Роли основателя и фракционного CTO: кто что решает первым

Почему это быстро превращается в конфликт

Этот конфликт возникает рано, потому что на основателя и фракционного CTO давят разные вещи.

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

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

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

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

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

Работа на неполный день добавляет еще один слой. Фракционный CTO не бывает на каждом совещании, поэтому люди заполняют пробелы догадками. Кто-то что-то обещает на звонке. Кто-то другой говорит «нет» в Slack. Через неделю оба уверены, что другой человек изменил план.

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

Сначала определите зону основателя

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

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

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

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

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

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

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

Определите зону CTO

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

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

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

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

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

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

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

Разложите решения по одному владельцу

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

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

На практике основатель должен отвечать за приоритеты roadmap. Именно основатель решает, какая бизнес-ставка важнее сейчас: выручка, удержание, дата запуска, enterprise-функции или контроль расходов. CTO может возражать по поводу объема работ и рисков, но не должен выбирать бизнес-ставку компании.

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

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

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

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

Запишите это простыми словами. Одного предложения на каждое решение достаточно.

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

Соберите разделение на одной встрече

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

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

Для встречи обычно хватает пяти вопросов:

• Кто принимает финальное решение по приоритетам roadmap?
• Кто может утверждать нового инженера или подрядчика?
• Какие расходы на инструмент или поставщика CTO может одобрить сам?
• Кто первым отвечает на ночные и выходные инциденты?
• Когда обоим нужно сначала поговорить, прежде чем кто-то начнет действовать?

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

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

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

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

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

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

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

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

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

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

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

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

Ошибки, из-за которых споры повторяются

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

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

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

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

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

Обычно сигналы тревоги хорошо заметны. Инженеры спрашивают, кто должен утверждать одну и ту же задачу. Финансы не знают, кто может сказать «да» новым инструментам. Приоритеты продукта меняются прямо во время инцидентов. Работа начинается до того, как обе стороны согласовали, зачем она нужна.

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

Быстрая проверка до того, как проблемы вырастут

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

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

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

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

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

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

Поставьте 45 минут в календаре на этой неделе и завершите встречу письменной картой решений. Короткая встреча сейчас дешевле, чем один спор во время релиза, активного найма или неожиданного счета.

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

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

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

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

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

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

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