Внешний CTO или инженерный менеджер: кого нанять?

Почему этот выбор кажется запутанным

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

Именно здесь и начинается путаница. Внешний CTO и инженерный менеджер могут помочь, но они решают разные задачи.

Основатели часто смешивают стратегию, поставку продукта и управление людьми в одну расплывчатую роль и надеются, что один найм закроет все три. Иногда это срабатывает. Чаще — скрывает настоящее узкое место.

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

Обычно правду лучше всего показывают три сигнала: размер команды, боль с релизами и риск системы.

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

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

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

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

Внешний CTO начинает с технического направления. Когда основатели слышат от старших инженеров разные ответы или никто не хочет брать на себя сложный компромисс, этот человек вмешивается и принимает решение.

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

Если команда спорит о выборе стека, объеме дорожной карты или о том, строить что-то внутри компании или купить готовое решение, внешний CTO снимает спор и понятно объясняет почему.

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

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

Это особенно важно, когда старшие инженеры сильные, но перегружены. Хорошие инженеры могут построить многое. Но им все равно нужен один понятный ответственный за решения, которые влияют на безопасность, надежность, найм и затраты.

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

Что в первую очередь исправляет инженерный менеджер

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

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

Эта роль наводит порядок в повседневной работе. Сильный инженерный менеджер ведет планирование, следит за регулярными индивидуальными встречами и внимательно относится к состоянию команды. Если один инженер теряется, другой постоянно ошибается в оценке сроков, а третий избегает code review, такой паттерн требует именно управления, а не нового дизайна системы.

Он также убирает блокеры, которые незаметно тормозят все вокруг. Задача ждет ответа от продукта. Запрос на слияние лежит без движения два дня. Backend уже готов, а frontend не подхватывает работу, потому что никто не договорился о передаче. Инженерный менеджер замечает такие разрывы и закрывает их.

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

Коучинг важнее, чем многие основатели ожидают. Менеджер может помочь сильному разработчику разбивать большие задачи на маленькие, раньше просить о помощи и понятнее объяснять компромиссы. Такая поддержка способна изменить результат уже за несколько недель.

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

Начните с размера команды

Численность — грубый фильтр, но он хорошо работает. Чем меньше команда, тем меньше нужен еще один уровень менеджмента и тем важнее четкая техническая оценка.

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

Ситуация меняется, когда команда вырастает до семи-пятнадцати человек. На этом уровне подойдут обе роли. Вопрос лучше сформулировать так: что болит каждую неделю?

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

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

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

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

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

Используйте боль с релизами как сигнал

Передача от «готово» к «в проде» говорит больше, чем отчеты о статусе. Когда команда говорит, что код готов, но релиз все равно срывается, значит, на пути к продакшену что-то слабое.

Начните с вопроса: что ломается после того, как код написан? Ответ обычно подсказывает, какой найм нужен.

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

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

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

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

Проверьте риск системы, прежде чем решать

Оргструктура может подождать день. Системный риск — обычно нет.

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

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

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

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

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

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

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

Простой способ выбрать за одну неделю

Вам не нужен долгий спор о найме. Обычно одна неделя честного разбора показывает, где именно начинается ущерб.

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

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

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

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

Потом напишите одним предложением, как выглядит успех через 90 дней. Сделайте его конкретным. «Выпускать релизы по графику и уменьшить количество заблокированных задач» — это про инженерного менеджера. «Снизить системный риск, задать техническое направление и остановить дорогие переписывания» — это про внешнего CTO.

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

Простой пример из стартапа на 12 человек

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

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

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

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

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

Через несколько недель команда часто выглядит совсем иначе. Пятничных срочных фиксов становится меньше. Релизы уменьшаются. Инженеры перестают гадать, кто должен принимать решение, если что-то ломается.

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

Ошибки, которые съедают время и бюджет

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

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

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

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

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

Команды также копируют должности из гораздо более крупных компаний. В компании на 200 человек можно разделить CTO, VP Engineering и engineering managers. Стартапу на 10 человек чаще всего это не подходит. Если вы берете крупнокорпоративные названия, вы вместе с ними берете и предположения, которые не работают для маленькой команды.

Лучше простой тест. Задайте три вопроса: кто принимает сложные технические компромиссы, кто каждую неделю держит людей в ответственности и кто подключается, когда релизы начинают срываться? Если одно описание должности пытается ответить на все три, перепишите его до найма.

Быстрые проверки перед тем, как открывать роль

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

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

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

Перед тем как это превратится в неудачный найм, задайте несколько прямых вопросов. Кто принимает финальное архитектурное решение, когда инженеры спорят? Кто каждую неделю ведет планирование, дает обратную связь по найму и обсуждает результативность? Как часто срываются релизы и что вызвало последние несколько задержек? Какой сбой ударит сильнее всего: простой, потеря данных, проблемы с безопасностью или сломанный биллинг? Что должно быть правдой через 90 дней, чтобы можно было сказать, что найм сработал?

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

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

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

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

Составьте узкий чек-лист, прежде чем писать вакансию. Привяжите его к результатам, которые можно увидеть за 30–90 дней. Сократите задержки релизов с еженедельных до редких. Определите три главных системных риска и назначьте ответственных. Настройте понятный ритм инженерной работы для планирования и ревью. Зафиксируйте, кто отвечает за архитектуру, поставку и управление людьми.

Это также делает собеседования проще. Становится видно, нужен ли вам стратегический технический взгляд, практическая структура поставки или и то и другое на короткий период.

Если вы все еще не уверены, начните с короткого консультационного разбора, прежде чем нанимать человека на полную ставку. На oleg.is Oleg Sotnikov работает с основателями над структурой команды, потоком релизов, инфраструктурой и системными рисками — это помогает понять, должен ли следующий найм отвечать за направление или за исполнение. Такой разбор часто дешевле, чем нанять не того руководителя на full time и через три месяца перестраивать оргструктуру заново.

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

Выбирайте роль, которая закрывает следующее болезненное узкое место. А потом дайте этому человеку понятный чек-лист и достаточно пространства, чтобы он сделал работу.