Первая встреча с новым техническим лидером: чек-лист для CEO

Почему первая встреча буксует

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

Если CEO говорит: «нам нужно лучшее удержание», но не приносит данные по оттоку, активации, объёму обращений в поддержку или длине цикла продаж, люди заполняют пробелы своими предположениями. Один слышит проблему продукта. Другой — проблему инженерии. Кто-то ещё думает, что дело в онбординге. Встреча кажется продуктивной, но люди уходят с разными целями в голове.

Следующий стопор создают обещания клиентам. Звонки продаж, письма основателя, обновления для инвесторов и треды поддержки часто содержат маленькие обязательства, которые так и не собрали в одном месте. Одному клиенту могли пообещать SSO в следующем квартале. Другой ждёт кастомную интеграцию. Крупный потенциальный клиент может считать, что audit logs вот-вот будут готовы. Пока эти обещания разбросаны, новый технический лидер начинает разбор с неполной картой.

Третья неожиданность — ограничения поставщиков. Команды часто планируют исходя из того, что они хотят от своих инструментов, а не из того, что на самом деле позволяют контракты, rate limits, правила работы с данными или ценовые уровни. Потом технический лидер предлагает roadmap, и только после этого кто-то вспоминает про заблокированного платёжного провайдера, дедлайн по cloud credits или контракт, который не даст мигрировать ещё шесть месяцев. Это может перечеркнуть недели работы.

Встречи также буксуют, когда одни и те же слова означают разное. «Запуск» для CEO может быть приватной бета-версией, для инженерии — релизом в продакшен, а для продаж — подписанным контрактом. «AI-фича» может означать демо-помощник, а может — рабочий процесс, который должен стабильно работать каждый день для платящих клиентов. Маленькие расхождения в формулировках превращаются в дорогие расхождения в ожиданиях.

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

Какие бизнес-факты нужно принести

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

Начните с выручки простыми словами. Разбейте её по продуктовым линиям, сегментам клиентов или крупным аккаунтам — по тому варианту, который сильнее всего влияет на ежедневные решения. У компании с одним флагманским продуктом и двумя крупными enterprise-клиентами совсем другой профиль рисков, чем у компании с 5000 маленьких self-serve пользователей.

Затем чётко покажите маржу и денежный запас. Назовите gross margin, ежемесячный burn и runway как реальные цифры, а не приблизительные ощущения. Если у команды осталось девять месяцев денег, технические решения сразу меняются. Лидер, который знает runway, будет иначе смотреть на найм, расходы на облако, переписывание системы и контракты с поставщиками.

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

Обязательства продаж часто скрывают главный риск. Если pipeline зависит от функций, интеграций, compliance-задач или помощи с миграцией, связывайте эти сделки с датами поставки. «Три сделки хотят это» — слишком размыто. «Два подписанных контракта зависят от SSO до Q3» — уже полезно.

Какие обещания по продукту нужно перечислить

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

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

Запишите их простым языком. Начните с того, что клиенты уже считают правдой. Это включает функции, которые sales называли «скоро будут», даты запуска, упомянутые в демо или интервью, обещанные в договорах uptime или response targets, а также любые заявления о безопасности и compliance, которые команда использует в питчах.

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

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

Именно здесь первая встреча либо экономит недели, либо теряет их. «Нам скоро нужен SOC 2» — слишком размыто, чтобы действовать. «Sales уже говорит клиентам, что у нас есть audit trails, role-based access и SSO, и в двух контрактах это нужно к Q3» — это уже конкретика, с которой можно разбираться.

Небольшой пример из SaaS хорошо показывает суть. Компания может думать, что следующая задача — обновить дашборд. Потом новый CTO видит три подписанные сделки, зависящие от API-доступа, слайд публичного вебинара, где пообещали мобильное приложение к июню, и master service agreement с целевым уровнем uptime 99,9%. Приоритеты меняются сразу.

Если вы привлекаете внешнего советника или fractional CTO, этот список ещё важнее. Видение задаёт разговор. Обещания определяют график.

Какие ограничения поставщиков нужно показать

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

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

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

Плата за использование часто прячется и в инструментах, которые сначала кажутся дешёвыми. API calls, storage, SMS и premium support нередко создают неожиданные расходы. Если клиентская функция зависит от поставщика с высокой платой за перерасход, это быстро меняет план продукта.

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

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

Для каждого инструмента достаточно короткой заметки: дата продления и срок уведомления, ежемесячная стоимость и модель оплаты, минимальный объём seats или обязательство по расходам, ограничения на export и hosting, а также контакт поддержки или маршрут эскалации.

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

Как подготовить пакет для встречи

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

Соберите цифры у команд, которые каждый день работают с выручкой и поставкой. Finance должны принести текущую выручку, gross margin, burn, cash runway и любые резкие скачки затрат. Sales — размер pipeline, показатели закрытия сделок, средний размер сделки и всё, что было обещано ради последних продаж. Support — объём тикетов, основные типы жалоб, время ответа и несколько проблем, которые повторяются снова и снова. Ops добавит ручную работу, точки отказа и сроки, которые команда не может пропустить.

Сложите всё это в один документ и добавьте ещё два раздела: обещания по продукту и ограничения поставщиков. Сделайте его достаточно коротким, чтобы прочитать за один заход. Если sales пообещали SSO к июню — отметьте это. Если крупнейший клиент ждёт audit logs до продления — тоже отметьте. Если контракт поставщика блокирует миграцию ещё на девять месяцев, поместите это рядом с обещанием, а не в юридическую папку, которую никто не открывает.

Чётко подпишите каждую строку. Одни пункты — факты, например ежемесячная recurring revenue или подписанная дата продления. Другие — предположения, например «мы думаем, что churn растёт из-за слабого онбординга». Третьи — открытые вопросы, например распространяется ли обещание по data export на все тарифы или только на enterprise-сделки. Такая простая маркировка помогает избежать долгих споров на встрече.

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

Закройте пакет тремя первыми решениями, которые вам нужны. Например:

• Что нужно выпустить в ближайшие 90 дней
• Какие vendor lock-in можно пока оставить
• Где команда должна сначала сократить расходы

Так первая встреча станет рабочей сессией, а не марафоном по сбору вводных.

Простой пример из SaaS-компании

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

Sales уже пообещали single sign-on и помощь с миграцией обоим аккаунтам. Это меняет первую неделю разбора. Auth поднимается в самый верх списка, потому что SSO затрагивает login flow, роли пользователей, требования к audit и иногда формулировки в контракте. Важна и работа по migration, потому что неудобный импорт может превратить подписанную сделку в зависший запуск.

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

Поддержка добавляет ещё одно ограничение. У premium-клиентов в контрактах зафиксированы сроки ответа. Значит, не каждая ошибка одинаково важна. Проблема с логином в 9 утра для premium-аккаунта может быть важнее, чем мелкая UI-ошибка, которая затрагивает всех остальных. Если новый лидер видит это обязательство по поддержке в первый день, он раньше начнёт смотреть на paging, нагрузку on-call и маршруты эскалации, а не на новые функции.

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

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

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

Ошибки, которые сжигают первый месяц

Плохой старт редко бывает из-за одной крупной проблемы. Обычно это набор маленьких привычек, которые делают разбор медленным, запутанным и политизированным.

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

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

Следующая ошибка — просить roadmap, не объяснив ограничения. CTO или fractional CTO нужен сам «короб», прежде чем он нарисует план. Бюджет, размер команды, сроки, правила compliance, заморозка найма и vendor lock-in — всё это влияет на ответ. Если эти ограничения всплывают на третьей неделе вместо первого дня, ранний план сразу летит в корзину.

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

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

Простое правило помогает: уходите со встречи с назначенными ответственными, реальными цифрами и коротким письменным summary. Это делает передачу CTO намного лучше, чем любой вылизанный стратегический deck.

Короткий чек-лист перед входом на встречу

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

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

Запишите известные сбои, проблемы безопасности, медленные части продукта и старый технический долг, о котором команда уже говорит, но ещё не исправила. Потом назовите людей, которые смогут ответить на недостающие вопросы. Поставьте одного ответственного рядом с направлениями product, sales, support, finance, data и infrastructure.

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

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

Обещания клиентам важны, потому что они превращаются в инженерную работу, работу поддержки и юридический риск. Если продавец пообещал SSO на следующий месяц, или крупный клиент ждёт audit logs до продления, технический лидер должен услышать это в первый же день.

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

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

Что делать в следующие 7 дней

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

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

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

Полезны короткие интервью. Запланируйте 20-минутные звонки с sales, support и product в ту же неделю. Спросите sales, где сделки тормозятся или теряются. Спросите support, какие проблемы повторяются каждую неделю. Спросите product, какие обещания уже есть на рынке. И у всех трёх команд спросите, что сильнее всего навредит клиентам, если сломается завтра.

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

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

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

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