Найм CTO для стартапа: когда корпоративные привычки помогают

Почему этот найм быстро становится сложным

Стартапу не нужны лишние уровни управления. Ему нужны ясные решения под давлением.

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

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

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

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

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

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

Чем корпоративный опыт помогает с первого дня

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

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

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

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

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

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

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

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

Какие привычки тормозят маленькую команду

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

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

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

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

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

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

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

Как проверить fit для стартапа на интервью

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

Спросите об одной недавней проблеме, а не обо всей карьере. Возьмите что-то конкретное: сломанный релиз, неудачный найм, скачок облачного счёта или сорванный срок. Держитесь этого примера, пока не услышите, что именно сделал сам кандидат, кого привлёк, что изменилось потом и что бы он сделал иначе.

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

Потом поместите кандидата в условия стартапа. Спросите, что бы он выпустил в первые 30 дней, если есть один продукт-менеджер, четыре инженера и жёсткий бюджет. Лучшие ответы быстро режут объём. Они выбирают одно-два действия, которые снимут боль прямо сейчас: более безопасный процесс релизов, базовую панель ошибок или более чёткие приоритеты для команды.

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

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

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

Что стоит прояснить до оффера

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

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

Прямо обсудите hands on-часть. Некоторые руководители из корпораций годами не трогали код, ревью или реагирование на инциденты. Это может сработать, если вам нужен человек, который выстроит команду и задаст направление. Но это провал, если вы ждёте, что он будет ревьюить pull request’ы, улучшать CI или разбирать продакшн-инцидент во вторник ночью.

Пропишите роль. Стартапу первые несколько месяцев может быть нужно 30 процентов архитектуры, 30 процентов code review, 20 процентов найма и 20 процентов продукта и планирования. Для fractional CTO этот вопрос важен так же. Частичная занятость работает только тогда, когда границы заданы очень точно.

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

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

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

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

Простой сценарий найма

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

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

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

В этом случае практичный ответ прост. Выпустить меньший релиз за две недели. Убрать фичи, которые могут подождать. Исправить один сломанный шаг, который привёл к задержке, будь то тестирование, деплой или ревью. Startup CTO должен сначала сделать следующий релиз безопаснее, а уже потом переделывать всё остальное.

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

Решение обычно сводится к темпу, ownership и диапазону. Может ли человек уже на этой неделе принять полезные решения? Считает ли он срыв релиза своей проблемой? Может ли он помогать с code review, процессом и наймом, не строя мини-оргструктуру?

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

Ошибки, которые основатели совершают при этом найме

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

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

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

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

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

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

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

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

Короткая проверка перед решением

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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