Почему найм CTO проваливается даже после отличного интервью

Почему отличное интервью не спасает плохую роль

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

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

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

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

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

Перед подписанием помогает простой тест.

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

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

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

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

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

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

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

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

Перед тем как кого-то интервьюировать, опишите роль простыми словами:

• Что этот человек будет делать в обычную неделю?
• Сколько времени должно уходить на код, найм и планирование?
• Кто принимает финальные решения по продукту и техническим компромиссам?
• Что этот человек должен взять на себя через 30, 90 и 180 дней?

Если вы не можете ответить на эти вопросы без общих фраз, значит, роль все еще размыта. Во многих ранних стартапах честный ответ — не «нам нужен CTO». Возможно, правильнее будет сказать: «нам нужен сильный lead engineer» или «нам нужен fractional CTO advice на несколько месяцев».

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

Где контроль основателя запускает конфликт

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

Основатель может сказать: «Технологии теперь твои», — и при этом все равно ожидать, что он будет утверждать каждое изменение roadmap, каждого senior-инженера и каждый счет свыше небольшой суммы. CTO слышит доверие. Основатель имеет в виду управляемое выполнение. И этот разрыв быстро начинает болеть.

Первой точкой напряжения обычно становится управление roadmap. Если меняется план продукта, кто говорит «да»? Некоторые основатели хотят сами утверждать все, что связано с продажами, ценами или датами запуска. Это нормально, но границы должны быть прописаны. CTO должен понимать, может ли он перестраивать приоритеты внутри согласованного плана или любое изменение снова уходит к основателю.

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

Найм показывает ту же проблему. CTO обычно ожидает, что сможет формировать команду, особенно когда речь идет о senior-ролях. Если основатель хочет иметь право вето на каждого lead-инженера или platform-инженера, это стоит проговорить еще на интервью. Скрытое право вето потом воспринимается как недоверие.

Помогает короткая карта решений:

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

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

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

Определите критерии успеха до первого дня

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

Большинство основателей говорят о целях очень широко: «работать быстрее», «починить команду» или «навести порядок в продукте». В разговоре это звучит нормально, но после старта работы все разваливается. Новому CTO нужны 3–5 понятных результатов на первые 90 дней, а не расплывчатое обещание «отвечать за технологии».

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

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

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

• частота релизов растет с одного раза в 3 недели до одного раза в неделю
• количество инцидентов в продакшне снижается с 6 в месяц до 2
• срок закрытия инженерной вакансии сокращается с 90 до 45 дней
• точность roadmap улучшается, и минимум 80% запланированной работы выходит вовремя
• время реакции на крупные баги сокращается с 2 дней до 4 часов

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

Простое правило такое: если у CTO нет полномочий сдвинуть метрику, не используйте эту метрику для оценки его работы.

Здесь fractional CTO advice часто особенно полезен. Внешний специалист может заметить цели, которые звучат умно, но в реальной компании работать не будут. Такой быстрый взгляд на реальность экономит месяцы обвинений, раздражения и очень дорогой ошибки найма.

Как проверить совпадение еще до найма

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

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

Добавьте простые вопросы:

• Кто утверждает изменения архитектуры?
• Кто может принимать решения по найму?
• Сколько времени CTO должен тратить на код?
• Какого результата должно быть видно через 90 дней?

Потом попросите кандидата пройтись по первым 30 дням. Серьезный человек сразу начнет выбирать приоритеты. Один кандидат начнет со стабильности релизов и доверия в команде. Другой сразу уйдет в найм, изменение процессов и новый стек. И ни один из подходов не является неправильным сам по себе. Он работает только тогда, когда совпадает с тем бизнесом, который у вас есть на самом деле.

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

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

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

Иногда честный ответ в том, что полноценный CTO вам пока не нужен. Возможно, вам нужен сильный engineering lead или fractional CTO advice, чтобы сначала сформировать роль. Oleg Sotnikov часто работает с компаниями именно на этом этапе, когда должность звучит понятно, но повседневная работа все еще размыта.

Если описание роли, план на 30 дней и кризисный сценарий ведут в одну сторону, значит, совпадение есть. Если нет — перепишите роль до того, как отправлять оффер.

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

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

На бумаге цель проста: выпускать быстрее.

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

Основатель по-прежнему хочет утверждать почти все. В том числе:

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

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

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

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

Через два месяца обе стороны считают, что наняли не того человека. Основатель говорит: «Нам нужен был кто-то более практический». CTO говорит: «Меня наняли руководить, но мне так и не дали пространство для этого».

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

Ошибки, которые ломают роль уже после оффера

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

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

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

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

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

Короткое письменное соглашение должно отвечать на четыре вопроса:

• Чем CTO владеет без согласования
• Что все еще требует подтверждения основателя
• Что важно в первые 90 дней
• Как измеряется успех

Границы, которые появляются после первого конфликта, обычно уже запаздывают. Лучше задать их до первого дня. Даже короткая карта ответственности способна предотвратить месяцы трения.

Здесь fractional CTO тоже может помочь. Человек с операционным опытом, например Oleg Sotnikov, часто быстро видит плохую постановку роли, потому что узор знаком: не сотрудник слабый, а роль сделана неаккуратно.

Быстрые проверки перед отправкой оффера

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

Проведите одну встречу с основателем и кандидатом вместе. Говорите прямо.

• Попросите основателя в одном предложении объяснить, зачем CTO нужен именно сейчас. «Нам нужен технический человек» — это не ответ. «Нам нужен один человек, который возьмет на себя архитектуру, поставку и найм инженеров, потому что основатель больше не может делать все три роли» — это уже честный ответ.
• Попросите обе стороны отдельно записать три главные обязанности роли. Сравните списки. Если основателю нужен builder, а кандидат думает, что его наняли руководить командой, это нужно исправить до подписи.
• Попросите основателя прямо назвать решения, которые он перестанет контролировать. Это могут быть технический найм, проектирование систем, приоритеты sprint-плана или выбор подрядчиков. Если основатель по-прежнему хочет последнее слово вообще во всем, должность значит очень мало.
• Попросите кандидата показать план на первый квартал с учетом реального бюджета. Хороший план показывает компромиссы. В нем видно, что человек починит первым, что может подождать и какой headcount ему пока не нужен.
• Попросите объяснить, по каким признакам будет судить об успехе к третьему месяцу. Подойдут несколько метрик, если обе стороны с ними согласны: более быстрые релизы, меньше сбоев, понятный план найма, ниже облачные расходы или более спокойная команда.

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

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

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

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

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

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

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

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

Слушайте прямые ответы. Если кандидат описывает не ту работу, которая у вас в голове, это полезно. Вы нашли проблему до оффера, а не после него.

Если вы все еще хотите, чтобы в одном человеке были основатель, head of engineering, product lead, recruiter и senior architect, лучше отложите найм. Это не одна ясная роль CTO. Это несколько должностей, запихнутых в одну должность, и обычно это заканчивается конфликтом основателя и CTO, потому что полномочия никогда не совпадают с ответственностью.

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

Хороший процесс интервью важен. Но еще важнее ясная роль. Если черновик все еще кажется туманным, сначала исправьте черновик.