Разделение ответственности CEO и CTO при жёстком оздоровлении компании

Почему это быстро становится запутанным

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

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

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

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

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

Самое трудное проще, чем люди признают: никто не называет, кто решает споры. CEO часто предполагает, что деньги дают последнее слово. CTO часто считает, что технический риск даёт право решать. Product или ops пытаются сгладить, но это обычно откладывает решение, а не делает его.

Когда компания не определяет разделение, команда придумывает своё. Вот тогда быстро появляются простои, смешанные приоритеты и из‑лишние конфликты.

Сначала выберите одну цель оздоровления

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

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

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

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

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

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

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

Кто отвечает за денежные решения

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

CTO отвечает за расчёт затрат, связанных с технической работой. Это инфраструктура, инструменты, подрядчики, усилия по доставке и реальная стоимость поддержания продукта в стабильности. Хороший CTO не ограничивается «это стоит $12,000 в месяц». CTO объясняет, что сломается, если это опустится до $8,000.

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

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

Если CEO хочет сократить облачные расходы на 35% за 30 дней, CTO может предложить два варианта: сэкономить 20% с низким риском или 35%, убрав резервирование и замедлив деплои. Тогда компромисс становится видимым. CEO может выбрать, зная последствия.

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

Кто отвечает за решения по дорожной карте

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

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

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

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

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

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

Кто отвечает за кадровые решения

CEO задаёт лимит по числу сотрудников и сроки. Если компания может нести только 18 зарплат ближайшие четыре месяца, это решение CEO. Штат начинается как денежное решение.

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

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

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

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

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

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

Кто отвечает за технический риск

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

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

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

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

Хороший CTO обычно хочет исправить больше, чем компания может позволить. Это нормально. CEO должен задать один жёсткий вопрос: какие две‑три проблемы могут повредить доверию или заблокировать продажи, если их не тронуть? Эти решите первыми. Всё остальное должно получить дату, монитор или явное решение «жить с этим» на время.

Установите разделение за одну неделю

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

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

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

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

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

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

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

Простой пример оздоровления

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

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

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

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

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

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

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

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

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

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

У CTO есть своя слепая зона. Некоторые защищают качество кода, не называя бизнес‑стоимости такого решения. Если CTO говорит «сначала это нужно починить», это только половина работы. Он также должен объяснить, во сколько обойдётся задержка, какой риск вырастет, и какое минимальное исправление купит нам 30 дней.

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

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

Короткий еженедельный чеклист

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

• На каждое сложное решение был один владелец.
• Расходы смещались в сторону цели по запасу средств.
• Изменения дорожной карты соответствовали реальности продаж.
• Кадровые решения защищали наиболее хрупкие системы.
• CTO заранее поднимал новые риски.

Не превращайте это в длинный статус‑митинг. Чеклист работает только если он вынуждает действовать. Когда пункт получает «нет», назначьте одного человека исправить это и поставьте дедлайн до конца встречи.

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

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

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

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

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

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

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

Если доверие низкое или те же компромиссы постоянно застревают, короткий внешний обзор может помочь. Oleg Sotnikov at oleg.is работает как Fractional CTO и советник стартапов — такая поддержка помогает разложить технические, продуктовые и кадровые решения без найма постоянного руководителя.

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