Как нанять CTO, сначала определив реальное узкое место

Один титул CTO не решает узкое место

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

Титул сам по себе ничего из этого не исправляет. Команде нужен человек, который снимет блокер. Пропустите этот шаг — и вы нанимаете ради статуса, а не ради соответствия задаче.

Одному стартапу нужен строитель, который приведёт в порядок архитектуру и сможет выпускать продукт небольшой командой. Другому нужен менеджер, который расставит приоритеты, грамотно наймёт людей и не даст продуктовой работе превратиться в хаос. Третьему может вообще не понадобиться руководитель на full-time. Ему может хватить fractional CTO на несколько месяцев, чтобы наладить delivery, выбрать стек и выстроить процесс, которому действительно можно следовать.

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

О реальной проблеме часто можно услышать в обычных словах:

• «Наш продукт нестабилен.»
• «Мы не успеваем выпускать вовремя.»
• «Команда постоянно переделывает одно и то же.»
• «Расходы на облако всё время растут.»
• «Никто не может превратить идеи основателя в технический план.»

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

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

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

Найдите узкое место простыми словами

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

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

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

Обычно помогают несколько простых вопросов:

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

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

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

Если вы пока не можете написать такое предложение, вы ещё не готовы нанимать. Вы всё ещё описываете боль, а не узкое место.

Типичные узкие места, которые стоят за поиском CTO

Большинству компаний нужен не «CTO вообще», а решение одной конкретной проблемы.

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

Иногда проблема в delivery. Продукт понятен, но релизы всё равно срываются. Pull request’ы слишком долго ждут, планирование слабое, тестирование начинается поздно, и никто не отвечает за инженерные привычки. Обычно это связано не столько с талантом, сколько с ежедневной дисциплиной.

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

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

AI-проекты создают новую версию той же проблемы. У компании может быть перспективный прототип для поддержки, продаж или внутренней автоматизации, но никто не понимает, как добавить проверки, мониторинг, fallback-логику и контроль затрат. Демонстрация вызывает аплодисменты, а потом умирает ещё до запуска.

Закончите это предложение до того, как писать роль: «Нам нужен этот человек, потому что...». Если ответ всё ещё звучит расплывчато, то и роль расплывчатая.

Диагностируйте проблему по недавней работе

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

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

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

Человек, который всё спасает, важнее, чем кажется большинству команд. Если постоянно вмешивается основатель, возможно, команде не хватает владельца решений. Если один senior engineer постоянно вытаскивает релизы, проблема может быть в техническом направлении или в слабых привычках delivery. Если продажи или продукт регулярно латют один и тот же бардак, проблема может лежать за пределами engineering.

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

У небольшого стартапа это может выглядеть так: Project A замедлился, потому что никто не выбрал стек. Project B застопорился, потому что два инженера неделю спорили о system design. Project C был выпущен только потому, что основатель проверял каждое техническое решение. Это не значит «нанять гениального CTO». Это значит, что компании не хватает ясной технической ответственности и способа принимать решения.

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

Выберите правильный уровень найма

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

Нанимайте senior engineer, если основная боль — в качестве кода, медленном выпуске или нехватке глубины на самых сложных технических задачах. Нанимайте engineering manager, если команде нужна структура, ответственность и более стабильное исполнение. Привлекайте fractional CTO, если бизнесу нужен senior-уровень технического взгляда на архитектуру, найм, подрядчиков, безопасность, внедрение AI или контроль затрат, но не нужен CTO каждую минуту каждого дня. Нанимайте full-time CTO, когда техническое лидерство затрагивает продукт, команду, архитектуру и бюджет каждую неделю, а иногда и каждый день.

Неправильный уровень создаёт новые проблемы. Senior engineer, поставленный в стратегический пробел, застрянет. Full-time CTO, нанятый ради узкой проблемы с delivery, обойдётся слишком дорого и часто начнёт делать работу ниже своего уровня.

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

Пишите роль через результаты, а не через черты

Большинство плохих описаний CTO выглядят как объявления о личности. В них ищут кого-то «стратегического», «практичного» и «инновационного», а сама работа остаётся размытой. Это замедляет найм и привлекает не тех людей.

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

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

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

Именно здесь многие основатели застревают. Они пишут широкий титул для узкой проблемы. Если масштаб ограничен, так и скажите и подберите найм под него. Человек, нанятый как full CTO, не должен попадать в роль, где он отвечает только за sprint planning и чистку работы с подрядчиками.

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

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

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

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

В то же время клиенты начинают замечать короткие сбои и неровные deploy’ы. Первыми жалобы слышит support. Engineering бросается тушить пожары. Никто не отвечает за надёжность, поэтому те же проблемы возвращаются через несколько недель.

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

Частичный CTO на этом этапе часто подходит лучше, чем full-time executive. Работа здесь практическая: установить правила, кто что решает, создать процесс релизов, которому команда сможет следовать каждую неделю, назначить одного ответственного за uptime и разбор инцидентов, помочь нанять или обучить тимлидов и снять рутинные технические решения с плеч основателя.

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

Через несколько месяцев компания яснее видит следующий шаг. Иногда ей действительно нужен full-time CTO. Иногда ей были нужны структура, более сильный найм и более спокойный способ управлять engineering. Гораздо дешевле понять это заранее, чем после дорогого executive-наёма.

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

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

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

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

Найм ради статуса тоже создаёт проблемы. Некоторые основатели добавляют титул, потому что инвесторы ожидают увидеть CTO в команде. Ущерб становится заметен позже. Новый человек приходит и понимает, что не может менять roadmap, отклонять плохую архитектуру, перестраивать найм или контролировать бюджет. Титул без полномочий — это просто будущий конфликт.

Размытые полномочия — один из самых быстрых способов потерять хорошего человека. Если основатель по-прежнему держит за собой каждое техническое решение, выбор подрядчиков и найм, CTO мало что сможет сделать. Он превращается в senior adviser с ожиданиями full-time и властью part-time.

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

Небольшой пример делает проблему очевидной. Компания с десятью инженерами нанимает «CTO», чтобы ускорить delivery. Но основатель всё ещё контролирует roadmap, lead developer блокирует изменения в коде, а operations утверждает инструменты. Через шесть месяцев скорость релизов остаётся прежней. Слабым был не нанятый человек. Слабой была роль.

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

Проверьте роль до публикации вакансии

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

До публикации роли ответьте на пять простых вопросов:

• Можете ли вы назвать узкое место одним предложением как бизнес-проблему, а не как титул?
• Что должно измениться через 90 дней?
• Какие полномочия, бюджет и линия подчинения будут у этого человека?
• Почему это full-time, part-time или fractional роль?
• Какие обязанности должны остаться у других ролей и не попадать в эту работу?

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

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

Если вы всё ещё сомневаетесь

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

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

Короткий advisory engagement может прояснить это быстрее, чем ещё один месяц внутреннего спора. Дайте консультанту доступ к roadmap, структуре команды, истории delivery и текущим техническим болям. Попросите не презентацию, а простой план. Такая ранняя работа быстро показывает, нужен ли вам full-time CTO, fractional CTO или более сильный engineering manager с внешней поддержкой.

Если вам нужен такой внешний взгляд перед senior-наймом, Oleg Sotnikov на oleg.is занимается именно fractional CTO и startup advisory. Он смотрит на узкое место, масштаб роли, архитектуру, проблемы delivery и помогает понять, нужен ли бизнесу full-time CTO уже сейчас.

Когда проблема становится ясной, найм обычно упрощается. Роль сужается. Собеседования становятся лучше. Шансы на хорошее совпадение растут.