Как оценить внешнего CTO спустя 90 дней без догадок

Почему это ревью часто идет не так

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

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

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

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

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

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

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

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

Что изменилось в продукте

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

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

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

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

Используйте несколько прямых проверок:

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

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

Допустим, стартап начал квартал с 25 пунктами в roadmap. Через 90 дней хороший fractional CTO review должен показать, что три-четыре вещи были выпущены, один болезненный пользовательский сценарий стал короче, а несколько малоценных идей убрали. Может быть, команда отказалась от переделки кастомной админки и вместо этого убрала лишнее трение при регистрации. Это уже реальное движение продукта.

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

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

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

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

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

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

Обратите внимание на такие признаки:

• Меньше сообщений в Slack в духе «я жду...»
• Более быстрые ответы по техническим компромиссам
• Меньше переделок после того, как задача уже собрана
• Понятные владельцы у багов, релизов и архитектуры

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

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

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

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

Что изменилось в расходах и инфраструктуре

Деньги оставляют четкий след. Если вы хотите оценить внешнего CTO через 90 дней, возьмите счета за три месяца до его старта и сравните их с последним полным месяцем. Посмотрите на облачный хостинг, базы данных, мониторинг, CI/CD, сторонние API и лицензии на софт.

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

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

Попросите прямые ответы:

• Какие сервисы были убраны?
• Какие объединили в один инструмент?
• Какие серверы, базы данных или тарифы были подобраны точнее?
• Какие лицензии отменили, потому что ими никто не пользовался?
• Что оставили на месте, потому что удаление создало бы риск?

Лучшие ответы звучат скучно и конкретно. «Мы перешли с четырех небольших баз данных на один управляемый кластер» — это полезно. «Мы оптимизировали инфраструктуру» — это ничего не говорит.

Представим стартап, который тратил 11 000 долларов в месяц на облако, логирование, CI runners и старые SaaS-инструменты. Через 90 дней счет снижается до 7 800 долларов. Это выглядит хорошо, но все равно нужны доказательства: стабильность не упала, число инцидентов не выросло, и команда по-прежнему выпускала продукт вовремя. В таком случае экономия реальная.

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

Как провести 90-дневное ревью

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

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

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

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

Оценка fractional CTO не требует длинной презентации. Лучше работает простая таблица, потому что она заставляет судить четко:

• 0 = явного движения нет
• 1 = изменение частичное, но все еще хрупкое
• 2 = реальное изменение, которое команда может поддерживать без постоянной помощи

Оценивайте каждую из исходных целей по фактам, а не по памяти. «Cloud spend снизился на 22% после правки размеров ресурсов» говорит больше, чем «инфраструктура стала лучше». «Два релиза вышли без авралов на выходных» говорит больше, чем «поставка стала лучше». Если CTO заявлял, что найм стал эффективнее, спросите, стали ли интервью быстрее, понятнее ли стали роли или просто старый процесс переименовали.

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

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

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

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

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

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

К 90-му дню фаундер может назвать несколько простых результатов:

• Отменены 2 неиспользуемых инструмента
• Остановлен 1 слабый проект
• Релизы перешли с поздних ежемесячных батчей на еженедельные обновления
• Стало меньше задач, которые зависают в Slack в ожидании согласования
• Больше времени разработчиков уходит на создание, а не на споры

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

Если part time CTO провел на позиции три месяца, а ничего из этого не изменилось, это уже о многом говорит. Совет, возможно, был. Руководства, скорее всего, не было.

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

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

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

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

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

Используйте доказательства из четырех источников:

• Выпущенные изменения в продукте
• Результаты и распределение ответственности в команде
• Расходы на инфраструктуру или облако
• Нерешенные риски, которые по-прежнему мешают росту

Представьте стартап, у которого теперь лучше стендапы, больше документов и гораздо более оживленный Slack. Фаундер чувствует себя менее одиноким, поэтому CTO кажется эффективным. Но через 90 дней скорость релизов не изменилась, один senior engineer по-прежнему тушит все пожары, счета за облако выросли на 30%, а roadmap все еще состоит в основном из обещаний. Это не сильное fractional CTO review. Это просто более гладкая версия той же проблемы.

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

Короткий чек-лист перед решением

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

Ответьте на эти вопросы примерами, цифрами или и тем и другим:

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

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

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

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

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

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

Обычно лучше всего работает короткий план:

• Выпустить конкретную веху продукта к определенной дате
• Сократить число открытых багов или обращений в поддержку на понятную величину
• Снизить расходы на облако и инструменты до целевой ежемесячной суммы
• Ужесточить командный процесс, например ускорить code review или сократить число заблокированных задач

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

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

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

Иногда самое сложное — получить непредвзятый взгляд. Если вам нужен второй взгляд, Oleg Sotnikov на oleg.is делает именно такой fractional CTO advisory с сильным фокусом на архитектуру продукта, инфраструктуру и практичное внедрение AI. Такой внешний разбор поможет понять, работа хорошая, застопорилась или идет не туда.

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