Онбординг CTO в стартапе: что совету директоров нужно сообщить первым

Почему новый CTO может начать не с той ноги

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

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

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

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

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

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

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

Именно поэтому онбординг CTO в стартапе часто идёт наперекосяк. Сбой начинается не с техники. Он начинается с неполной вводной.

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

Что совет директоров должен рассказать до первой недели

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

Начните с запаса денег. Дайте точную картину простыми числами: сколько денег в банке, какой ежемесячный расход, на сколько месяцев хватит средств и в какой точке расходы нужно будет замедлить. Фраза «денег примерно на год» слишком размытая. «У нас 1,8 млн долларов, мы тратим 150 тыс. в месяц, и мы хотим сохранить 12 месяцев запаса после любого нового найма» — это уже информация, с которой CTO может работать.

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

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

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

Например, совет может сказать:

• Один крупный корпоративный клиент подпишет договор, если в этом квартале выйдет SSO.
• Продление контракта зависит от более стабильной работы и более удобных инструментов поддержки.
• Для партнёрской сделки нужны audit logs и доступ по ролям.

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

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

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

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

Как передать всё это в первую неделю

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

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

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

Воронка продаж важна не меньше. Покажите CTO, какие сделки почти закрыты, какие шаткие и что клиентам уже пообещали. Именно здесь многие передачи контекста ломаются. CTO может увидеть аккуратное техническое исправление как главную задачу, а отдел продаж в это время ждёт SSO, audit logs или одну интеграцию, которая закроет два контракта в этом квартале.

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

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

Закончите неделю коротким письменным списком компромиссов, за которые теперь отвечает CTO. Пусть он будет кратким:

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

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

Цифры, которые меняют технические решения

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

Валовая маржа обычно первая цифра, которая меняет дорожную карту. Если цель — 75%, а бизнес сейчас на уровне 58%, CTO должен знать об этом в первый день. Этот разрыв влияет на выбор хостинга, сторонних инструментов, хранение данных и даже на объём продукта. Команде, которая не выполняет целевые показатели маржи, стоит дважды подумать, прежде чем добавлять дорогие managed-сервисы или строить функции, которые увеличат расходы на поддержку и инфраструктуру.

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

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

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

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

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

SaaS-компания нанимает нового CTO в апреле. Совет давит на две корпоративные сделки до конца квартала, и оба покупателя говорят одно и то же: они не начнут закупку, пока в продукте не появятся audit logs и SSO.

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

Наедине это выглядит умно. Но для этого квартала это неверный ход.

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

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

• добавить audit logs для тех действий, которые покупатели хотят проверять
• выпустить SSO для тех identity providers, которые названы в сделках
• исправить несколько проблем с производительностью, влияющих на демо и онбординг
• отложить масштабную переработку до закрытия квартала или переноса сделок

Это не гламурная работа. Но часто именно она и нужна.

Представьте цифры. Шестичленная инженерная команда тратит восемь недель на частичный рефакторинг. Это может стоить дороже ожидаемой годовой прибыли от одной сделки, особенно если у компании и так тонкая маржа. Если же команда за три недели выпустит audit logs и SSO, продажи смогут двигаться дальше, закупка начнётся, а у компании останется пространство для манёвра.

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

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

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

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

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

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

Скорость создаёт другую проблему, когда никто не называет ограничения по марже. Основатели говорят: «Нам нужно двигаться быстрее», — но не говорят, что расходы на облако не могут превысить определённую сумму или что команда поддержки и так на пределе. Тогда CTO выбирает технический путь, который быстро выпускает продукт, но добавляет расходы, которые бизнес не потянет. Быстро — не значит полезно, если каждый новый клиент делает компанию менее прибыльной.

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

Одни и те же ошибки повторяются снова и снова:

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

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

Ясность не делает работу легче. Она делает решения чище.

Быстрая проверка перед первыми 30 днями

К 20-му дню совет и основатель должны попросить CTO пересказать план простыми словами. Если ответ звучит расплывчато, передача контекста не сработала. CTO сможет узнать глубже всё позже, но с самого начала ему нужна ясная рамка для компромиссов.

Короткая проверка лучше, чем ещё один длинный deck. Выделите 30 минут и задайте пять прямых вопросов:

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

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

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

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

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

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

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

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

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

Соберите бизнес-ограничения в одном месте. Для онбординга CTO в стартапе обычно достаточно одной страницы, если она понятная и актуальная.

В ней должно быть несколько жёстких фактов:

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

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

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

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

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

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

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

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