Как стартапу нанимать CTO: один основатель решает

Почему найм CTO быстро становится запутанным

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

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

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

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

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

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

Дайте каждому интервьюеру свою зону

Основатель не должен нанимать CTO в одиночку, но и группа должна оставаться небольшой. Обычно достаточно трёх голосов: CEO, продуктового лида и сильнейшего senior-инженера. Каждый видит свой тип риска.

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

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

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

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

• Что этот человек хорошо сделает в первые 90 дней?
• Где он может навредить компании?
• Что он доказал примерами?
• Что ещё нужно проверить на следующем этапе?

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

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

Финальное решение должен принимать один основатель

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

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

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

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

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

Назначьте решающего до старта поиска

Большинство процессов найма ломаются по простой причине: никто не знает, у кого последнее слово. Решите это до первого знакомства с кандидатом.

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

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

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

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

Соберите scorecard под вашу стадию

Многие команды ошибаются, когда копируют описание вакансии CTO из большой компании. Это звучит серьёзно, но приводит к размытым интервью и смешанной обратной связи. Стартапу нужна scorecard, которая соответствует работе CTO на ближайшие 12–18 месяцев.

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

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

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

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

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

Используйте две колонки: must have и nice to have. В первую колонку кладите настоящие стоп-факторы и держите её жёстко. Если CTO уже в следующем месяце будет управлять маленькой командой, лидерство должно быть в must have. Если продукт через два года может перейти к другому облачному провайдеру, такой опыт, скорее всего, относится к nice to have.

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

Постройте простой процесс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Личная симпатия тоже мешает. Основатели часто путают «с ним приятно общаться» и «он сможет вести команду под давлением». Кандидат может быть очень удобным в разговоре, но при этом уходить от сложных решений, давать туманные ответы или не вызывать доверия у инженеров. Бывает и наоборот. Сильные CTO иногда говорят прямо, довольно жёстко и намного лучше работают, чем поддерживают small talk.

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

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

Проверка перед оффером

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

Запишите свои три ближайшие технические проблемы простыми словами. Возможно, вам нужно выпустить первый шаткий продукт, распутать запутанный backend и пройти первый серьёзный security review клиента. Если кандидат не может объяснить, как бы он взялся за эти задачи, скорее всего, это не тот найм, даже если собеседование прошло хорошо.

Простой язык важнее отполированной речи. Сильный CTO умеет объяснять компромиссы так, чтобы основатель мог на них опереться. Он должен уметь сказать: «Мы сможем выпустить это за четыре недели, если не раздувать объём, но более быстрый путь создаст работу по переделке потом», и сказать это понятно, без пряток за жаргоном.

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

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

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

Если финальная заметка выглядит натянутой, скорее всего, так и есть.

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

Выделите в календаре 30 минут на этой неделе и уточните роль до того, как поговорите с новыми кандидатами. Большая часть расхождений начинается рано, когда команда видит эту работу по-разному. Один представляет senior-инженера, другой — рекрутера для dev-команды, а третий — продуктового партнёра.

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

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

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

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

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