44 урока engineering-менеджмента: часть 1
Перед вами адаптированный перевод и осмысление легендарной статьи «44 Engineering Management Lessons» — настольной памятки engineering-менеджера. Материал разбит на 3 части по 15 уроков. Оригинал написан в 2014 году, но каждый пункт остаётся актуальным и в 2025.
Целевая аудитория: tech-lead, team-lead, engineering manager, CTO небольшой компании — все, кто управляет разработчиками.
Часть 1. Что делать (Do)
Урок 1. Привлекайте, растите и удерживайте таланты
Разговаривайте с инженерами. Выявляйте проблемы на ранней стадии — когда человек задумывается об уходе, а не когда кладёт заявление на стол. Решайте проблемы, если можете.
Как это выглядит на практике: регулярные one-on-one встречи, на которых вы не говорите, а слушаете. Вопрос не «как дела с проектом», а «что тебя беспокоит?», «где ты чувствуешь, что буксуешь?», «что бы ты изменил в процессе?»
Урок 2. Доносите до каждого инженера следующий по важности приоритет
Разработчик не должен гадать, чем заняться. У него должен быть ответ на вопрос «над чем я работаю сейчас и почему это важно». Приоритеты меняются — коммуницируйте изменения.
Инструмент: список из максимум 3 приоритетов на неделю. Не 25 задач в Jira с пометкой «High».
Урок 3. Будьте арбитром, когда команда не может прийти к консенсусу
Две одинаково разумных архитектуры, два подхода, два инструмента. Команда спорит третий день. Ваша задача — выслушать обе стороны и принять решение. Без решения команда застрянет.
Урок 4. Будьте информационным хабом
Знайте, над чем работает каждый инженер. Соединяйте точки: «Слушай, Петя делал похожий модуль в прошлом квартале — поговори с ним, он сэкономит тебе неделю».
Антипаттерн: спрашивать «Чем ты занимаешься?» на статус-митинге. Вы должны знать это до митинга.
Урок 5. Обеспечьте административную поддержку
Согласование релизов, планирование встреч, взаимодействие с HR и смежными отделами, бюрократия. Если разработчик тратит 30% времени на администрирование — вы не справляетесь.
Урок 6. Обеспечивайте соблюдение поведенческих и профессиональных стандартов
Увольняйте буллеров. Увольняйте тех, кто систематически не выполняет обязательства. Один токсичный инженер разрушает команду быстрее, чем вы успеваете её построить.
Часть 2. Чего НЕ делать (Don't)
Урок 7. Не чините баги и не пишите фичи лично
Код писать нужно — чтобы оставаться техническим арбитром. Но ваша работа — не закрывать задачи в спринте. Если вы регулярно дописываете код за командой — вы наняли не тех людей.
Урок 8. Не контролируйте качество и объём работы инженеров ежедневно
Разработка — не конвейер. Если вы вынуждены проверять каждый коммит — проблема в найме или в отсутствии культуры качества. Микроменеджмент — симптом, а не решение.
Часть 3. Мотивация и культура
Урок 9. Вы принимаете решения о найме и увольнении — всё на команде лежит на вас
Не HR, не CEO, не тимлид. На вас. Если команда неэффективна — это ваша ответственность. Не перекладывайте.
Принцип экстремальной ответственности (Джоко Виллинк): командир отвечает за всё, что происходит в его подразделении. Даже если отказал движок, а он не механик — он отвечает за то, что механик не проверил движок.
Урок 10. Рынок разработки — рынок продавца
Люди работают с вами, потому что верят в вас. Доступ к их таланту — привилегия, а не данность. Талантливый инженер может уйти в любую из 50 компаний. Почему он должен остаться с вами?
Практика: у каждого сильного инженера спросите раз в квартал: «Почему ты всё ещё здесь?» — и слушайте ответ.
Урок 11. Авторитет не даётся должностью — он зарабатывается решениями
Вас назначили руководителем. Это даёт вам право подписывать отпуска и проводить митинги. Но авторитет — когда команда выполняет ваше решение, даже если не согласна — вы зарабатываете месяцами правильных решений.
Урок 12. Не принимайте решения, если не обязаны
Когда возможно, дайте команде исследовать варианты и принять решение самостоятельно. Во-первых, они ближе к коду и знают больше. Во-вторых, люди выполняют свои решения охотнее, чем спущенные сверху.
Урок 13. Принимайте решения, когда это необходимо
Застрявшая команда деморализует быстрее, чем непопулярное решение. Если обсуждение идёт по кругу — принимайте решение и двигайтесь дальше.
Урок 14. Создайте среду, где безопасно предлагать идеи
Не отвергайте идеи, пока не стало абсолютно необходимо. Люди, пишущие код, знают детали, которых не знаете вы. Если инженер боится предложить улучшение — вы потеряли ценнейший источник инноваций.
Google Project Aristotle: психологическая безопасность — фактор №1 эффективности команды. Без неё лучшие специалисты будут молчать, боясь показаться глупыми.
Урок 15. Фреймворки управления — 5% успеха, остальное — интуиция и отношения
Scrum, Kanban, OKR, SAFe — они сделают хорошего менеджера чуть лучше, а плохого — чуть хуже. Никакой фреймворк не заменит умения принимать решения и строить отношения с командой.
Главное: доверие команды, умение слушать, готовность принимать решения. Всё остальное — инструменты.
Итог части 1
Первые 15 уроков покрывают три ключевые зоны engineering-менеджера:
- Делать (привлекать таланты, задавать приоритеты, быть арбитром, соединять информацию, снимать бюрократию, поддерживать стандарты)
- Не делать (не кодить за команду, не микроменеджерить)
- Строить культуру (брать ответственность, зарабатывать авторитет, создавать безопасность, не переоценивать фреймворки)
Во второй части — эмоции, люди, арбитраж и конфликты.
Связанные статьи: Архитектурные роли в ИТ: карьерный трек SE → SA → EA