Референсы CTO в стартапе: что основателям действительно стоит спрашивать

Почему большинство звонков по референсам не попадают в суть

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

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

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

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

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

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

Сначала решите, что именно вы хотите узнать

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

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

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

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

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

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

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

Как провести звонок шаг за шагом

Хороший звонок по референсам занимает 15–25 минут. Держите его коротким и привязывайте к периоду, когда основатель и CTO достаточно близко работали друг с другом, чтобы видеть друг друга под давлением.

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

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

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

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

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

Заканчивайте вопросом о повторном найме: «Вы бы снова наняли этого человека на вашей нынешней стадии и почему?» Пауза перед ответом часто говорит не меньше, чем сам ответ.

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

Какие вопросы выводят разговор за пределы вежливых ответов

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

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

Спрашивайте простым языком: «Что этот CTO перестал делать после прихода, и был ли это правильный шаг?» «Что он упростил для команды или продукта?» «Что сломалось под его руководством, и как он это исправил?» «Где он сказал нет, когда другие хотели больше функций, больше наймов или больше инструментов?» «Что сначала выглядело хорошо, но потом создало проблемы?»

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

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

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

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

Как звучат сильные ответы

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

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

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

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

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

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

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

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

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

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

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

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

Именно такие детали может раскрыть сильный референс. Бывший основатель может сказать: «Да, они выпускали функции, но больше всего помогло то, что они отказались строить». Этот ответ показывает, что CTO понимал компромиссы, внимание команды и цену хаоса.

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

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

Самый быстрый способ испортить звонок по референсам — попросить характеристику личности. «Она была хороша?» даст вам вежливую похвалу, а не полезную информацию. Почти любой сильный найм звучит умным и приятным первые 20 минут.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать после звонков

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

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

Хорошо работает простой фильтр. Уменьшил ли кандидат лишнее, или просто добавил еще работы? Починил ли он запутанные системы, или только выпускал новые функции? Защищал ли он стабильность, расходы и фокус команды, когда становилось трудно? Сообщал ли он основателям плохие новости заранее? Оставил ли он компанию проще в управлении, чем нашел ее?

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

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

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

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