Мандат fractional CTO: почему важен объем роли на одной странице

Почему роль быстро становится размытой

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

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

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

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

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

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

Что исправляет scope на одной странице

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

На этой странице должны быть перечислены повседневные обязанности простым языком. Для большинства компаний это техническое направление, архитектура, риски delivery, участие в найме и коучинг команды. Там же стоит прямо написать, что роль не покрывает: первую линию поддержки, полное project management, догонялки с продажами или работу ассистента основателя. Чем яснее формулировки, тем лучше.

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

Та же страница защищает и основателя. Нанять part-time senior technical help — не то же самое, что отдать «все, что связано с техникой». Письменный scope делает очевидным, что все еще остается у основателя: обещания клиентам, цены, приоритеты компании и финальные компромиссы.

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

Типичное для стартапа разделение ролей легко читается. Советник отвечает за проверку архитектуры, риски релиза и инженерные процессы. Основатель — за приоритеты roadmap, финальное утверждение найма и эскалации клиентов. Engineering manager ведет ежедневную поставку. Когда границы такие четкие, их гораздо сложнее потом исказить.

Что должно быть на странице

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

Затем назовите одну главную цель на первые 60–90 дней. Она должна быть достаточно узкой, чтобы всем было понятно, есть ли реальный прогресс. Это может быть более безопасный процесс релизов, сокращение расходов на инфраструктуру на 20 процентов или найм и наставничество первого engineering lead. Выберите один основной результат. Побочные задачи все равно появятся.

После этого перечислите несколько зон, за которые отвечает этот человек. Для большинства команд достаточно трех-пяти:

• product и system architecture
• найм инженеров и структура команды
• расходы на инфраструктуру и uptime
• процесс delivery и качество кода
• технический вклад в решения основателя или совета директоров

Этот список важен, потому что ответственность — это не то же самое, что «все, что связано с техникой».

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

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

Полезен и конкретный пример. Если стартап привлекает Олега Сотникова после тяжелого growth sprint, в документе можно написать, что его задача — сократить облачные потери, сделать технические решения жестче и выстроить AI-assisted development workflow, которым команда сможет пользоваться каждый день. Так у роли появляется понятная цель, а не размытое обещание помочь с «техникой».

Что должно остаться за рамками

Хороший scope не только описывает, что fractional CTO будет делать. Он еще и показывает, чем он не занимается. Пропустите эту часть — и роль почти сразу начнет расползаться.

Не включайте работу, которая должна быть у оператора, руководителя поддержки или основателя. На практике это обычно ежедневная обработка тикетов, обычные клиентские обращения, полное project management, разбор писем основателя и открытые обещания разрулить любую появившуюся проблему с людьми. Формулировки вроде «помогать, где потребуется» вообще не должны попадать в документ.

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

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

Это особенно важно в маленьких компаниях. Основателю нужна передышка, и ближайший senior technical человек быстро оказывается втянут в поддержку, планирование и проблемы команды. Но архитектуре, AI-first delivery и техническим решениям нужно непрерывное время. Без четких границ даже сильный советник начинает разбирать шум вместо того, чтобы чинить систему, которая этот шум создает.

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

Как написать это за 30 минут

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

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

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

Теперь посмотрите на повторяющуюся работу и назначьте каждому пункту одного владельца: основатель, fractional CTO, engineering manager, product manager, support или кто-то еще. Эта часть важнее, чем многие ожидают. Проверка архитектуры может принадлежать fractional CTO. А вот планирование спринтов — обычно нет. Сбросы паролей, погоня за тикетами и разбор почты почти никогда не должны быть у него.

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

Полезный тест: прочитайте каждую строку и спросите себя: «Это требует senior технического суждения или просто полезного человека на связи?» Во второй категории и начинается расползание scope.

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

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

Основатель SaaS нанимает fractional CTO на три месяца. Цель понятна: поправить roadmap, проверить архитектуру и помочь нанять двух инженеров.

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

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

Перезагрузка простая. Основатель и CTO составляют короткий мандат и оба его подтверждают. В нем написано, что CTO отвечает за технический roadmap, проверку архитектуры и процесс найма senior engineers. Там же указано, что CTO не отвечает за triage багов, расписание встреч с вендорами, ежедневные standup и обычные follow-up.

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

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

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

Ошибки, из-за которых scope расползается

Мандат fractional CTO обычно ломается постепенно, а не одним громким событием. У основателя срочный вопрос от клиента, один менеджер заболел, релиз задержался — и вдруг любая проблема начинает называться «задачей технического лидера».

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

Вторая ошибка — добавлять обязанности в чате и никогда не обновлять письменный scope. Быстрое сообщение в Slack превращается в постоянную ответственность, а потом никто уже не помнит, когда это началось. На странице написано «архитектура, найм и техническое направление», а неделя говорит: «участвовать в sales calls, догонять вендоров и разгружать поддержку».

Третья проблема появляется, когда компания делает CTO запасным вариантом на место любой недостающей роли. Нет engineering manager? Попросим CTO. Нет product owner в этом спринте? Попросим CTO. Основатель утонул в сообщениях? Отдадим ему почту. На несколько дней это помогает, но тихо заменяет лидерскую работу на работу по покрытию дыр.

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

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

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

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

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

Перед утверждением проверьте пять вещей:

• Может ли новый член команды в одном предложении объяснить, зачем здесь этот человек?
• Написано ли на странице, чего он не делает?
• Есть ли у основателя отдельная зона без пересечений?
• Назначены ли отдельные владельцы для поддержки, project management и admin-задач?
• Влезает ли первый месяц в реальный бюджет времени?

Есть и еще один тест. Дайте страницу тому, кто пришел на прошлой неделе, и задайте три прямых вопроса: если ломается продакшен, кто решает; если меняется roadmap, кто решает; если клиент просит статус, кто отвечает. Если ответы приходят быстро и одинаково, мандат работает.

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

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

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

Отправьте черновик основателю, текущему CTO или engineering manager и тимлидам, которые будут работать с этим человеком каждую неделю. Задайте один прямой вопрос: что эта роль должна делать в ближайшие 30 дней, а что должно остаться у кого-то другого?

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

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

Делайте это письменно, а не в памяти Slack. Короткая пометка вроде «Это за Sam» не даст задаче снова вернуться на следующей неделе.

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

Если вам нужна внешняя помощь с формулировкой scope, держите ее практичной. Советники вроде Олега Сотникова часто начинают именно с этого упражнения, чтобы engagement оставался сфокусированным на архитектуре, рисках delivery и изменениях, связанных с ИИ, а не на ежедневной уборке. Именно такой тип работы описан на oleg.is, где фокус — техническое лидерство и AI-first operations, а не общий поток проектных хвостов.

Scope на одной странице не делает fractional CTO менее полезным. Он просто делает его время значимым.