Когда нанимать фракционного CTO для найма и продуктовых решений

Почему одних советов уже недостаточно

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

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

Настоящая проблема — во времени. Наставник часто подключается уже после начала спора, даёт мнение и отходит в сторону. А команде всё равно нужен человек, который скажет: да, нет, не сейчас или сначала нанимаем вот этого человека.

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

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

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

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

Чем на самом деле владеет оператор

Наставник даёт мнение. Оператор принимает решение и отвечает за результат.

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

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

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

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

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

В бережливых командах хороший оператор может выбрать AI-инструменты вместо ещё одного штатного сотрудника, если это помогает держать сроки и стоит дешевле. Oleg Sotnikov на практике делал именно такую работу, в том числе управлял production-системами с очень маленькой командой, усиленной AI, сохраняя высокую надёжность. Это и есть операторская работа: бюджет, штат, поставка и результат связаны между собой.

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

Признаки, что роль наставника уже не подходит

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

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

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

Деньги тоже утекaют тихо. Команды начинают работу, прежде чем кто-то оценит стоимость, сравнит компромиссы или спросит, что придётся отложить ради этого. Продукту нужна скорость. Инженерам нужна надёжность. У обеих сторон есть аргументы, и работа всё равно стартует. Когда никто не владеет финальным решением, компания платит дважды: сначала зарплатами, а потом переделками.

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

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

Как расширять роль поэтапно

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

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

Самая аккуратная передача полномочий идёт поэтапно.

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

Зафиксируйте в письменном виде, кто принимает финальное решение. Если последнее слово всё ещё остаётся за основателем, так и напишите. Если решение в рамках заданной зоны принимает фракционный CTO, зафиксируйте и это.

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

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

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

Через 30 дней основатель смотрит на скорость. Кандидаты двигаются быстрее? Стали ли стандарты интервью понятнее? Через 90 дней он смотрит на качество. Прижились ли новые сотрудники? Сэкономила ли команда время? Если да — расширяйте зону. Если нет — сначала чините саму передачу полномочий.

Простой пример стартапа

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

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

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

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

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

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

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

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

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

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

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

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

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

Основатели ещё и слишком долго ждут, прежде чем подключить оператора. Они зовут человека, когда релизы уже месяцами срываются, senior-сотрудник не прижился или cloud costs резко выросли, а потом ждут быстрого ремонта. Это как нанять тренера, когда сезон уже разваливается, и попросить победу к пятнице.

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

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

Как задать рамки без путаницы

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

Обычно достаточно простой одностраничной заметки. Разделите решения на три группы: что оператор владеет сам, что требует одобрения основателя и что вы решаете вместе. Будьте конкретны. «Отвечает за найм» — слишком расплывчато. «Ведёт поиск, проводит первичный отбор инженеров и выбирает финалистов на backend-роль» — уже понятно.

Числа важны не меньше, чем титулы. Задайте бюджетные лимиты с реальными порогами, а не расплывчатыми формулировками вроде «небольшие покупки» или «обычные расходы». Например, фракционный CTO может утверждать инструменты до $2,000 в месяц, подрядчиков до $8,000 в месяц, а предложения по зарплате — только внутри заранее заданного диапазона. Основатель при этом может оставлять за собой согласование любой новой full-time-ставки, любого оффера выше установленной зарплаты и любой продуктовой ставки, которая может изменить планы по выручке.

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

Затем задайте еженедельный ритм и сделайте его скучным. Для ранней команды часто достаточно 30-минутной product-встречи, 30-минутной проверки найма и 30-минутного финансового обзора. На product-встрече обсуждается, что выходит следующим. На проверке найма смотрят открытые вакансии, блокеры и офферы. На финансовом обзоре проверяют burn, расходы на подрядчиков и то, вписывается ли текущий план в cash.

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

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

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

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

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

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

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

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

Лучше всего обычно работает короткий пилот на одной бизнес-проблеме. Дайте ему 30–60 дней и один важный результат. Можно попросить снизить ошибки в найме, сократить расходы на облако или решить, заслуживает ли новый продукт инженерного времени.

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

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