Границы part-time CTO, которые защищают время лидера

Почему роль съезжает в запасного инженера

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

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

Founders невольно подталкивают этот сдвиг. Когда им нужен быстрый ответ, они идут к человеку, который быстрее всего снимет блокировку. Пятиминутный вопрос превращается в ревью pull request, тред в support или демо от поставщика. Если это сработало один раз, так начинают делать снова.

Ситуация с support становится хуже, если никто не отвечает за первый отклик. Странные баги, крайние случаи по оплатам и alerts из production попадают туда, где их быстрее всего заметят. Если CTO несколько раз вмешается, команда начнет воспринимать его как конечную точку для всего сложного. Вскоре каждый странный случай приходит с пометкой: «Можешь быстро посмотреть?»

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

Вот почему в part-time роли так важны границы. Времени мало, поэтому каждое прерывание стоит дороже, чем у full-time лидера. Один час на отладку support-проблемы — это еще и один час, который не ушел на передачу ответственности, правила по инцидентам или предотвращение той же проблемы на следующей неделе.

Съезд редко выглядит драматично. Он выглядит как ответственное поведение. А потом однажды CTO уже занимается запасным engineering, хотя должность у него лидерская.

Какую лидерскую работу нужно защищать по времени

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

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

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

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

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

Обычно достаточно простого еженедельного ритма. В понедельник можно оставить архитектурный обзор и письменные заметки. Во вторник — коучинг lead developer. В пятницу — риски delivery и решения по найму. Для startup на шесть человек это может звучать слишком формально. Но часто именно это и отличает команду, которая движется вперед, от команды, которая ждет в чате, что CTO ее спасет.

Защищайте эти блоки до того, как начнется внеплановая отладка. Это та работа, которая предотвращает повторение одних и тех же пожаров.

Решите, что CTO будет делать, а что нет

Part-time CTO начинают втягивать в случайную работу, когда любая техническая тема считается «работой CTO». Такая привычка быстро ломает планирование. Исправление простое: назвать работу, назначить владельца и записать небольшой набор обязанностей, которые остаются за CTO.

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

Для каждой задачи назначьте одного человека, который отвечает за первый отклик. Не пятерых. Не «engineering» как группу. Одно имя. Тимлид может владеть code review. Инженер может отвечать за сбои сборки. Ops-специалист может владеть стандартными alert. Founder может вести большую часть общения с поставщиками.

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

Вам не нужен длинный документ с политиками. Обычно хватает короткой заметки о зоне ответственности:

• Еженедельный архитектурный обзор: CTO
• Обычный triage багов: engineering lead
• Проверка облачного счета: ops или finance lead
• Первые звонки с поставщиками: founder или operations
• Production outage выше согласованного порога: CTO после эскалации

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

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

Командам, которые привлекают внешнюю senior-техническую помощь, лучше фиксировать это с первого дня. Oleg Sotnikov из oleg.is работает со стартапами именно с такими задачами: определение зоны ответственности, защита времени лидера и решение, что нужно эскалировать, а что должно оставаться в команде.

Установите правила для программирования

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

Код должен быть исключением. Используйте его для короткого spike, рискованного proof of concept или блокера, который никто другой в команде не может быстро снять. Если задачу можно спокойно положить в backlog, ее должен взять инженер.

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

Это полезно зафиксировать в операционных правилах:

• CTO не берет обязательства по sprint, если команда не согласна, что задача действительно снимает блокировку.
• Для работы с кодом нужно заранее определить дату завершения.
• Reviews и pairing sessions получают фиксированный недельный лимит.
• Другой инженер становится долгосрочным владельцем уже на той же неделе.
• Каждое исключение попадает в один общий журнал.

Последний пункт важнее, чем кажется. Если не отслеживать исключения в одном месте, они перестают восприниматься как исключения. Достаточно простого документа или project board. Запишите, что произошло, почему CTO вмешался, сколько времени это заняло и кто отвечает за дальнейшие шаги.

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

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

Маленький стартап может проверить это на одном реальном кейсе. Допустим, перед релизом команда столкнулась с неприятным auth bug. CTO 90 минут работает вместе с инженером, помогает изолировать причину, при необходимости пишет узкий фикс и передает cleanup и tests инженеру, который отвечает за auth. Так delivery защищен, но CTO не превращается во владельца auth.

Установите правила для support и инцидентов

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

Отдайте первый отклик тем, кто ближе всего к проблеме. Customer support должен сортировать пользовательские вопросы, собирать факты и отсеивать простые ошибки. Инженеры должны делать triage обычных багов, проверять логи и пробовать стандартное исправление, прежде чем эскалировать дальше.

Запишите правила по инцидентам простым языком. Настоящий инцидент обычно означает одно из четырех:

• Многие пользователи не могут пользоваться продуктом.
• Перестают работать платежи, регистрации или другой путь к выручке.
• Есть риск потери, искажения или утечки данных.
• On-call-инженер не может восстановить сервис за установленное время.

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

В incident chat нужна дисциплина. Используйте его, чтобы восстановить сервис, назначить владельцев и делиться статусом. Не тащите туда продуктовые вопросы. «Этот button должен работать по-другому?» и «Мы вообще еще хотим этот flow?» — это продуктовые решения, а не инцидентная работа. Перенесите такие вопросы в backlog или в заметку для product review.

После каждого настоящего инцидента исправляйте повторяющуюся причину, а не только видимый баг. Выделите 15–30 минут на короткий разбор. Что сломалось? Почему команда это пропустила? Что не даст этому повториться? Ответом может быть более удачный alert, небольшое изменение в коде, более понятный runbook или отказ от нестабильной зависимости от поставщика.

Это особенно важно для маленьких команд. Part-time CTO может помочь написать правила, но первый отклик все равно должен оставаться за командой. Так вы одновременно защищаете uptime и время лидера.

Как вести встречи с поставщиками, не теряя всю неделю

Встречи с поставщиками быстро расползаются. Одно демо превращается в follow-up, потом в разговор о цене, а затем в «быстрый созвон» на следующей неделе. Part-time CTO легко теряет полдня на встречи, которые ничего не меняют.

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

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

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

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

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

Допустим, стартап выбирает новый инструмент для error tracking. Первое демо должен взять инженер или ops lead, сравнить цены и проверить, сколько сил требует настройка. CTO подключается позже только если выбор влияет на инфраструктуру, compliance или контракт, который компании будет трудно развернуть назад.

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

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

Простой пример из маленького стартапа

Представьте стартап из 12 человек: один founder, engineering lead, support lead и part-time CTO. Команда достаточно мала, чтобы все видели все, а значит, роли очень быстро размываются.

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

В 10:30 поставщик просит демо в тот же день. Founder хочет быть вежливым и сразу соглашается. При рыхлой организации CTO втягивают в процесс, потому что «это займет всего 30 минут». Потом звонок затягивается, переходит в обсуждение цены, и блок на roadmap исчезает.

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

Затем наступает полдень, и клиент сообщает о billing bug. Именно такие случаи обычно возвращают CTO в режим запасного инженера. Вместо этого support lead сначала делает triage, проверяет, затронут один аккаунт или многие, и отмечает severity.

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

• Потеря выручки затрагивает нескольких клиентов.
• Engineering lead не может назвать владельца в течение 15 минут.
• Исправление требует решения на уровне продукта или политики.
• Проблема может создать юридические или compliance-риски.

Если ничего из этого не случилось, engineering lead назначает баг, support обновляет клиента, а CTO сохраняет свой roadmap-блок. Часто это экономит больше часа, но еще важнее последовательность. Команда учится, что не каждая проблема должна лежать на столе у CTO.

Именно так эти границы работают на практике. CTO по-прежнему помогает с трудными решениями. Просто команда перестает считать, что каждое прерывание — это такое решение.

Ошибки, которые втягивают CTO обратно

Большинство сбоев в границах начинается с простой привычки: люди слишком часто называют все срочным. Сломанный платежный flow ночью может действительно потребовать CTO. Неаккуратный Jira ticket или просьба поставщика быстро ответить — нет. Когда каждой проблеме дают одинаковый уровень тревоги, команда перестает сортировать вопросы и ждет, что вмешается самый senior человек.

Direct message вызывают такой же сдвиг. Если инженеры, founders, support или клиенты могут писать CTO когда захотят, они будут это делать. В моменте это кажется быстрым решением. За месяц CTO превращается в help desk с более красивым названием. Вопросы должны сначала проходить через тимлидов, on-call-владельца или общий support-канал.

Один маленький стартап постоянно ошибается именно так. Клиент сообщает о баге, support сразу пишет CTO, CTO смотрит логи и остается онлайн до релиза, потому что «так безопаснее». К пятнице архитектурная работа по-прежнему не тронута.

Встречи с поставщиками могут съедать не меньше времени. Если только CTO знает cloud-менеджера, контакт по security или account manager агентства, каждое продление, разговор о скидке и демо продукта попадает в один календарь. Этого можно избежать. Передайте ежедневные контакты с поставщиками finance, ops или engineering manager, а CTO подключайте только к сложным техническим или контрактным решениям.

Релизы создают еще одну ловушку. Команды часто оставляют CTO последней страховкой, потому что этот человек видел все плохие сбои раньше. Это кажется разумным, но тормозит рост. Если CTO должен смотреть каждый deploy, утверждать каждый hotfix или писать последний rollback plan, команда никогда не научится запускать production без надзора.

С возрастом компании это становится хуже, если никто не записывает владение задачами. При пяти людях все помнят, кто за что отвечает. При пятнадцати память подводит. Тогда инциденты, support, поставщики и релизы снова сползают к CTO, потому что никто не хочет угадывать.

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

Быстрая проверка и следующие шаги

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

Начните с внеплановых часов. Сложите все незапланированные запросы: пинги в Slack, быстрые исправления кода, неожиданные звонки с клиентами, emergency review и встречи с поставщиками, которые внезапно попали в календарь. Даже у part-time CTO с неплохими привычками на это может уйти 8–12 часов в месяц. Этого часто достаточно, чтобы сломать планирование, найм, архитектурную работу и коучинг.

Потом проверьте поток инцидентов. Сколько support issues или outages дошло до CTO напрямую? Высокое число обычно означает, что команда по-прежнему считает CTO запасной сеткой безопасности. Смотрите не только на количество, но и на картину. Если обычные баги, проблемы с доступом и мелкие сбои деплоя все еще идут наверх, правила по инцидентам слишком мягкие.

Встречи с поставщиками стоит проверить так же. Запишите, какие звонки действительно требовали времени CTO, а какие могли бы провести engineering, ops, finance или founder. Многие встречи звучат серьезно в приглашении, а на деле оказываются просто демо или check-in по аккаунту, где senior technical judgment не нужен.

Достаточно простого ежемесячного обзора:

• Посчитайте общее число внеплановых часов, которых не было в плане.
• Посчитайте, сколько инцидентов дошло до CTO и почему.
• Посчитайте, какие встречи с поставщиками действительно требовали участия CTO, а какие — нет.
• Обновите scope note с реальными исключениями, которые случились.
• Назначьте одно изменение на следующий месяц.

Scope note важнее, чем думает большинство команд. Держите его коротким, но настоящим. Если CTO вмешался в два production-инцидента потому, что ни у кого не было доступа, это нужно записать и исправить владение. Если CTO подключался к sales call, потому что покупатели задавали архитектурные вопросы, решите, кто будет отвечать на них в следующий раз.

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

Почему part-time CTO часто превращается в запасного инженера

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

Какая работа требует защищенного времени в расписании part-time CTO?

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

За что должен отвечать CTO, а что должно оставаться у команды?

CTO должен отвечать за техническое направление, решения по senior-найму, системные риски и эскалации, которые затрагивают деньги, безопасность или доверие клиентов. Рутинный triage, обычные code review и стандартные follow-up по поставщикам должны оставаться у назначенных владельцев в команде.

Когда part-time CTO должен писать код?

Используйте время CTO на программирование только для короткого spike, настоящего unblocker или рискованного proof of concept. Если задачу можно спокойно оставить в backlog как обычную, ее должен брать инженер.

Сколько внеплановой работы допустимо для fractional CTO?

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

Что должно запускать эскалацию инцидента к CTO?

Используйте простые триггеры: продуктом не могут пользоваться многие пользователи, останавливается денежный поток, есть риск потери или утечки данных, либо on-call-инженер не может восстановить сервис в согласованное время. Если ничего из этого не произошло, команда должна решать проблему в обычном рабочем процессе.

Какие встречи с поставщиками действительно нужны CTO?

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

Как остановить поток всех вопросов прямо к CTO?

Дайте людям один путь для запросов — например, через тимлида, on-call-владельца или общий канал — и просите сначала использовать его. Если founder, инженеры или support могут писать CTO в любой момент, они будут делать это снова и снова.

Какие ранние признаки показывают, что границы размываются?

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

Как стартапу каждый месяц проверять границы для CTO?

Проводите короткую ежемесячную проверку. Посчитайте внеплановые часы, посчитайте инциденты, которые дошли до CTO, разберите, какие vendor calls действительно требовали senior technical judgment, и обновите scope note одним исправлением на следующий месяц.