Первый инженерный менеджер: что должен исправить внешний CTO

Почему в первый день всё идёт не так

Новый менеджер редко приходит в уже собранную команду. Обычно он попадает в размытые привычки, недоделанные решения и работу, которая уже кажется просроченной. Если стартап нанимает первого инженерного менеджера до того, как навести порядок, этот человек первые недели будет разбираться с путаницей вместо того, чтобы вести людей.

Первая проблема — ответственность. Один инженер занимается инцидентами в продакшне, потому что лучше всех знает систему. Другой берёт на себя запросы клиентов, потому что основатель ему доверяет. Третий тихо не отвечает ни за что конкретное. У нового менеджера вроде бы есть команда, но нет карты. Трудно управлять эффективностью, когда никто не договорился, кто отвечает за релизы, баги, техдолг и планирование.

Основатели часто делают хуже, даже не замечая этого. Они по-прежнему утверждают каждое продуктовое решение, врываются в планирование спринтов и меняют приоритеты в личных чатах. На табличке написано «менеджер», но команда всё ещё ждёт, когда решит основатель.

Работа обычно разбросана по разным местам. Баг лежит в чате. Идея фичи — в документе. Срочный запрос клиента — у кого-то в голове. Инженеры привыкают быстро реагировать, потому что именно так компания выжила в раннем росте. Потом приходит новый менеджер и пытается планировать на неделю вперёд. Не получается, потому что реальная нагрузка раскидана по пяти местам и по памяти двух людей.

Вот почему первый инженерный менеджер может выглядеть слабым, даже если он хороший. Он наследует шум, отсутствие правил и постоянные отвлечения. Хороший внешний CTO быстро видит настоящую проблему: дело не в том, что человек не справляется. Команда всё ещё работает как постоянный аварийный пункт под руководством основателя.

Пока неясна ответственность, решения по продукту не идут по понятному пути, а работа не живёт в одном месте, управлению людьми почти нечем помочь. Менеджер просто продолжает реагировать вместе со всеми.

Что внешний CTO должен исправить сначала

До прихода первого инженерного менеджера внешний CTO должен убрать путаницу, к которой основатели уже привыкли. Новый менеджер мало что сможет сделать, если каждый релиз, каждый сбой и каждое изменение продукта по-прежнему превращаются в общий спор.

Начните с ответственности за решения. Один человек должен отвечать за продуктовые решения, один — за техническое направление, и один — за решения во время инцидента, когда что-то ломается. В маленьком стартапе один основатель какое-то время может совмещать две роли. Это нормально. Настоящая проблема — скрытое пересечение.

Запишите, кто принимает решение, кто даёт вводные и кого потом просто ставят в известность. Пишите простыми словами. Если API падает в 2 часа ночи, команда должна знать, кто может остановить работу над фичами и кто общается с клиентами. Если срывается задача по срокам, всем должно быть понятно, кто принимает компромисс — продукт или инженерия.

Потом сделайте инвентаризацию. В большинстве стартапов систем больше, чем кто-либо признаёт. Соберите в одном месте все репозитории, сервисы, подрядчиков и внутренние инструменты. Включите и то, что люди обычно забывают: старый staging-сервер, уведомление по платежам в личной почте основателя, аналитический инструмент, которому никто не доверяет, но за который всё ещё платят.

Простой список должен включать:

• каждый кодовый репозиторий и кто может выкатывать его в прод
• каждый продакшн-сервис и от чего он зависит
• каждого платного подрядчика и кто отвечает за контракт
• каждый внутренний инструмент, который команда использует каждую неделю

Когда список готов, отметьте системы, которые ломаются чаще всего. Не гадайте. Посмотрите на недавние инциденты, повторяющиеся баги, шумные алерты и жалобы в поддержку. Небольшая проблема с оплатой, которая бьёт по клиентам каждую пятницу, важнее, чем идея переписать всё с нуля, которая может подождать.

После этого разделите работу на две корзины: срочные исправления и запланированную продуктовую работу. Срочные исправления — это сбои, дыры в безопасности, сломанные деплои, рискованные зоны без нормального тестового покрытия и болезненные передачи задач. Запланированная продуктовая работа — это всё, что команда строит осознанно. Если смешать это в одном бэклоге, новый менеджер унаследует хаос и первый месяц будет извиняться за планы, которые никто не мог выполнить.

Такой порядок даёт инженерному менеджеру не пустой лист, а команду с понятными решениями, видимой картой системы и бэклогом, который не врёт.

Наведите порядок в бэклоге и роадмапе

Грязный бэклог делает нового менеджера медленным, даже если настоящая проблема началась много месяцев назад. Если на доске 300 тикетов, полусырые идеи и баги без владельца, первый инженерный менеджер первые недели будет сортировать шум вместо того, чтобы вести людей.

Внешний CTO должен навести этот порядок до прихода человека. Цель простая: оставить короткий, правдоподобный план, который команда реально сможет выполнить в ближайшие 6–12 недель.

Начните с бэклога. Откройте каждый тикет и примите жёсткое решение. Удалите старые запросы, которые больше не важны. Объедините дубликаты. Закройте задачи, которые описывают проблему, которую никто не может воспроизвести. Если у тикета нет понятной причины существовать, ему не место на доске только потому, что кто-то записал его полгода назад.

Потом разложите оставшееся на несколько простых категорий: запросы клиентов, баги, техдолг и операционная работа. Такое деление быстро меняет разговор. Основатели видят, что даёт ценность пользователю, что продолжает ломаться и что команда всё время откладывает, потому что никто не хочет этим заниматься.

Дайте каждому активному приоритету одного владельца. Не двум командам, не «инженерии» в целом и не основателю, который вспоминает о задаче только на встречах. Один владелец означает, что есть один человек, который может ответить, что сейчас происходит с этой задачей. Он всё ещё может просить помощи, но задача не висит в воздухе.

С роадмапом нужна та же дисциплина. Сократите его максимум до следующего квартала. Всё, что дальше, в раннем стартапе обычно превращается в гадание. Если держать 12-месячный роадмап, полный фич, новый менеджер унаследует обещания, которые он не давал и не сможет защищать.

Такая уборка звучит очень просто. Она и правда простая. И она работает. Когда новый менеджер приходит, он может помогать команде и принимать решения, а не распутывать месяцы накопленного мусора.

Сначала опишите роль, а потом нанимайте

Многие стартапы говорят, что им нужен менеджер, хотя на самом деле им нужна более ясная ответственность. Первый инженерный менеджер не должен приходить в роль, которая для пяти разных людей означает пять разных вещей. Если основатель, команда и внешний CTO представляют себе разную работу, найм начинается с путаницы.

Сначала примите одно простое решение: этот человек отвечает за людей, за поставку или за всё вместе. Роль с упором на людей включает one-on-one, обратную связь, поддержку найма и состояние команды. Роль с упором на поставку отвечает за планирование, приоритеты, сроки и доведение до результата. Некоторым ранним стартапам нужно и то и другое, но это работает только тогда, когда команда ещё маленькая, а объём задач остаётся узким.

Запишите, какие встречи этот человек должен вести. Не оставляйте это расплывчатым. Если он отвечает за поставку, он может вести еженедельное планирование, сверку роадмапа и обзор релизов. Если он отвечает за людей, он должен проводить one-on-one и базовые разговоры о результативности. Если основатель всё ещё хочет вести продуктовые обзоры или звонки с клиентами, не включайте это в описание роли.

Хорошее описание также говорит, как выглядит успех через 90 дней. Достаточно короткого и конкретного списка. Трёх-четырёх результатов хватит:

• вести стабильный ритм команды с понятным еженедельным планированием и последующими шагами
• регулярно проводить one-on-one с каждым инженером и отслеживать открытые вопросы
• уменьшить перенос работы между недельными циклами или спринтами
• давать основателю простой отчёт по поставке без ежедневного тушения пожаров

Такой список помогает нанимать и защищает найм потом. Если задача не поддерживает эти результаты, стоит спросить, почему она вообще входит в роль.

Основатели часто переносят в эту работу свои незавершённые привычки. Отсюда и начинаются проблемы. Ночная разборка сообщений в Slack, переписывание тикетов, погоня за одной пропущенной дедлайном и участие в каждом техническом споре — это привычки основателя, а не обязанности менеджера. Внешний CTO может отделить эти привычки от настоящей работы ещё до начала поиска.

Есть простой тест. Если бы вы наняли этого человека завтра, смог бы он объяснить свою неделю, не спрашивая основателя каждое утро? Если нет, роль всё ещё слишком размыта.

Задайте командные правила, которые унаследует менеджер

Новый менеджер должен прийти в команду, где уже есть несколько понятных правил. Если каждый разработчик работает по-своему, менеджер первый месяц будет разбирать мелкие споры, а не вести команду.

Начните с одного места для спецификаций и решений. Продуктовые заметки, технические решения и изменения объёма должны лежать в одном месте, а не расползаться по чату, почте, тикетам и памяти основателя. Когда люди не могут найти последнее решение, они начинают угадывать. Угадывания превращаются в переделки.

Простой еженедельный ритм помогает больше, чем ожидает большинство основателей. Выберите одну встречу по планированию в неделю. Используйте её, чтобы подтвердить приоритеты, отметить блокеры и решить, что попадёт в ближайшие дни. Потом не трогайте план, если не случилось ничего серьёзного. Если основатель меняет направление каждый день после обеда, будущий менеджер становится регулировщиком на перекрёстке.

Правила поставки тоже должны быть общими. Они не обязаны быть сложными. Каждое изменение кода должно проходить ревью до выката. Релизы должны выходить по понятному графику, даже если этот график — всего два раза в неделю. Кто-то должен отвечать за алерты в продакшне и знать, когда разбудить другого человека. После исправления инцидента нужно короткое письменное описание, чтобы та же ошибка не повторилась.

Роль основателя тоже должна иметь границы. Основатель должен вмешиваться в обещания клиентам, бюджетные решения, одобрение найма и настоящие аварии. А вот в ежедневное перетасовывание тикетов, комментарии к ревью кода и случайные просьбы в личных сообщениях ему лучше не лезть.

Здесь хорошо работает один простой тест: если разработчик не может понять, кого слушать — основателя, продуктового лидера или будущего менеджера, — правило всё ещё неясно.

Для стартапа, который нанимает первого инженерного менеджера, это важнее, чем красивый оргструктурный рисунок. Менеджер должен унаследовать команду с рабочими привычками, спокойным циклом планирования и меньшим количеством лишних сюрпризов.

Как провести эту уборку за 30 дней

Одного месяца достаточно, чтобы сделать команду удобнее для управления, если внешний CTO жёстко держит рамки. Цель не в том, чтобы переделать компанию. Цель в том, чтобы убрать мусор, который на первый же день заблокирует вашего первого инженерного менеджера.

Первая неделя — это карта реальности. Составьте список всех активных проектов, всех инструментов, к которым прикасается команда, и того, кто сейчас отвечает за каждую область. Вам нужен простой обзор кода, продуктовых решений, поддержки, релизов и инцидентов. Если за что-то никто не отвечает, тоже запишите это. Скрытая работа вредит новому менеджеру быстрее, чем тяжёлая работа.

На второй неделе большинству стартапов становится немного больно. Жёстко сократите бэклог. Архивируйте старые идеи, объединяйте дубликаты и отделяйте реальные обязательства от списка пожеланий. Выберите несколько ближайших приоритетов и напишите, почему они важны именно сейчас. Если команда не может объяснить, зачем существует задача, ей, скорее всего, пора уйти с доски.

На третьей неделе уборка превращается в план найма. Определите, что будет в зоне ответственности менеджера в первые 90 дней. Составьте короткую шкалу успеха с несколькими понятными результатами. Отметьте, что остаётся у основателей или у внешнего CTO. Подготовьте заметки для интервью, которые проверяют именно эту работу, а не абстрактный титул менеджера.

Это экономит много плохих наймов. Многие стартапы говорят, что им нужен менеджер, но на самом деле им нужен техлид, рекрутер или человек, который наведёт порядок в процессах.

Четвёртая неделя — это стресс-тест. Прогоните новый процесс на текущей команде до открытия роли. Проведите одну встречу по планированию, одно обновление статуса и один обзор по новым правилам. Посмотрите, где решения всё ещё застревают, где ответственность остаётся размытой и где команда всё ещё зависит от основателя даже в мелочах.

Часто именно так работает внешний CTO на частичной занятости: навести порядок в ответственности, сократить зоопарк инструментов и заставить команду работать с меньшим числом отвлечений ещё до добавления ещё одного уровня управления. Если текущая команда не может следовать процессу хотя бы неделю, новый менеджер это не исправит. Он просто унаследует проблему.

Простой пример стартапа

Представьте SaaS-стартап из 10 человек. Основатель по-прежнему отвечает почти на все вопросы по поставке. Когда sales просит исправление для клиента, они пишут инженеру напрямую. Когда support находит баг, он падает в Slack. Идеи по продукту лежат в документе, недоделанные задачи — в репозитории, и никто не может сказать, что должно выйти на этой неделе.

Два инженера тянут на себе большую часть продукта. Они делят день между новыми фичами, проблемами в продакшне и запросами поддержки, которые приходят от основателя. Один начинает менять дашборд, а потом бросает это, чтобы починить платёжный баг. Второй берёт задачу по API, а потом уходит на звонок с клиентом. Они работают много, но прогресс ощущается случайным.

Внешний CTO исправляет это до того, как компания нанимает первого инженерного менеджера. Каждый запрос попадает в одну очередь. Дубликаты убираются. Работа раскладывается по нескольким простым категориям: фича, баг, поддержка или инцидент. Потом внешний CTO назначает владельца для каждого открытого пункта, чтобы основатель перестал раздавать задачи в личных сообщениях, а инженеры перестали гадать, кто должен отвечать.

Уборка добавляет и базовый ритм. Команда проводит короткое планирование в начале недели и проверку поставки в середине. Поддержка дежурит по очереди, так что один инженер разбирает входящие вопросы, а другой продолжает двигать продуктовую работу. Роадмап сокращается до ближайших нескольких недель вместо огромного списка, который никто не может закончить.

Теперь новый менеджер приходит в команду, где всё понятно. Он не тратит первый месяц на чтение старых тредов в Slack и не спрашивает, почему три человека трогали один и тот же тикет. Он получает очередь, понятных владельцев и еженедельный ритм, который можно сохранить или улучшить. Вот тогда первый инженерный менеджер действительно начинает помогать.

Ошибки, которые убивают найм

Стартап часто нанимает senior-менеджера, когда основатель чувствует, что его уже распирает от задач. Это реальное давление, но титул не исправляет поведение основателя. Если основатель всё ещё меняет приоритеты в личных чатах, отвечает на каждый технический вопрос и вмешивается в каждый спор о поставке, новый менеджер становится прослойкой, а не лидером.

Ещё одна частая ошибка — использовать высокий титул, чтобы решить проблему основателя. Компания говорит, что ей нужен менеджмент, а на самом деле у неё неясная ответственность, слабое планирование и слишком много решений, застрявших в голове одного человека. Первый инженерный менеджер не наведёт порядок за один день. Если роль размыта, найм первый месяц будет только угадывать, чего на самом деле хочет основатель.

Некоторые команды ждут, что один человек будет управлять людьми и одновременно спасать каждый инцидент. Обычно это долго не работает. Менеджер может помогать инженерам расти, вести найм, улучшать планирование и помогать команде поставлять лучше. Но тот же человек не может быть ещё и круглосуточным реагирующим на инциденты, senior-архитектором, рекрутером и терапевтом для уставшего основателя. Когда так происходит, именно работа с людьми страдает первой. One-on-one пропускаются, обратная связь становится поверхностной, а мелкие командные проблемы превращаются в увольнения.

Приватные продуктовые решения делают работу ещё хуже. Основатели часто решают изменения объёма в личных чатах с sales, дизайном или одним доверенным инженером. Потом менеджер приходит на планирование с половиной контекста и получает обвинение, когда команда не попадает в срок. Если продуктовые решения реальны, им нужно письменное место ещё до того, как двинется процесс найма.

Последняя ошибка — оценивать успех по количеству встреч и статусов. Переполненный календарь может скрывать грязную команду. Больше стендапов, длиннее планирование и красивее еженедельные отчёты не означают, что менеджер помогает. Более хорошие признаки проще: меньше неожиданных смен приоритетов, быстрее решения, понятнее ответственность и меньше повторяющихся вопросов от команды.

Проверки перед открытием роли

Не открывайте роль только потому, что команде кажется, что она занята. Открывайте её тогда, когда у работы уже есть достаточно формы, чтобы её мог вести кто-то ещё. Первый инженерный менеджер быстро начинает буксовать, если каждое решение всё ещё проходит через основателя, задачи лежат в трёх местах, и никто не может сказать, что новому человеку нужно исправить первым.

Перед тем как писать вакансию, проведите короткую проверку.

Назначьте одного человека ответственным за найм. Этот человек планирует интервью, собирает обратную связь и решает, что происходит после каждого этапа. Если основатель, рекрутер и senior-инженер только частично отвечают за процесс, кандидаты получают смешанные сигналы.

Перенесите планирование в одну систему. Она может быть простой, но это должно быть единственное место, где живут приоритеты, владельцы и статус. Менеджер не сможет успокоить команду, если работа приходит через чат, звонки и личные заметки.

Сделайте согласование релизов очевидным. Каждый инженер должен понимать, кто может выкатывать, кто может остановить релиз и что делать, если что-то ломается в пятницу вечером.

Попросите основателя за минуту объяснить первые 90 дней. Если он не может сказать это понятно, роль всё ещё расплывчата.

Этот последний тест важнее, чем думает большинство основателей. Если ответ звучит как «помочь команде вырасти» или «принести процессы», кандидаты будут заполнять пробелы сами. Один менеджер может ожидать власти над наймом. Другой — ожидать, что останется в коде и будет много делать руками. Оба могут быть сильными кандидатами и всё равно провалиться.

Попробуйте один прямой тест. Спросите трёх человек в команде одни и те же вопросы: где планируется работа, кто утверждает релизы и чего новый менеджер должен добиться к 90-му дню. Если ответы не совпадают, остановите найм и сначала исправьте это. Неделя уборки дешевле плохого найма.

Что делать дальше

Сделайте подготовку до того, как назначите хотя бы одно интервью. Первый инженерный менеджер помогает тогда, когда у команды уже есть понятная роль, базовые правила и бэклог, в котором есть смысл. Если эти вещи всё ещё в хаосе, новый менеджер первый месяц будет разбирать путаницу основателя вместо того, чтобы кого-то вести.

Начните с трёх простых документов: заметки по роли, правила команды и уборка бэклога. В заметках по роли должно быть написано, что этот человек берёт на себя, что всё ещё остаётся у основателя и как выглядит успех через 30, 60 и 90 дней. В правилах команды должны быть планирование, ревью кода, реакция на инциденты и место, где всё это записывается. В уборке бэклога должно быть видно, что активно, что заблокировано, что уже стало шумом и какие проблемы требуют внимания в первую очередь.

Обычно этого достаточно, чтобы превратить расплывчатый найм в настоящий процесс. Это ещё и делает интервью лучше. Кандидаты видят честную картину, а не красивую историю, которая разваливается после выхода на работу.

Говорите о проблемах прямо. Если поставка задерживается, потому что никто не закрывает тикеты, скажите это. Если основатель по-прежнему отвечает на каждый вопрос по продукту, скажите и это тоже. Хорошие кандидаты не ждут идеала. Им нужно понимать, куда они приходят, какая у них будет власть и где именно сейчас лежит трение.

Если вы не можете сделать эту работу в одиночку, привлеките внешнюю помощь до найма. Хороший внешний CTO может проверить объём роли, передачи задач между основателем и менеджером и ежедневный процесс, который унаследует новый человек. Это часто дешевле, чем нанять быстро и через полгода заменить не того человека.

Oleg Sotnikov занимается такой работой со стартапами и небольшими командами, а oleg.is даёт ясное представление о его фокусе на Fractional CTO и консультациях для стартапов. Если вам нужен второй взгляд до открытия роли, такая проверка может показать пробелы, которые иначе лягут на первого инженерного менеджера.