Когда мы говорим об инженерном менеджменте, чаще всего на поверхность всплывают «правильные процессы», «эффективные митинги», «разрешение конфликтов» или «выстраивание коммуникаций со стейкхолдерами». Всё это, безусловно, важно. Но на практике есть ещё один, менее очевидный, но куда более сложный вызов — вовремя понять, какую позицию занять: приблизиться к ситуации или вмешаться напрямую.
Я называю это так: Zoom In и Step In.
🔍 Zoom In: вовлечённость без вмешательства
Zoom In — это умение менеджера наклониться ближе к ситуации, но не забирать инициативу. Ты смотришь на метрики, задаёшь уточняющие вопросы, наблюдаешь за динамикой команды. Ты не переписываешь чужой код и не берёшь на себя чужие задачи.
Почему это важно? Потому что чаще всего проблеме нужно внимание, а не давление.
На одном из проектов мы увидели, что скорость ревью PR выросла почти втрое. Это выглядело тревожно. Казалось бы, самое простое — начать «подгонять» разработчиков или самому подключиться к ревью. Но правильнее было просто задать несколько вопросов: кто и как сейчас делает ревью? Оказалось, что нагрузка свалилась на двух человек, а остальные были в стороне. Когда команда это увидела, она сама же перераспределила обязанности. Без давления, без потери доверия.
Вот что такое Zoom In — вовремя подсветить проблему и помочь людям увидеть её сами.
🛠 Step In: прямое вмешательство
Но иногда Zoom In не спасает. Бывают ситуации, когда уже нельзя просто наблюдать.
Представьте себе: пятница вечер, сервис лежит, пользователи не могут зайти, разработчики на нервах и не могут быстро синхронизироваться. Это не момент для «наблюдения» и длинных вопросов. Здесь нужно действовать: подключаться самому, брать на себя управление, помогать с принятием решений и устранением проблем. Это Step In.
Другой пример: важный релиз горит, дедлайн под угрозой. Ключевые задачи застряли, блокеры не решены. В такой момент бесполезно просто задавать вопросы. Нужно самому договариваться со стейкхолдерами, убирать препятствия, иногда даже временно «вставать в строй».
Step In реже нужен, но именно он иногда спасает бизнес и команду.
⚖️ Искусство переключения
Настоящее мастерство инженерного менеджера в том, чтобы уметь переключаться.
Если всегда оставаться в Zoom In, можно легко упустить момент, когда ситуация уже становится критической. Но если всегда жить в режиме Step In, команда теряет самостоятельность и превращается в исполнителей указаний.
Поэтому баланс — ключ.
- Zoom In нужен, когда метрики начинают «провисать», когда слышны тревожные сигналы.
- Step In нужен, когда кризис уже на пороге и время играет против команды.
Особенно сложно вовремя выйти обратно из Step In. Когда всё стабилизировалось — важно снова вернуть команде автономию.
🎯 Вывод
Каждый день инженерного менеджера — это не черно-белый выбор, а настройка «громкости участия». Иногда приходится несколько раз за день переходить от Zoom In к Step In и обратно.
Хороший инженерный менеджер — это не тот, кто всегда вмешивается, и не тот, кто всегда отстраняется. А тот, кто чувствует момент: чуть раньше подключиться, чуть раньше отпустить.
👉 В моём Telegram-канале я регулярно делюсь разбором таких ситуаций и личным опытом: https://t.me/pavelsengineeringstuff