CTO на частичной занятости и старший инженер: кто за что отвечает?

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

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

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

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

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

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

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

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

За что должен отвечать part-time CTO

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

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

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

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

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

Стандарты тоже относятся к CTO, но не каждый комментарий в review. CTO должен задать правила для архитектуры, безопасности, uptime и качества релизов, а затем позволить senior engineer управлять ежедневной работой внутри этих правил. Например, CTO может требовать логов, алертов, планов отката и проверки затрат для новых сервисов, не читая каждый pull request.

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

За что должен отвечать senior engineer

Когда направление понятно, senior engineer должен отвечать за выполнение. Он берёт цель вроде «сократить отвал на онбординге» или «запустить биллинг для команды» и превращает её в задачи, которые команда может сделать в этом спринте.

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

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

Простое правило работает хорошо: если решение укладывается в рамки, его принимает senior engineer. Если решение меняет стоимость, потребность в найме, объём продукта или приоритеты команды, его нужно вынести наверх.

Обычно это значит, что senior engineer отвечает за разбиение задач, последовательность работ, реализацию фич и багов, обычный рефакторинг, code review и сам поток поставки.

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

Review здесь очень важны. Сильный senior engineer не просто ловит баги. Он учит через комментарии, держит стандарт стабильным и помогает команде выпускать продукт, не превращая каждый pull request в спор.

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

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

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

Как разделять технические решения

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

Используйте простое правило: чем больше зона влияния и чем сложнее откатить решение, тем больше в нём участвует CTO. Если выбор повлияет на бюджет, найм, uptime, безопасность или roadmap на месяцы вперёд, финальное решение принимает CTO после консультации с инженером. Если выбор остаётся внутри одного сервиса или одного цикла поставки, обычно им должен владеть senior engineer.

Именно поэтому решения без обратного хода требуют другого подхода, чем то, что легко откатить. Выбор базы данных, изменение модели мультиарендности, переход на определённую cloud-схему или принятие исключения по безопасности могут надолго остаться с командой. Такие решения требуют более широкого взгляда.

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

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

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

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

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

Простой способ всё настроить

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

Думайте простыми категориями: время релиза, приоритет багов, изменения архитектуры, выбор поставщиков, потребность в найме, урезание объёма и инциденты. Когда список становится видимым, разделение становится намного проще.

Для каждого решения назначьте две вещи: одного владельца и одну группу участников. Владелец принимает финальное решение. Группа участников даёт контекст, риски или ограничения. Если три человека считают, что они отвечают за одно решение, на самом деле за него не отвечает никто.

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

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

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

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

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

Реальный пример из команды растущего продукта

Представьте небольшую SaaS-компанию с пятью людьми вокруг продукта и разработки: один product lead, один senior engineer, два middle-инженера и дизайнер. Product lead хочет запустить биллинг по использованию и уведомления для клиентов, потому что крупные аккаунты постоянно этого просят. Интерфейсы — не самая сложная часть. Сложность прячется ниже.

Сейчас уведомления работают на простом cron job и одном worker. Это дёшево, и для небольшой базы клиентов это нормально. Но как только биллинг начинает зависеть от того же потока событий, риск резко меняется. Задержка уже означает не просто опоздавшее уведомление. Она может означать неверные счета, обращения в поддержку и тяжёлую неделю для стабильности.

Здесь разделение становится практичным. CTO принимает решения, которые влияют на стоимость, риск и объём релиза. Senior engineer принимает решения о реализации и запуске. Product lead решает, какую проблему клиента релиз должен закрыть в первую очередь.

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

Senior engineer отвечает за всё внутри этой границы. Он решает, добавлять ли очередь, делить ли workers по типам задач, хранить ли idempotency tokens и как настроить мониторинг неудачных биллинговых запусков. Он же выбирает план запуска: сначала внутреннее тестирование, потом несколько клиентов, потом полный релиз, если цифры остаются чистыми.

Такое разделение работает, потому что каждый остаётся в своей зоне, когда работа начинает двигаться. CTO не прыгает в каждый pull request и не даёт комментарии построчно. Senior engineer не обязан спорить с product lead о лимитах бюджета или объяснять отделу продаж риск релиза.

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

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

Ошибки, которые создают напряжение

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

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

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

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

Инциденты быстро показывают, где слабая ответственность. Представьте, что релиз ломает биллинг, поддержка получает злые сообщения, и проблема ещё затрагивает инфраструктуру. Senior engineer может исправить код, но кто-то всё равно должен вести полный ответ между командами. Если за момент никто не отвечает, проблема просто катается туда-сюда, пока клиенты ждут.

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

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

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

Короткий чек-лист на каждую неделю

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

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

Используйте четыре быстрых вопроса:

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

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

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

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

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

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

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

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

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

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

Потом подкорректируйте карту на основе реальных примеров. Если CTO и senior engineer всё ещё спорят об одном и том же, граница всё ещё слишком размыта. Меняйте формулировки, пока каждый не сможет за несколько секунд ответить на вопрос: «Это моё?»

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