Когда нанимать временного CTO перед поиском штатного

Что идет не так до того, как найм CTO начинает приносить пользу

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

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

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

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

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

Когда временный CTO нужен уже сейчас

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

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

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

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

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

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

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

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

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

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

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

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

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

План на 30 дней, чтобы стабилизировать команду

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

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

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

Дни 11–20

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

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

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

Дни 21–30

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

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

Простой пример из растущего стартапа

У B2B SaaS-компании число инженеров выросло с шести до четырнадцати меньше чем за год. Продажи улучшились, но поставка стала хуже. Даты релизов сдвигались, баги висели неделями, а каждый новый сотрудник забирал задачи по-своему, потому что никто не установил понятные правила ответственности, code review и планирования.

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

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

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

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

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

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

Как понять, что команда стабилизируется

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

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

Работа перестает прыгать туда-сюда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Короткий чек-лист перед запуском поиска

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

Сначала пройдите короткую проверку:

• Можете ли вы назвать три главных технических риска прямо сейчас? «Наш деплой ломается два раза в неделю», «биллинг знает только один инженер» и «облачные расходы продолжают расти» — это реальные риски. «Нам нужны лучшие технологии» — нет.
• Может ли команда выпускать продукт по стабильному графику хотя бы месяц? Быстро не обязательно. Предсказуемо — обязательно.
• Есть ли один человек, который явно отвечает за архитектурные решения, и один человек, который явно отвечает за найм?
• Можете ли вы объяснить, что должен сделать CTO на полную ставку в первые 90 дней?
• Понимаете ли вы, какой именно лидер вам нужен: операционный, архитектурный или управленец, работающий с людьми?

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

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

Что делать основателю дальше

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

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

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

Используйте этот разбор как внутренний бриф. Перескажите его команде простыми словами, чтобы люди понимали, что меняется сейчас, кто за что отвечает и что какое-то время останется без изменений. Затем используйте тот же документ, чтобы сформировать поиск. В некоторых случаях следующий правильный найм — это head of engineering, staff engineer или технический лидер с продуктовым мышлением, а не CTO.

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

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