Первые три встречи CTO с основателями, которые задают четкие правила

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

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

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

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

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

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

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

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

Встреча 1: согласовать бизнес-цели

Начинайте со сроков, а не с инструментов. Спросите основателей, что именно должно улучшиться за 30, 90 и 180 дней. Добивайтесь прямых ответов вроде «закрыть на 10 клиентов больше», «снизить отток» или «выпустить enterprise-план». Не принимайте расплывчатые формулировки вроде «почистить стек» или «модернизировать платформу», если только кто-то не может связать это с бизнес-результатом.

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

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

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

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

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

До конца встречи сведите разговор в короткий список, который все будут читать одинаково:

• 30 дней: исправить отвал на онбординге и запустить тест цены
• 90 дней: поддержать sales-пуш двумя обещанными изменениями продукта
• 180 дней: снизить нагрузку по инцидентам и сократить самый тяжелый долг по надежности
• Основные метрики: квалифицированные демо, конверсия, ежемесячный отток
• Принятые компромиссы: отложить менее важную уборку, если она не защищает поставку или выручку

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

Встреча 2: установить права на решения

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

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

Четкое разделение часто выглядит так:

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

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

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

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

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

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

Встреча 3: назвать владельцев проблем

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

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

Полезный список может выглядеть так:

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

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

Это также момент, чтобы отделить симптомы от причин. «Мы постоянно срываем сроки» — это симптом. Причиной может быть постоянная смена объема, слабые спецификации, плохая дисциплина релизов или слишком мало инженеров под план. «Качество плохое» — тоже симптом. Причиной может быть отсутствие тестов, спешка в ревью или слабая ответственность после инцидентов.

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

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

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

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

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

Как провести эти встречи за одну неделю

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

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

Хорошо работает простой ритм:

• понедельник: бизнес-цели
• среда: права на решения
• пятница: владельцы проблем

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

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

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

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

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

Простой пример маленького стартапа

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

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

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

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

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

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

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

Ошибки, которые создают трение

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

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

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

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

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

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

Во время этих встреч помогает короткая проверка:

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

Это не замедляет компанию. Это не дает маленьким недопониманиям превратиться в еженедельные споры.

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

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

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

Используйте короткую проверку «да» или «нет»:

• Может ли каждый основатель назвать три главные цели без подсказки?
• Понимают ли все, какие решения CTO может принимать сам, а какие все еще требуют согласования основателей?
• У каждой крупной проблемы есть один владелец?
• Записала ли команда компромиссы за каждым изменением процесса и срок его пересмотра?
• Может ли кто-то объяснить в одной-двух простых фразах, почему это изменение важно именно сейчас?

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

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

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

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

Что делать после встреч

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

Включите четыре вещи:

• бизнес-цели на ближайшие 90 дней
• кто какие решения принимает
• кто отвечает за каждую текущую проблему
• первое изменение, которое команда протестирует

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

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

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

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

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

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