Когда нанимать fractional CTO вместо новых инженеров

Что идёт не так, когда никто не владеет tradeoffs

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

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

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

Обычно проблема становится ясной, когда вы называете её прямо:

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

Когда так происходит, любой tradeoff превращается в спор. Backend lead говорит о стабильности. Product — о скорости. Founder хочет и того и другого. Команда продолжает обсуждать, потому что никто не уполномочен выбрать путь и взять на себя цену этого выбора.

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

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

Почему больше senior engineers редко это исправляет

Нанимать ещё senior engineers кажется безопасным вариантом. У вас больше опыта, лучше ревью и меньше ошибок новичков. Но если никто не владеет tradeoffs, вы в основном добавляете ещё больше мнений.

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

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

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

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

Это и есть architecture drift. Одна команда добавляет сервис, потому что так удобно ей сейчас. Другая меняет процесс деплоя. Третья придумывает свои правила тестирования. Ни одно решение само по себе не ломает компанию. Но вместе они замедляют всё.

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

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

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

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

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

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

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

Повторяющиеся инциденты — ещё один признак. Deployments ощущаются напряжёнными. Небольшие изменения ломают части продукта, которые вроде бы не связаны. Команда воспринимает каждую аварию как неудачу, хотя они снова и снова возникают из одних и тех же shortcuts. Это не просто проблема кода. Это проблема ответственности.

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

Чаще всего founders чувствуют это раньше, чем могут назвать. Если вы слишком много времени тратите на улаживание технических споров, выбор того, что важно в этом квартале, или перевод между product и engineering, вы уже делаете CTO-работу. Просто делаете её без достаточного времени и структуры.

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

Вот тогда executive technical direction становится важнее, чем ещё один кодер.

Как выглядит executive technical direction

Executive technical direction — это в первую очередь умение закрывать решения, чтобы команда не открывала их заново каждую неделю. Кто-то задаёт границы: какие части продукта должны быть строгими, где можно сохранять простоту и где команде не стоит импровизировать.

Сразу задайте правила

Хорошее направление звучит просто. Используйте один путь деплоя. Храните один источник истины для billing и login. Выберите один способ работы с тестированием и релизами. Не переписывайте рабочий код, если это не решает проблему пользователя, проблему стоимости или серьёзную проблему надёжности.

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

Найм тоже должен обсуждаться в этом же контексте. Компании с запутанным roadmap не всегда нужны ещё руки для кода. Иногда нужен один человек, который решит, должен ли следующий найм быть backend engineer, product engineer, infrastructure specialist или пока вообще никого не нанимать.

Держите один план

Направление также означает выбор, где надёжность должна быть скучной и где достаточно простого кода. Payments, login и целостность данных требуют более строгих ревью, уведомлений и планов отката. Внутреннему admin tool может хватить понятного кода и базовых проверок. Если команда относится к каждой функции как к системе с высоким риском, поставка замедляется. Если ко всему относится как к быстрому хаку, накапливаются проблемы с поддержкой.

Product, engineering и operations должны следовать одному плану. Если product обещает еженедельные релизы, а operations всё ещё борется с одними и теми же авариями, команда теряет время дважды. Технический лидер выстраивает работу: что выходит в этом квартале, что стабилизируется, какой target по uptime важен и какие shortcuts всё ещё допустимы.

Меньше героического кодинга. Больше ясных решений, которые помогают всей команде двигаться вместе.

Как понять, что добавить следующим

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

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

Потом разберите список по трём вопросам:

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

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

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

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

Простой пример из растущей SaaS-команды

Представьте B2B SaaS-компанию с семью инженерами, одним founder и продуктом, на который уже есть стабильный спрос. Клиенты хотят меньше багов и ещё пару отсутствующих функций. Команда выглядит занята весь день, но релизы каждую неделю идут всё медленнее.

Три инженера начинают по-разному перепроектировать один и тот же сервис. Один хочет разделить его на части. Другой — полностью переписать на новом языке. Третий предлагает оставить текущий код и добавить queue для обработки нагрузки. Каждая идея сама по себе разумна. Но окончательного yes или no нет.

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

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

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

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

Вот где judgment на уровне CTO важнее, чем raw coding capacity. Кто-то должен решать, чего команда не будет делать, а не только то, что она могла бы построить. В небольшой компании этим человеком часто становится fractional CTO, а не full-time руководитель.

Результат не магический. Codebase всё ещё не идеален. Но команда выпускает исправления багов, доставляет пропущенные функции и перестаёт параллельно перепроектировать одну и ту же проблему. Headcount тот же, а output выше, потому что один человек наконец-то взял на себя tradeoffs.

Ошибки founders, когда они нанимают ради скорости

Founders часто нанимают ради движения, когда на самом деле им нужно направление. Команда кажется медленной, сроки сдвигаются, и простой ответ — добавить senior engineer. Это может помочь с output. Но компании это не даёт понятного владельца технических tradeoffs.

Распространённая ошибка — ждать, что лидерство появится само по себе только потому, что у нового сотрудника сильное резюме. Senior engineer может писать отличный код и при этом совсем не хотеть заниматься staffing, sequencing или говорить «нет». Если за эти решения никто не отвечает, команда продолжает двигаться, но по кругу.

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

Ситуация становится ещё сложнее, когда founder, product lead и engineering lead каждый владеет частью решения, но финального слова нет ни у кого. Product хочет скорости. Engineering хочет почистить систему. Founder хочет и то и другое. В итоге команда наполовину делает новую работу и одновременно тащит старые проблемы дальше.

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

Legacy systems — ещё одна ловушка. Founders сохраняют все старые потоки, странные edge cases и выведенные из оборота сервисы, потому что не хотят раздражать пользователей. Это понятный инстинкт. Но он быстро становится дорогим. Команда начинает поддерживать несколько версий одного и того же, и каждый релиз замедляется.

Растущей SaaS-компании не нужны ещё два инженера, пишущие код, если никто не выведет из эксплуатации старый billing path, не упростит deployment и не выберет одну архитектуру вместо пяти полу-решений. Вот тогда fractional CTO становится серьёзным вариантом.

Быстрая проверка, прежде чем открывать ещё одну роль

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

Если никто не может, ещё больше senior engineers, скорее всего, добавят только ещё больше мнений. Хорошим инженерам всё равно нужен понятный владелец tradeoffs.

Задайте эти вопросы и ответьте на них «да» или «нет»:

• Инженеры знают, кто утверждает крупные изменения до начала работы?
• Последние два инцидента произошли из-за неясной ответственности, а не из-за жёстких технических ограничений?
• Можете ли вы объяснить, почему следующий найм нужен именно сейчас, а не просто ради скорости?
• Ограничения по затратам влияют на технические решения каждую неделю?
• Может ли один человек связать product plans, системный дизайн, risk и budget?

Если на большинство ответов — «нет», сначала у вас не проблема с наймом. У вас проблема с направлением.

Возьмём знакомый пример. Приложение начинает тормозить, и команда нанимает ещё одного backend engineer. Через два месяца люди всё ещё спорят, делить ли codebase, продолжать ли латать его или перенести часть работы в queue. Финальное решение по-прежнему никому не принадлежит. Работа идёт, но форма системы продолжает уплывать.

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

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

Что делать дальше, если команда застряла

Если команда застряла, остановитесь прежде, чем добавлять новые роли. Запишите решения, которые постоянно прыгают между founders, product и engineering. Если за них никто не отвечает, ещё один senior hire обычно добавляет ещё одно мнение, а не ясность.

Спор между senior engineers и CTO редко бывает про чистый skill. Он про ownership. Технический лидер принимает решения, которые формируют cost, speed и risk, когда ни один вариант не кажется идеальным.

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

Full-time CTO нужен тогда, когда компании требуется ежедневное руководство, ownership по найму и тесная работа с founders. Fractional CTO подходит, когда команда умеет строить продукт, но приоритеты расползаются, системы растут неравномерно или планы найма не совпадают со стадией продукта. Более сильный engineering manager подходит, когда стратегия в целом понятна, а настоящая проблема — исполнение.

Проверку держите короткой. Двух-трёх встреч и письменного summary достаточно. Если на то, чтобы понять, кто принимает tradeoffs, уходит шесть недель, путаница уже стоит слишком дорого.

Если нужен внешний взгляд, Oleg Sotnikov на oleg.is работает со стартапами как fractional CTO и startup advisor по архитектуре, инфраструктуре, структуре команды и практичному внедрению AI. Его опыт охватывает роли от software engineer до CTO, CEO и founder. Цель проста: понять, нужен ли вам более ясный технический лидер, больше headcount или и то и другое. Если вы всё ещё не можете назвать того, кто владеет трудными решениями, начните с этого.