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

Почему команды начинают действовать наугад после ухода CTO

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

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

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

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

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

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

Сначала зафиксируйте все открытые решения

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

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

Разделите каждое решение на одну из трёх категорий:

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

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

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

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

Затем остановите новые обсуждения, если они не связаны с выручкой, безопасностью или инцидентами в продакшене. Эта пауза важна. Команды часто тратят неделю на повторные обсуждения формы API, CI pipeline или выбора фреймворка, хотя старый план и так был достаточно хорош. Во время перехода CTO «достаточно хорошо» с записанными причинами лучше, чем более удачная идея, которая снова открывает пять новых вопросов.

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

Назначьте временных ответственных по направлениям

Когда никто не владеет решением, самый громкий человек в Slack часто и побеждает. Так команда за несколько дней съезжает из нормальной работы в догадки.

Вам не нужна идеальная оргструктура. Вам нужна короткая временная схема — кто за что решает до прихода нового CTO.

Назначьте по одному понятному владельцу на каждую область. Не комитет и не «спросим их обоих». Если два человека делят финальное решение, команда будет ждать, спорить или идти своим путём.

Для большинства стартап-команд хорошо работает простое разделение:

• Один человек отвечает за объём продукта. Он решает, что остаётся в спринте, что вырезать и что может подождать.
• Один человек отвечает за технические решения. Он решает архитектурные компромиссы, смотрит рискованные pull request и разруливает ничьи в инженерных спорах.
• Один человек отвечает за инциденты и операционку. Он занимается сбоями, доступами, вопросами подрядчиков, продлениями и срочными вопросами по безопасности.
• Все знают, кто принимает финальное решение в каждой области. Запишите имена там, где их увидит вся команда.

Фаундер часто берёт на себя объём продукта, особенно если клиентам нужны быстрые ответы. Старший инженер или временный технический лидер может взять code review и технические решения. Для инцидентов выберите человека, который уже работает с инфраструктурой, аккаунтами или эскалациями поддержки. Не отдавайте эту задачу тому, кто только начинает разбираться в стеке.

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

Говорите команде прямо. Скажите: «В ближайшие 30 дней Anna решает по объёму работ, Ben — по техническим вопросам, а Maya отвечает за инциденты и подрядчиков». Такая фраза убирает очень много лишних потерь времени.

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

Что делать в первые 7 дней

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

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

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

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

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

Дни 4 и 5 обычно — то место, где команды теряют время, даже не замечая этого. Отмените side projects, отложите cleanup-работу, которая может подождать, и встречи, которые существуют только потому, что были в календаре. Оставьте только те встречи, которые помогают поставке, например короткий ежедневный созвон и один еженедельный обзор рисков.

Дни 6 и 7 используйте, чтобы опубликовать один письменный план на месяц. Он должен быть коротким. В нём нужно указать:

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

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

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

Сократите roadmap до того, как сорвётся поставка

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

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

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

Хорошо работает быстрый фильтр:

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

Если ответ «нет», поставьте это на паузу.

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

Смену инструментов тоже стоит воспринимать с осторожностью. Новый фреймворк, issue tracker, облачная настройка или CI/CD процесс должны подождать, если только текущий вариант не создаёт боли прямо сейчас. «Мы всё равно собирались перейти» — этого недостаточно во время перехода CTO.

Небольшая команда может оставить исправление checkout, улучшение онбординга и одну функцию экспорта, обещанную платящему клиенту. Но при этом стоит отложить обновление дизайна, перестройку аналитики и cleanup-проект, который никто толком не может объяснить. Такое сокращение может сэкономить месяц дрейфа.

Простой пример из маленькой стартап-команды

SaaS-стартап из 10 человек теряет CTO за 14 дней до запланированного релиза. Время плохое, но главный риск не в пустой должности. Риск в том, что пять человек начинают делать пять разных предположений о том, что важнее всего.

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

Такое разделение быстро успокаивает команду. Вопросы по продукту идут фаундеру. Вопросы по инженерии — старшему инженеру. Люди перестают ходить кругами по встречам, потому что знают, кто принимает финальное решение.

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

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

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

Что меняется после сокращения

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

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

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

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

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

Неделю это кажется безобидным. Потом backend lead одобряет один подход, product manager обещает другой, а старший инженер тихо выбирает третий. Если вам нужно заменить CTO в стартапе, избегайте разделённой финальной власти. Мнение нескольких людей можно собирать, но решать должен один.

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

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

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

Небольшой стартап ощущает это уже через несколько дней. Допустим, команда из шести человек теряет CTO в понедельник. К пятнице один инженер ждёт доступ к облаку, другой не может продлить инструмент у подрядчика, потому что пропал billing contact, а у поддержки нет ответа по багу, который видят клиенты, потому что все заметки лежат в почте бывшего руководителя. Работа не останавливается из-за сложности кода. Она останавливается потому, что базовая операционная информация заперта не там, где нужно.

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

Быстрые проверки для еженедельного обзора

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

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

• Проверьте, что у каждого активного проекта есть один назначенный владелец. Совместное владение кажется справедливым, но часто создаёт паузы. Один человек должен отслеживать решения, двигать работу вперёд и ясно говорить, идёт ли проект по графику.
• Попросите каждого инженера сказать цель релиза на этой неделе в одном предложении. Если ответы не совпадают, команда распыляется. Цель должна быть настолько узкой, чтобы её не нужно было читать с доски.
• Посмотрите на backlog и сократите его до ближайших четырёх недель. Более длинный список провоцирует ложные обещания. Отложите идеи, которые могут подождать, и оставьте только то, что поддерживает ближайший релиз.
• Держите риски в одном видимом списке. Отсутствующие спецификации, нестабильный код, задержки у подрядчиков, заблокированные доступы и пробелы в найме должны лежать в одном месте. Если риск живёт только в чате, кто-то о нём забудет.
• Раз в неделю обсуждайте изменения объёма работ с фаундерами. Инженеры не должны тихо менять функции, чтобы сэкономить время. Фаундеры должны видеть, что сместилось, почему это произошло и как это влияет на дату релиза.

Считайте любой ответ в духе «ну, вроде бы» — ответом «нет». Это звучит жёстко, но потом экономит время. Размытое «да» обычно скрывает реальную проблему, и команда расплачивается за это уже через неделю.

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

Что делать дальше, если пробел затянулся

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

В этот момент нужно сделать один ясный выбор: вам нужен новый CTO на full-time уже сейчас или временное прикрытие, пока компания продолжает выпускать продукт? Это разные задачи. Поиск на full-time может занять месяцы. Временное прикрытие нужно для того, чтобы удерживать техническое направление, снижать риски и дать команде человека, который может сказать «да», «нет» или «не сейчас».

Составьте 30-дневный бриф для того, кто будет закрывать этот пробел. Сделайте его простым и конкретным. В брифе должно быть указано:

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

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

Если у фаундеров не очень много технической глубины, зовите внешнюю помощь раньше. Слишком долго ждать обычно дороже, чем попросить поддержки. Опытный fractional CTO может заранее посмотреть на владение, объём roadmap, риски поставки и узкие места команды, пока дрейф не стал хуже.

Именно такой работой занимается Oleg Sotnikov как Fractional CTO и startup advisor. Он руководил командами от стартапов до глобальных production-систем, а также выстраивал lean AI-augmented operations с очень небольшими командами. В более длинном переходе CTO такой внешний взгляд помогает фаундерам отделить реальные риски от шума и собрать простой план, которому команда сможет следовать.

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