Красные флаги в роли startup CTO, из-за которых сильные лидеры уходят

Почему сильные кандидаты уходят сразу

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

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

В чем разница между сложной и хаотичной работой

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

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

Сильные кандидаты быстро замечают три тревожных сигнала:

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

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

Основателям стоит воспринимать такое сопротивление как подарок. Если senior-кандидат говорит, что роль выглядит неясной, он показывает вам проблему до того, как вы заплатите за нее плохим наймом, коротким сроком работы и месяцами пробуксовки.

Размытые полномочия становятся заметны сразу

Сильный кандидат замечает это уже на первых встречах. startup CTO role может звучать очень senior, но реальная динамика в комнате говорит о другом.

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

CTO не может одновременно тянуть delivery, качество и uptime, если еще трое людей сохраняют право вето.

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

• Кто принимает финальное решение по компромиссам в roadmap?
• Кто утверждает архитектурные решения и технические стандарты?
• Кто нанимает, управляет и увольняет инженеров?
• Кто выбирает агентства, инструменты и сервисных подрядчиков?

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

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

Размытые линии подчинения только усиливают проблему. Формально CTO может подчиняться CEO, но ежедневно получать указания от основателя, давление от sales и неожиданные запросы от агентства, которое до сих пор владеет частью стека. Такая схема рождает маленькие конфликты каждую неделю. Какая работа срочная? Кто может сказать «нет»? Кто решает спор, если приоритеты не совпадают?

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

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

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

Скрытая зависимость от агентства меняет саму работу

startup CTO role выглядит совсем иначе, если delivery по-прежнему ведет внешнее агентство. На бумаге новый лидер отвечает за engineering. На практике агентство все еще контролирует темп, людей и многие технические решения.

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

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

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

Риск еще выше, если у подрядчика остаются базовые вещи:

• облачные аккаунты и доступ к production
• права администратора в системе контроля исходников
• скрипты деплоя и настройка CI/CD
• заметки по архитектуре и история инцидентов
• контакт с разработчиками, которые собирали систему

Без этого передача дел не считается настоящей. Это всего лишь обещание.

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

Поэтому некоторые команды сначала привлекают fractional CTO. Его задача не в том, чтобы принять на себя вину. Его задача — навести порядок в зонах ответственности, передаче дел и правилах работы до того, как full-time лидер унаследует беспорядок.

Размытый план найма превращается в личный долг

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

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

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

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

В слабой startup CTO role это быстро превращается в плохой сценарий. Основатели ждут результата, опираясь на будущую команду. Команда так и не приходит вовремя. Senior-наем закрывает дыру поздними вечерами, поспешными решениями и лоскутным наймом. Так ранний burnout начинается почти сразу.

Сильный план менее эффектный, но гораздо безопаснее. Он может звучать так: один backend-инженер выходит в июне, один product designer — в июле, диапазоны зарплат уже утверждены, а CEO дает финальное согласование в течение 48 часов. С таким планом можно работать.

Перед тем как принимать предложение, спросите:

• Кто утверждает каждого нового сотрудника?
• Какой бюджет уже одобрен?
• Когда выйдет каждый человек?
• Кто отвечает за sourcing и подбор?
• Какая работа будет убрана, если найм задержится?

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

Как запускаются blame loops

Blame loop часто начинается с одной пропущенной даты. Основатель говорит команде, а иногда и инвесторам, что фича выйдет в пятницу. Пятница проходит, агентство говорит, что изменился scope, основатель говорит, что delivery был на инженерной стороне, а технического лидера спрашивают, почему «его команда» не уложилась в план. В понедельник основатель требует план восстановления, агентство придумывает объяснения, а лидеру приходится защищать работу, которой он не до конца управлял.

Опоздавшая фича — это только триггер. Более глубокая проблема — неясная ответственность. Если никто не зафиксировал, кто отвечает за scope, бюджет, контроль подрядчиков и найм, каждый может пересказать историю так, чтобы защитить себя. Агентство скажет, что ждало решений. Основатель скажет, что руководство должно было давить сильнее. Лидер скажет, что ему не дали права менять подрядчика или нанимать помощь. Все три версии могут звучать частично правдоподобно.

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

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

Обычно заранее видны несколько признаков:

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

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

Как определить роль до найма

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

Опишите этот 90-дневный план простыми словами. Уберите общие фразы вроде «отвечать за tech» или «масштабировать engineering». Скажите, что должно произойти к 30-му, 60-му и 90-му дню. Реальный план звучит примерно так: выпустить один просроченный релиз, задокументировать стек, забрать одну область продукта у агентства, нанять одного senior-инженера и сократить cloud-расходы на 15 процентов.

Еще нужна четкая линия принятия решений. Один человек принимает финальные решения по продукту. Один человек — по технологиям. Если CEO, руководитель продукта, агентство и инвестор могут отменить одно и то же решение, startup CTO role уже сломана.

До любого собеседования опишите текущую ситуацию на одной странице:

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

Одна такая страница быстро меняет разговор. Кандидаты видят, идут ли они в настоящую команду или наследуют набор разрозненных договоренностей.

Успеху тоже нужны даты, а не ощущения. Хорошая цель на 30 дней — провести аудит стека и убрать самые опасные риски. Хорошая цель на 60 дней — забрать release control внутрь компании. Хорошая цель на 90 дней — закрыть две вакансии и выйти на стабильный ритм релизов. Понятные цели защищают обе стороны.

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

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

У небольшого SaaS-стартапа есть один основатель, одно агентство и уже есть продукт с платящими пользователями. Теперь основатель хочет нанять первого senior-технического сотрудника и публикует широкую startup CTO role: отвечать за roadmap, исправить проблемы качества, нанять команду и ускорить delivery.

Сначала это звучит хорошо. Потом всплывают детали.

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

Сильный кандидат обычно останавливается и задает несколько прямых вопросов до того, как сказать «да»:

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

Такие вопросы быстро меняют разговор. Дело не в названии должности. Дело в скрытой зависимости от агентства и неясных полномочиях.

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

У стартапа получается лучший результат, если он переписывает роль. Основатель переносит репозитории, cloud-доступ и мониторинг в аккаунты, которые принадлежат компании. Предложение меняется с «отвечать за весь tech» на понятную 90-дневную задачу: забрать delivery у агентства, задокументировать систему, расставить приоритеты по найму и еженедельно сообщать о рисках. Основатель также выделяет реальный бюджет на одного инженера и оставляет продуктовые решения у себя.

Теперь роль честная. Хороший кандидат может оценить объем работы, ограничения и риски. Если компания пока слишком ранняя для full-time CTO, сначала помочь с передачей дел может fractional CTO, а уже потом сформировать более сильный найм.

Быстрые проверки перед тем, как делать оффер

Хорошая startup CTO role должна быть понятна до оффера, а не после выхода человека на работу. Сильные лидеры делают быстрый risk scan. Им нужно понять, смогут ли они реально выполнять работу или полгода будут просить доступы, спорить о бюджете и получать вину за медленный прогресс.

Короткий чек-лист многое показывает:

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

Эти вопросы кажутся базовыми, но слабые предложения обычно проваливаются по двум или трем из них. Основатель говорит: «Ты будешь отвечать за engineering», а контроль над подрядчиками, утверждение найма и доступ к production оставляет у кого-то другого. Это не ownership. Это borrowed accountability.

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

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

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

Некоторые команды зовут fractional CTO на короткий review перед full-time наймом. Это помогает увидеть размытые полномочия, недостающие доступы или нереалистичный план по штату еще до того, как обе стороны допустят дорогую ошибку.

Частые ошибки основателей

Основатели часто портят startup CTO role еще до начала поиска. Сценарий простой: они продают upside, пропускают повседневную реальность, а потом удивляются, почему сильные кандидаты теряют интерес уже после нескольких звонков.

Одна из частых ошибок — говорить о видении и скрывать операционные детали. Кандидат слышит: «Ты будешь отвечать за technology», а потом узнает, что основатель по-прежнему утверждает архитектуру, выбор подрядчиков, найм и сроки. Это не ownership. Это ответственность без контроля, и опытные лидеры замечают это быстро.

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

Несколько паттернов повторяются снова и снова:

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

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

Иногда честный ответ меньше, чем обещание в питче. Возможно, компании пока не нужен full-time executive. Возможно, сначала нужен fractional CTO, который разберется с агентством, определит найм и зафиксирует правила принятия решений. Кандидаты обычно уважают такую честность. Сюрпризы они уважают гораздо меньше.

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

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

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

Одной страницы достаточно, если на ней есть то, что обычно ломается:

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

Здесь не нужен отшлифованный текст. Нужен честный текст. Грубая страница, которая говорит правду, лучше красивой вакансии, которая прячет сложные части.

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

Например, если агентство все еще контролирует деплой, мониторинг и контакты с подрядчиками, новый нанятый человек не попадает в чистую leadership-роль. Он попадает в rescue role. Скажите это прямо или исправьте ситуацию заранее.

Если вам нужна внешняя помощь, Oleg Sotnikov может помочь основателям определить зоны ответственности, план найма и практичные AI-first operations еще до того, как они сделают предложение. Такой review обычно дешевле, чем один проваленный поиск, и намного дешевле, чем нанять не того человека в размытую роль.

Следующее собеседование должно начинаться с ясности, а не с убеждения.