Временный CTO против VP of engineering в кризисе стартапа

Почему основатели застревают на этом найме

Обычно основатели начинают думать, нужен ли им временный CTO или VP of engineering, после того как одна и та же неделя повторяется снова и снова. Сроки сдвигаются. Ошибки висят открытыми. Инженеры обвиняют требования, код или друг друга. Product lead не может получить внятный ответ. Все выглядят занятыми, но пользователи по-прежнему чувствуют хаос.

В этот момент «нужно больше руководства» звучит как ответ. Но это слишком расплывчато. Это две разные роли.

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

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

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

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

Чем занимается временный CTO

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

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

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

На практике эта роль сводится к нескольким понятным обязанностям:

• Выбирать архитектурные ставки, которые компания сохранит на следующем этапе.
• Убирать или приостанавливать системы, которые отнимают время и не помогают клиентам.
• Поддерживать tech lead'ов в выборе между скоростью, качеством и риском.
• Объяснять основателям, сколько стоит каждый вариант по времени, деньгам и фокусу.
• Доносить технический план восстановления до инвесторов или совета директоров, когда доверие уже просело.

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

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

Чем занимается VP of engineering

VP of engineering отвечает за способность команды выпускать результат каждую неделю, а не время от времени. Основатели или product lead'ы могут задавать цели, но VP превращает их в план с владельцами, сроками и компромиссами, с которыми команда справится.

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

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

Хороший VP также замечает, когда проблема совсем не в коде. Возможно, один менеджер избегает сложных разговоров. Возможно, два senior engineer'а постоянно спорят о приоритетах. Возможно, половина команды работает над срочными просьбами без владельца. Поставка результата срывается потому, что сломан сам рабочий ритм. VP чинит это первым.

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

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

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

Если компания уже понимает, что хочет строить, но команда не может делать это спокойно и стабильно, обычно нужен VP of engineering.

До product-market fit

До product-market fit обычно логичнее нанять временного CTO, а не VP of engineering. Компания все еще выясняет, чего хотят клиенты, за что они готовы платить и какие части продукта действительно важны. Технические решения должны помогать быстро учиться, а не строить безупречную структуру.

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

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

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

Временный CTO также должен защищать команду от работы, которая выглядит умной, но ничему не учит. Большинству стартапов до product-market fit не нужны формальные ритуалы планирования, сложные оргструктуры или архитектура, рассчитанная на будущую большую команду. Обычно достаточно простого бэклога, прямых заметок от клиентов и еженедельных релизов.

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

Ранний рост

Ранний рост меняет давление. Команда уже не просто строит новые функции. Теперь ей нужно еще и защищать продукт, на который уже реально опираются клиенты.

На этом этапе VP of engineering обычно должен взять на себя ритм поставки. Это значит планировать работу по неделям, следить, чтобы менеджеры проводили one-on-one, рано замечать заблокированные команды и держать сроки честными. Хороший VP превращает хаотичные релизы в рутину, которой команда может доверять.

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

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

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

Несколько рабочих правил быстро успокаивают ситуацию:

• Назначайте одного дежурного на каждую смену и заранее выбирайте запасного.
• Ограничьте время на review, чтобы pull request'ы не висели днями.
• Выпускайте релизы по расписанию, а не тогда, когда кому-то просто кажется, что уже можно.
• Если прод ломается, чините сначала его, а follow-up задачу создавайте в тот же день.

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

Когда масштаб начинает мешать

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

На этом этапе VP of engineering и CTO не должны делить одни и те же решения. Если делят, команды ждут, приоритеты плывут, а восстановление замедляется.

VP of engineering обычно владеет машиной, которая выпускает работу: структурой команд, staffing, планированием и еженедельным ритмом поставки. Если одна squad'а постоянно срывает сроки, другая выгорает, а тикеты в support продолжают копиться, VP в первую очередь чинит структуру.

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

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

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

Типичный пример — стартап с 25 инженерами, замедляющимися релизами и крупными клиентами, жалующимися на сбои. VP перестраивает команды, убирает шум из планирования и закрывает самую большую кадровую дыру. CTO упрощает путь деплоя, уменьшает связанность данных и усиливает ответственность за безопасность. Меньше пересекающихся решений обычно означает более быстрое восстановление.

Как принять решение за одну неделю

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

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

Для каждого сбоя определите главную причину:

• Архитектура: плохие технические решения, хрупкие системы, неясное направление
• Управление: слабое планирование, плохое доведение до конца, конфликт в команде, отсутствие ответственности
• Объем продукта: приоритеты постоянно менялись или в спринт попадало слишком много работы

Вот где многие основатели спотыкаются. Они спрашивают, нужен ли им временный CTO или VP of engineering, когда настоящая проблема — постоянная смена продукта. Если четыре из последних пяти сбоев произошли из-за смены приоритетов, ни один из этих наймов мало поможет, пока продуктовые правила не станут жестче.

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

После этого запишите одну 30-дневную цель восстановления и назначьте одного владельца. Держите ее узкой. «Вернуть еженедельные релизы без отката» — полезно. «Починить инженерию» — нет.

Проверка простая. Если самый большой пробел — техническая оценка, сначала нанимайте временного CTO. Если самый большой пробел — стабильность команды и ритм поставки, сначала нанимайте VP of engineering.

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

Простой пример восстановления

У SaaS-стартапа 14 инженеров, два сорванных релиза подряд и только что ушел tech lead. Отдел продаж ждет функцию, связанную с продлением контрактов, но команда снова и снова открывает старый код, потому что текущему дизайну никто не доверяет. Каждый спринт начинается с плана и заканчивается дополнительной работой.

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

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

Если главная проблема — исполнение командой, VP of engineering начинает с другого. Он работает с менеджерами, пересобирает планирование, сокращает встречи и вводит простые правила поставки, которым команда может следовать каждую неделю. В первую неделю его меньше интересует перепроектирование систем и больше — сделать следующий релиз предсказуемым.

Выбор становится яснее, если смотреть через призму выручки. Если из-за задержки одной функции компания может потерять продления, потому что текущий стек постоянно заставляет переделывать работу, сначала чините архитектуру. Если функция уже понятна, но после ухода tech lead'а никто не может довести ее до конца, сначала чините управление поставкой.

Ошибки, которые замедляют восстановление

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

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

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

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

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

Стартап выходит из кризиса, когда руководство режет объем работ, возвращает ответственность и снова выпускает что-то полезное за недели, а не за кварталы.

Краткий чеклист перед наймом

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

Перед тем как открывать поиск, проверьте пять вещей:

• Где сейчас лежат самые сложные решения: в системном дизайне или в исполнении команды?
• Почему сроки постоянно сдвигаются: меняющийся объем работ, плохая архитектура или слабое доведение до конца?
• Могут ли ваши текущие лиды вести планирование и review без участия основателя?
• Что вызвало последние несколько сбоев или неудачных релизов?
• Кто отвечает за первые 30 дней после выхода человека на работу?

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

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

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

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

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

Сначала отслеживайте только три показателя:

• соблюденные или сорванные даты релизов
• количество инцидентов
• текучесть команды

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

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

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