Карта результатов CTO: определите цели до найма CTO

Почему этот найм идет не так

Наем CTO часто проваливается еще до первого собеседования. Сама роль слишком расплывчатая.

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

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

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

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

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

Что должна отвечать карта

Карта результатов CTO должна отвечать на один простой вопрос: что именно этот человек должен изменить в бизнесе за следующие 12 месяцев?

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

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

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

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

• к 90 дням определите, чему он должен научиться, что остановить и что разблокировать;
• к 6 месяцам определите, что должно работать лучше каждую неделю;
• к 12 месяцам определите, какие цифры должны измениться.

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

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

Поставьте цели по темпу поставки

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

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

• время от одобренной работы до выхода в продакшн;
• частота релизов в неделю или в месяц;
• доля запланированной работы, которая выходит в тот же спринт или месяц.

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

Записывайте цель простым языком. «Сократить медианное время с 18 дней до 10 дней за шесть месяцев» — это полезно. «Ускориться в 10 раз» — это фантазия.

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

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

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

Поставьте цели по здоровью команды

Здоровье команды видно в ежедневной работе. Это не про то, насколько люди милы на собеседовании.

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

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

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

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

Это намного лучше, чем просить о «культурном совпадении» или о «сильном лидере». Такие слова почти ничего не значат и только размывают интервью.

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

Поставьте цели по рискам системы

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

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

Достаточно небольшого набора показателей:

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

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

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

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

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

Поставьте цели по марже

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

Используйте понятные бизнес-цифры. Выберите валовую маржу, операционную маржу или обе. Затем опишите, как CTO может повлиять на них в следующие 6–12 месяцев.

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

Это делает собеседования точнее. Вместо вопроса «Можете ли вы оптимизировать расходы?» спросите: «Как вы сократили бы лишние траты на 15% и при этом не замедлили бы релизы и не повысили риск инцидентов?»

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

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

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

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

Превратите цели в вопросы на собеседовании

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

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

Хорошо работает простой набор вопросов:

• Темп поставки: «Расскажите о команде, которая выпускала слишком медленно. Что вы изменили в первые 90 дней?»
• Здоровье команды: «Расскажите о команде с низким доверием или слабой ответственностью. Как вы с этим работали?»
• Риски системы: «Расскажите о системе, которая казалась хрупкой. Что вы починили в первую очередь и почему?»
• Маржа: «Расскажите о продукте или платформе, которая стоила слишком дорого в обслуживании. Где вы сократили лишние расходы, не ухудшив сервис?»

Эти вопросы намного лучше, чем «Каков ваш стиль лидерства?». Общие ответы отполированы и их трудно оценить. Истории о похожих проблемах гораздо труднее подделать.

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

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

Простой пример для небольшой software-компании

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

Основателю нужна не просто скорость. Ему нужны меньше задержек без роста количества сбоев. И еще он хочет, чтобы команда перестала жить в Slack по вечерам.

Карта результатов CTO делает эту работу конкретной. Вместо просьбы «улучшить инженерию» она задает несколько понятных результатов на первые два квартала:

• сократить среднее время от одобренного кода до релиза в продакшн с 10 дней до 3;
• снизить расходы на облако на 15–20 процентов без замедления продукта;
• уменьшить экстренные сообщения вне рабочего времени;
• назначить четкого владельца для каждого сервиса, пайплайна и пути обработки клиентской проблемы.

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

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

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

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

Ошибки, которые ослабляют карту

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

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

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

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

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

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

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

Короткая проверка перед стартом собеседований

Слабая карта делает собеседования шумными. Люди задают широкие вопросы, ставят оценки по интуиции, а потом спорят о том, кто «ощущался более senior».

Хороший черновик проще. Прочитайте каждую строку результата через пять фильтров:

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

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

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

Что делать после того, как черновик готов

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

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

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

Удобный вариант передачи выглядит так: поделитесь картой со всеми интервьюерами, превратите каждую цель в план на 30, 60 и 90 дней, используйте ее снова на первой оценке результатов и храните датированную копию, чтобы позже можно было обновить ее с учетом контекста.

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

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