Когда фракционному CTO пора нанимать постоянную замену

Почему команды слишком долго ждут

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

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

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

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

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

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

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

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

Что подсказывает размер команды

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

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

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

К восьми инженерам предупреждающий сигнал обычно уже горит. Кому-то почти всегда нужно быть на связи каждый день, даже если эта «комната» — это Slack, Zoom и ежедневные стендапы. Небольшие задержки множатся. Одна команда ждет архитектурного решения, другая — обратной связи по найму, а старший инженер начинает играть роль неофициального менеджера без времени и полномочий, чтобы делать это хорошо.

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

Простое правило обычно работает неплохо:

• Два инженера: фракционный CTO обычно может направлять работу.
• Пять инженеров: компании нужны регулярная расстановка приоритетов и более четкая ответственность.
• Восемь и более инженеров: полная занятость руководителя часто становится безопаснее.
• Несколько команд или подрядчики: нагрузка на координацию может ускорить переход.

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

Как накапливается нагрузка на принятие решений

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

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

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

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

Самые явные сигналы обычно простые:

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

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

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

Как раунд инвестиций меняет роль

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

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

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

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

Полноценный CTO помогает очень практично:

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

Для timing найма CTO в стартапе самый чистый ход часто простой: дайте фракционному CTO помочь сформулировать роль, отобрать кандидатов и передать контекст за 30–60 дней. Так новый руководитель успевает заслужить доверие еще до закрытия раунда.

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

Как принять решение за 30 дней

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

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

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

Месяца достаточно, чтобы увидеть рисунок.

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

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

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

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

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

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

Спустя шесть месяцев в команде уже 9 инженеров. Звучит как небольшое изменение, но работа меняется быстро. Больше людей — больше pull request'ов, больше архитектурных вопросов, больше крайних случаев в продакшене и больше моментов, когда кому-то нужен ответ именно сегодня, а не во вторник на следующей неделе.

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

Фракционный CTO замечает, как меняется расход времени. Утро уходит на разбор багов, инцидентов и вопросов в Slack. Послеобеденное время растворяется в воронках найма, планировании и повторном объяснении одних и тех же решений разным людям. Долгосрочный фокус начинает исчезать. Вместо того чтобы формировать следующие 6–12 месяцев, работа превращается в попытку не дать неделе пойти наперекосяк.

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

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

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

Результат простой. Основатель снова получает поддержку по продукту. Инженеры — более быстрые ответы. Новый CTO начинает с более чистого старта, чем в разгар кризиса.

Ошибки, из-за которых переход становится сложнее

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

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

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

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

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

Более плавный переход обычно включает короткое overlap-перекрытие, чтобы новый CTO мог:

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

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

Быстрые проверки перед запуском поиска

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

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

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

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

Простой тест помогает:

• Есть ли ежедневные вопросы, которые не могут ждать несколько дней?
• Включает ли одна дорожная карта одновременно найм, поставку и снижение рисков?
• Потребуют ли инвесторы скоро полноценного технического лидера?
• Может ли основатель описать роль одним четким предложением?
• Есть ли у вас 60–90 дней на найм и overlap-передачу?

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

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

Оставляйте место для overlap. Найм старшего руководителя часто занимает 60–90 дней, и передаче тоже нужно время. Уходящий фракционный CTO должен передать контекст, познакомить нового лидера с командой и объяснить решения, которые сформировали текущий стек. Именно в этом overlap и происходит настоящая передача инженерного руководства.

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

Начните с понятного описания роли. Запишите, что компании нужно от CTO в ближайшие 12–18 месяцев, а не то, что было нужно, когда в команде было пять человек и выпускался один продукт. Говорите прямо о работе: найм, решения по дорожной карте, проверка архитектуры, встречи с инвесторами, контроль бюджета, безопасность или ежедневное управление командой.

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

Затем назначьте владельцев процесса до открытия поиска.

• Один человек должен вести поиск и держать его в движении.
• Небольшая группа должна проводить интервью.
• Один человек, обычно CEO или основатель, должен принять финальное решение.
• Текущий фракционный CTO должен формировать scorecard, а не контролировать каждый шаг.

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

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

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

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