Фракционный CTO против советника: когда полномочия должны сместиться

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

Основатель может сказать: «Мне просто нужен совет», имея в виду: «Скажи, что делать, и будь рядом, если что‑то пойдёт не так». Этот разрыв быстро создаёт проблемы.

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

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

Риск не только в плохом решении. Более крупная проблема — задержка с решением, когда команде нужна скорость и ясность.

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

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

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

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

Как выглядит коучинг в повседневной работе

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

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

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

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

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

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

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

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

Когда лучше подходит частичное руководство

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

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

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

Инженерный менеджер, технический лид или старшие разработчики по‑прежнему отвечают за исполнение. Они ведут стендапы, разбивают работу на задачи, ревьюят пулл‑реквесты и решают повседневные вопросы. Частичный лидер проверяет ход по установленному ритму, а не «висят» над командой.

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

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

Частичный лидер помогает сузить опции и задать ясный путь.

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

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

Когда имеет смысл полный операционный контроль

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

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

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

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

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

Самая безопасная версия — ограниченная по времени. Установите условия до начала работы, а не в разгар пожара.

Установите рамки заранее

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

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

Именно такой работой занимается Oleg Sotnikov с командами стартапов. Его бэкграунд в lean‑подходах и AI‑дополненных операциях разработки делает его подходящим, когда компании нужно меньше встреч, быстрее принимать решения и иметь одного ответственного технического владельца на определённый срок.

Как выбрать правильный уровень полномочий

Полномочия должны следовать за риском и задержкой, а не за названиями ролей.

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

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

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

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

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

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

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

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

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

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

Тогда и проявляется реальная разница. Советник может указать на проблему. Фракционный CTO может на время сесть за руль.

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

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

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

Ошибки, которые размывают роль

Большинство команд думают, что выбор — это вопрос стоимости. На деле всё чаще дело в полномочиях.

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

Вторая ошибка — давать ответственность без инструментов для её реализации. Говорят: «Ты отвечаешь за доставку», а затем забывают дать доступ к облачным аккаунтам, логам инцидентов, бюджетам, планам найма или встречам, где принимаются решения. Человека обвиняют в задержках, но он не может устранить причину.

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

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

Последняя ошибка — оставлять договорённость бессрочной. Стартап говорит: «Давайте попробуем», но не назначает дату проверки, не прописывает область или условия выхода. Через три месяца основатель ожидает операционный контроль, команда ждёт коучинга, а внешний лидер думает, что у него всё ещё консультативный мандат.

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

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

Изменения роли обычно терпят неудачу по одной причине: полномочия двигаются, но никто не называет их явно. Граница между советником и оператором становится реальной только тогда, когда команда знает, кто может сказать «да», кто — «нет» и кто отвечает за последствия.

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

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

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

Следите за тремя ранними сигналами. Звонки по продукту должны перестать отскакивать между основателем, советником и тим‑лидом. Даты доставки должны меняться реже, с одним человеком, утверждающим изменения. Найм должен идти быстрее, потому что кандидатам дают одно чёткое «да» или «нет».

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

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

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

Короткая карта решений помогает больше, чем длинный документ ролей. Уместите её на одной странице и говорите просто. Назовите, кто может менять объём, приоритеты и дедлайны. Назовите, кто утверждает инструменты, подрядчиков и облачные траты. Назовите, кто открывает вакансии и делает окончательный выбор кандидата. Назовите, кто ведёт инциденты и кто общается с клиентами.

Это само по себе уберёт много трения вокруг вопроса. Люди обычно не спорят о названиях. Они спорят потому, что никто не знает, кто решает.

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

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

Если граница всё ещё кажется размытой, взгляд со стороны помогает. Oleg Sotnikov на oleg.is помогает стартапам именно с такой передачей: определяет область, распределяет владение и понимает, когда временный оператор должен отойти в сторону.