Engineering Manager кто это: роль, обязанности, путь в 2026
Самый живучий миф в индустрии: Engineering Manager — это senior-разработчик, которому дали права админа в GitHub и разрешили одобрять pull requests по пятницам. Миф ошибочный по двум причинам. Первая: медианный EM в 100+ B2B-командах, которые мы измеряем, пишет код примерно 18 минут в день, и это здоровая цифра. Вторая: самое ценное, что делает EM, к IDE отношения не имеет. Это разговор, который удержал senior'а от ухода. Переписанная спека, которая спасла квартал. Нанятый инженер на уровень выше, чем команда считала возможным. Will Larson, который строил инженерию в Stripe, Calm и Carta, в An Elegant Puzzle формулирует прямо: задача EM — сделать так, чтобы команда выдавала больше суммы своих частей. Руками на клавиатуре этого не сделать.
Эта статья — простое определение роли. Кто такой EM, что он делает в течение недели, чем отличается от Tech Lead, как попасть туда из senior engineer и по каким метрикам понять, что человек справляется.
{/* truncate */}
Engineering Manager — определение в одном предложении
Engineering Manager — это человек, отвечающий за результат, рост и поставку команды разработки, и делает он это через людей, а не через код.
Три слова в определении несут вес. Отвечает, не «вовлечён». Если команда провалила квартал, отвечает EM. Команда, не проект и не кодовая база. EM управляет людьми, которые случайно пишут софт, а не самим софтом. Через людей — это медиум, через который происходит работа. Leverage лежит в разговорах, решениях о том, кто что делает, и в дизайне того, как течёт работа. Не в коммитах.
Camille Fournier в The Manager's Path (2017) описывает переход так: будучи IC ты дебажишь код, будучи EM — дебажишь системы из людей. Навыки не переносятся 1-в-1. Именно поэтому senior'ы, которых толкнули в менеджмент без подготовки, либо откатываются в код, либо выгорают, пытаясь делать обе работы.
Engineering Manager vs Tech Lead — разделение
Эти две роли путают постоянно. Это параллельные треки, а не ступени одной лестницы. Вот как они расходятся по четырём измерениям, которые действительно имеют значение:
| Измерение | Tech Lead | Engineering Manager |
|---|---|---|
| Доля кода в неделе | 40-60% | 0-10% |
| Ownership | Кодовая база, архитектура, технические направления | Люди, поставка, здоровье команды |
| People management | Только менторинг — нет перфоманса, нет sign-off на найме | Полный — perf-ревью, comp, найм, увольнения |
| Стратегический горизонт | Архитектура квартала, тех. ставки на год | План по headcount, growth ladder, структура команды |
Tech Lead, которого заставили ещё и проводить performance review, либо пропускает работу с людьми, либо пропускает работу с кодом. Подробный разбор раскола — Tech Lead vs Engineering Manager vs Engineering Lead. Короткий вывод: совмещение двух ролей в одной должности — самая частая и самая дорогая ошибка лидерства на масштабе 8-15 инженеров.
Что EM реально делает в течение недели
40-часовая неделя EM средней команды (6-8 reports) выглядит примерно как на графике ниже.
Куда уходят 38 из 40 часов EM. Оставшиеся ~2 часа съедают Slack-triage и вещи, которые не влезают в календарь.
| Активность | Часов/неделя | Что это реально значит |
|---|---|---|
| 1:1 с reports | 6-8ч | 45-60 мин на человека в неделю. Карьера, блокеры, сбор сигналов |
| Кросс-командные встречи | 5-7ч | PM, design, другие EM, зависимости, планирование |
| Найм + интервью | 4-6ч | Pipeline review, panel-интервью, дебрифы, write-ups |
| Планирование и roadmap | 4-6ч | Шейпинг спринтов, квартальные ставки, согласование скоупа с PM |
| Unblocking + эскалации | 3-5ч | Всё, где власть EM сдвигает то, что команда не может |
| Код, ревью, доки | 2-4ч | Мелкие фиксы, PR ревью для контекста, комментарий к RFC, изредка прототип |
| Growth + perf | 3-5ч | Промо-пакеты, feedback по перформансу, разговоры о comp |
| Skip-level, оrg-работа | 1-3ч | Manager's manager, кросс-оrg инициативы, hiring panel для других команд |
Заметьте, чего нет: значимого написания кода. EM, пытающиеся остаться в кодовой базе, оказываются на критическом пути фичи, уходят heads-down, команда перестаёт разблокироваться, спринт уезжает. Честный tradeoff: можно быть IC-контрибьютором, можно быть менеджером. Попытка делать обе работы на масштабе — это и есть выгорание.
Как стать EM из senior engineer
Единого пути нет, но есть надёжные сигналы готовности и надёжные failure modes первого года.
Сигналы, что вы готовы
- К вам приходят с не-кодовыми проблемами. Карьерные вопросы, конфликты, «это нормально?». Если джуны уже используют вас как неформального ментора, формальная версия — небольшой шаг.
- Вы делаете других продуктивными. Ваши PR полезны, но ваше unblocking полезнее. Команда замечает, когда вас нет.
- Вам уже не хочется писать каждый PR самостоятельно. Вам начинает нравиться проектировать работу больше, чем делать её. Самый надёжный сигнал, потому что его сложнее всего изобразить.
- Вы умеете писать ясно и быстро, без приступа ярости в Google Docs. Большая часть работы EM — письменная коммуникация. Если вы ненавидите писать, в роли будет больно.
Типичные ошибки первого года
| Ошибка | Почему случается | Сколько стоит |
|---|---|---|
| Код >30% недели | «Я всё ещё сильнейший инженер тут» | Команда медленнее разблокируется, EM становится единой точкой отказа |
| Избегание тяжёлых разговоров | Инженерная культура поощряет технический спор, а не личный feedback | Перфоманс-проблемы зреют 2-3 квартала, прежде чем кто-то их адресует |
| Попытка быть всем другом | EM, выросшие изнутри команды, перекомпенсируют сохранение отношений | Теряют авторитет в момент, когда нужно реальное решение |
| 1:1 как статус-митинг | Откат к самому привычному паттерну (standup) | 1:1 становятся бесполезны, реальные сигналы никогда не всплывают |
| Оптимизация только по delivery | Проще всего измерить, хорошо смотрится для leadership | К Q3 retention обваливается, все «победы» испаряются |
Самый недооценённый навык первого года: умение скучать продуктивно. Новые EM часто чувствуют себя бесполезными, потому что за день не произвели ни одного артефакта. Артефакт — это output команды следующего квартала. Если эта идея вызывает тревогу, роль будет тяжёлой.
Структурный фреймворк для проведения 1:1 на данных, а не на ощущениях: Data-Driven One-on-Ones.
Как измерить EM
Честный лимит сразу: для engineering management нет DORA. DORA даёт четыре числа, которые любая команда может продуктивно обсуждать. «Хороший ли мой EM?» к четырём числам не сводится. Это сильно зависит от стадии команды, зрелости компании и того, под какую задачу EM нанимали.
Измерения, которые стабильно имеют смысл:
| Измерение | Что мерить | Здоровый диапазон / сигнал |
|---|---|---|
| Здоровье поставки команды | Стабильность cycle time (std dev / mean за 8 недель), commitment vs delivered | std dev < 0.5× mean; отклонение по обязательствам в пределах ±15% |
| Retention | Добровольный attrition в команде за 12 мес, доля «жаль, что ушёл» | < 10% добровольного; < 3% regretted |
| Рост | Скорость промо, изменение распределения по уровням IC год-к-году | Минимум 1 промо / 4 reports / год |
| Найм | Time-to-hire, accept rate, проход 90 дней | < 60 дней; > 75% accept; > 90% проходят |
| Engagement | eNPS или pulse, кросс-проверка с поведением | Опрос ≥ 30 И отсутствие after-hours паттерна |
| Кросс-командная координация | Skip-level + peer-EM feedback, hit-rate по зависимостям | Стабильный peer rating, < 1 проваленная зависимость / мес |
Контр-интуитивное утверждение в этой таблице: лучший EM часто заметно хуже как кодер, чем её лучший senior IC. Это не баг. Время в IDE — это время не на unblocking, не на найм, не на разговор, который удерживает человека от ухода. Если ваш EM выдаёт больше строк кода, чем половина её reports, она недо-инвестирует в те куски работы, которые только она может сделать.
Та же логика наверх: VP Engineering First 90 Days — как это масштабируется на уровень оrg, и Staff Engineer Framework — параллельный IC-трек, если менеджмент не цель.
Где здесь PanDev Metrics
EM наших клиентов используют team-level views для одной конкретной вещи: отделить то, что я думаю, что происходит от того, что реально происходит. Focus time vs meeting time по каждому direct report, after-hours паттерны по людям, кросс-проектное распределение, когда человек «разделён» между тремя задачами. Всё пассивно из IDE heartbeat, Git и трекеров. Идея не в надзоре. Идея в том, чтобы 1:1 был про реальную форму недели, а не про self-report, искажённый тем, что инженер думает о ваших ожиданиях. Одно правило воркфлоу включает это всё: ветки именуются с ID задачи (feature/PDM-3475).
FAQ
Engineering Manager — это менеджер или инженер?
Менеджер, который раньше был инженером. Инженерный бэкграунд нужен для кредибельности и адекватного технического суждения, но повседневная работа — менеджмент. Если слово «менеджер» вызывает дискомфорт, возможно, роль не ваша. В этом нет ничего плохого. Для тех, кто хочет остаться IC, существует Staff Engineer track.
Сколько кодит Engineering Manager?
Медиана: ~18 минут в день, обычно прототипный код или разблокировка критичного бага. Диапазон: 0-10% недели. EM, которые кодят >20% недели, либо в команде из 2 человек, либо пытаются починить delivery-проблему своими руками вместо лидерства.
Engineering Manager vs Tech Lead — в чём реальная разница?
Tech Lead = senior IC с архитектурным ownership, кодит 40-60% недели, нет полномочий по people management. Engineering Manager = лидер людей с ответственностью за delivery, кодит 0-10%, владеет наймом, perf, comp. Параллельные треки, не последовательные. Полный разбор: Tech Lead vs Engineering Manager.
Какие навыки нужны Engineering Manager?
Примерно в таком порядке по leverage: (1) письменная коммуникация, (2) структурированные 1:1 и feedback, (3) суждение в найме, (4) переговоры о скоупе и приоритетах с PM и design, (5) техническое суждение, достаточное чтобы вызвать BS на плохие оценки, (6) спокойствие в инцидентах. Навык писать код имеет куда меньшее значение, чем навык работы с людьми.
Когда команде нужен Engineering Manager?
Грубое правило: когда один человек отвечает за 5+ инженеров и тратит больше 50% недели не на код. Ниже 5 инженеров обычно хватает Tech Lead. Выше 8 — почти всегда нужен выделенный EM.
Сколько подчинённых у Engineering Manager?
Здоровый диапазон: 5-8 direct reports. Ниже 4 — у EM слишком много времени и он начинает перенаправлять команду. Выше 8 — каденс 1:1 ломается. Посчитайте: 8 reports × 1ч/неделя = полный день уже ушёл. Выше 10 — нужны либо skip-level EM, либо команда поменьше. Подробнее про team-size signals — 10 metrics every EM should track; про механику промо в эту роль — Junior-to-Senior Promotion.
Честный итог
Engineering Manager — это не senior engineer с правами админа. Это другая работа. Leverage переезжает из IDE в календарь команды, а артефакт — это люди, которые продуктивны, растут и не уходят. Путь из senior engineer существует, но не гладкий, и первый год обычно проходит либо в чрезмерном кодинге, либо в избегании тяжёлых разговоров. Навык учится. Лучшие EM, которых мы видим — это те, кто рано признал, что больше не будет лучшим кодером в команде, и отнёсся к этому как к сути работы, а не к потере идентичности.