Сфера ответственности part-time CTO: что решить до первого дня

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

Основатель нанимает part-time CTO, чтобы выстроить архитектуру, помочь с наймом и принять несколько сложных решений. Через две недели этот же человек уже участвует в ежедневных стендапах, проверяет мелкие pull request, успокаивает outage и отвечает в Slack на вопросы о незначительных изменениях в продукте. Название роли не изменилось. Изменились привычки команды.

Так происходит постоянно, потому что основатели часто ждут, что один человек одновременно будет отвечать и за стратегию, и за ежедневное управление. Это разные задачи. Для стратегии нужно время вдали от шума. Для ежедневного управления нужны быстрые ответы, постоянное присутствие и внимание к мелочам. Part-time CTO может касаться и того и другого, но только в ограниченном объёме и только если все договорились, где заканчивается одна зона ответственности и начинается другая.

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

Срочные проблемы делают размытость ещё сильнее. Один серьёзный outage может съесть целую неделю. Аварийная работа живёт по другому ритму, чем планирование и ревью. Она реактивная, стрессовая и плохо предсказуемая. Если компания не отделяет время на аварийные задачи от обычных обязанностей part-time CTO, стратегическая работа тихо исчезает.

Размытая роль создаёт и провалы в ответственности. Основатель думает, что CTO управляет поставкой. Engineering lead думает, что приоритеты всё ещё у основателя. Product manager считает, что CTO вмешается, когда команда застрянет. В итоге никто не владеет передачей задач, никто не фиксирует компромиссы, и пропущенные сроки начинают выглядеть как технический сбой, хотя на деле это сбой в scope.

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

Что входит в сферу ответственности

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

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

Направление на квартал

Технические приоритеты должны входить в scope, потому что команды редко попадают в неприятности из-за одного плохого тикета. Проблемы начинаются, когда проходит квартал без понятных компромиссов. Хороший CTO помогает основателям выбрать между более быстрой поставкой, закрытием technical debt, повышением надёжности или сокращением расходов на инфраструктуру, а затем объясняет цену каждого выбора простыми словами.

Аудит архитектуры тоже должен быть здесь, особенно перед дорогими изменениями. Переписывание системы, перенос в облако, редизайн базы данных и новые ИИ-функции могут привязать компанию к месяцам работы и гораздо большему счёту. Part-time CTO должен проверять такие шаги заранее, пока компания ещё может недорого сменить курс.

Найм — ещё одна область, где помогает внешний взгляд. Основатели часто просят «ещё инженеров», когда реальный разрыв совсем другой. Иногда команде нужен более сильный backend lead. Иногда — лучшие привычки тестирования. Иногда один человек, который возьмёт на себя инфраструктуру, поможет сильнее, чем ещё два разработчика под приложение. Такое решение нельзя принимать наугад.

Когда CTO должен вмешаться

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

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

Что должно остаться за пределами сферы ответственности

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

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

Проведение стендапов, планирование спринтов и приведение доски задач в порядок обычно должны быть где-то ещё. Туда же относятся утверждение каждого pull request, тикета или шага релиза, обработка отпусков и performance issues, роль default engineering manager и обычные закупки у вендоров или небольшие покупки софта.

Ничто из этого не бесполезно. Просто эти задачи требуют более коротких циклов и более быстрой реакции, чем может дать part-time CTO. Основатель может подумать: «Это же всего 15 минут в день», но пять таких мелких обязанностей легко съедают всю роль. Тогда важная работа так и не получает нужного внимания: архитектурные решения, дизайн команды, проверка рисков, восстановление после инцидентов и техническое направление.

Хороший пример — утверждение pull request. CTO может задать планку качества, определить правила ревью и подключаться к рискованным изменениям. Это полезно. Утверждать каждый небольшой фикс — нет. То же самое со sprint board. CTO может решить, имеет ли смысл сам процесс планирования. Но не должен тратить утро вторника на то, чтобы переставлять тикеты между колонками.

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

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

Решения, ревью и аварийная работа — это разные задачи

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

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

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

Когда начинается аварийная работа

Аварийная работа должна начинаться тогда, когда компания пересекла понятный триггер, а не когда кому-то просто не по себе. Типичные триггеры:

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

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

После исправления работу нужно вернуть кому-то другому. Обычно это engineering manager, tech lead, основатель или только что нанятый head of engineering. Передачу задач стоит прописать письменно: кто снова владеет roadmap, кто ведёт стендапы, кто утверждает найм и кто продолжает план восстановления.

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

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

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

Начните с ближайших 90 дней. Сначала выберите бизнес-результаты, а потом свяжите с ними работу CTO. Хорошие цели должны быть конкретными: сократить расходы на облако на 20 процентов, выпустить первый paid onboarding flow, исправить сбои релизов или перевести один ручной процесс на автоматизацию с помощью ИИ.

После этого назовите территорию. Перечислите продукты, системы и команды, к которым CTO может прикасаться. «Вся engineering» — слишком широко. «Customer app, billing backend, CI/CD и продуктовая команда из 4 человек» — уже достаточно понятно, чтобы потом не спорить.

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

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

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

Запланируйте пересмотр scope на 30-й день ещё до старта работы. На этой встрече стоит задать прямой вопрос: CTO тратил месяц на запланированные решения или его затягивали аварийные задачи и управление командой? Если реальная работа выглядит не так, как подписанный scope, меняйте его сразу. Это экономит деньги, убирает лишнее раздражение и даёт компании роль, которая совпадает с реальными потребностями.

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

У SaaS-компании восемь инженеров, один engineering manager и релиз, который дважды сдвинулся за один месяц. Клиенты продолжают просить новый набор функций, но команда тратит больше времени на исправление последних проблем, чем на поставку.

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

Именно здесь помогает чёткий scope.

Part-time CTO не берёт на себя стендапы, планирование спринтов и каждый ежедневный вопрос от команды. Движение поставки сохраняет engineering manager. Этот человек ведёт backlog, отслеживает blockers, возвращается по срокам и следит, чтобы команда закрывала уже начатую работу.

CTO подключается на другом уровне. Сначала он смотрит на архитектуру и путь релиза. Ищет причины, почему работа застревает: слишком много передач, неясные владельцы, слабое покрытие тестами перед релизом или один senior engineer, который стал единственным человеком, умеющим выкатывать изменения. Он также проверяет кадровые разрывы. Может быть, команде пока не нужен ещё один backend engineer. Может быть, ей нужен более сильный процесс релиза и один senior человек, который поможет команде пройти через запуски.

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

Такой аварийный период может длиться две или три недели, а не шесть месяцев. После этого CTO смотрит на результаты, корректирует план и возвращает ежедневный ритм engineering manager.

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

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

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

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

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

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

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

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

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

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

Краткий чек-лист перед подписанием

Большинство проблем с scope начинается с одной расплывчатой фразы: «помочь нам с техничкой». Звучит безобидно, но скрывает сразу несколько разных задач. Чёткий scope гораздо проще оценить, измерить и соблюдать после старта работы.

Прочитайте черновик и проверьте его по пяти простым пунктам:

• Каждая большая обязанность должна помещаться в одно простое предложение. Если строка требует полстраницы объяснений, работа слишком широкая или смешанная.
• Вся команда должна понимать, кто занимается ежедневным управлением людьми. Part-time CTO может направлять лидов и задавать стандарты, но one-on-one, отпуск и ежедневный follow-up обычно должен вести кто-то другой.
• Основатели должны назвать, какие решения всё ещё требуют утверждения. Изменения бюджета, senior-найм, выбор вендоров и компромиссы по продукту часто вызывают напряжение, если правило не установить заранее.
• Аварийная работа должна иметь ясное начало и конец. Если компания зовёт CTO, чтобы остановить outage, распутать проблемы с поставкой или почистить запутанный стек, нужно записать, что означает «исправлено» и когда аварийная фаза заканчивается.
• Успех должен выражаться в трёх ежемесячных результатах. Держите их простыми: меньше инцидентов, быстрее релизы или план найма с датами и владельцами.

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

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

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

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

Запишите, чем этот человек владеет, что он только ревьюит и что остаётся у основателей или engineering managers. Все размытые места пометьте простыми заметками вроде «решить позже» или «нужен владелец». Это лучше, чем делать вид, что граница ясна, когда это не так.

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

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

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

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

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

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

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