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

Почему переход быстро становится хаотичным

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

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

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

Обычно предупреждающие признаки очевидны:

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

Найм от этого часто страдает сильнее, чем ожидают. Компания говорит, что ей нужен senior backend engineer, product engineer или AI lead, но роль продолжает меняться, потому что меняется план. Кандидаты замечают, когда интервьюеры не могут объяснить, что команда будет делать дальше и кто примет финальное решение. Сильные люди обычно уходят, вместо того чтобы ждать, пока компания разберется сама.

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

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

Что советник должен взять на себя в первую очередь

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

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

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

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

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

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

Что подготовить до передачи

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

Кодовая база тоже нуждается в карте людей. Запишите, кто отвечает за billing, кто понимает deployments, кто быстро починит mobile app и кто до сих пор помнит, зачем вообще существует тот или иной запутанный сервис. Достаточно одной простой страницы с именами, зонами ответственности и заметками о рисках. Если только один инженер знает хрупкую часть стека, советник должен увидеть это уже в первый день.

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

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

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

Такая подготовка дает fractional CTO-поддержке чистую точку старта. Советники вроде Oleg Sotnikov часто просят в начале перехода о том же самом: о простом и честном контексте. Чем яснее передача, тем меньше плохих догадок придется делать новому лидеру.

Первые 30 дней

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

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

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

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

К третьей неделе найм обычно требует наведения порядка. Открытые процессы тянутся во время смены руководства, а расплывчатые описания ролей только ухудшают ситуацию. Советнику стоит закрыть устаревшие переписки с кандидатами, объяснить рекрутерам, что именно нужно команде, и переписать рамки ролей простым языком. «Senior backend engineer» — это слишком широко, если реальная потребность звучит как «человек, который сможет отвечать за Go-сервисы и production incidents».

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

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

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

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

В каждой заметке должно быть:

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

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

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

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

Инженеры должны добавлять недостающий контекст, пока детали еще свежие. Разработчик может написать, почему у сервиса жесткие rate limits. Product manager может объяснить, почему команда отклонила запрос клиента. Эти маленькие обновления потом экономят часы.

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

Цель не в идеальном архиве. Цель проста: если кто-то спрашивает «Почему мы делаем это именно так?», команда должна ответить за две минуты, а не после трех веток в Slack и звонка с бывшим основателем.

Как не останавливать найм

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

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

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

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

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

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

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

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

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

Параллельно рекрутер отбирает кандидатов на backend. В brief написано, что компании нужен «сильный backend engineer», но не объясняется, чем человек будет владеть, какие компромиссы важны и какие навыки нужны в первую очередь.

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

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

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

Ошибки, которые тормозят изменения

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

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

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

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

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

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

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

Короткий чек-лист для передачи

Используйте его как проверку pass-or-fail до того, как основатель отойдет в сторону. Если хотя бы один пункт все еще расплывчатый, команда заполнит пробел догадками, а догадки быстро становятся дорогими.

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

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

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

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

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

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

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

Короткий план действий работает лучше, чем длинный план перехода:

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

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

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

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