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

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

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

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

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

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

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

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

Как размер команды меняет ответ

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

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

На этом этапе работа руками — не приятный бонус. Это часть того, что помогает компании двигаться.

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

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

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

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

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

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

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

Что делает с ролью давление сроков

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

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

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

Хорошо работает простая схема:

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

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

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

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

Где нехватка структуры начинает управлять днём

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

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

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

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

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

Недостаток структуры легко заметить по нескольким признакам:

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

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

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

Как по шагам разделить неделю

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

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

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

Простое распределение времени часто выглядит так:

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

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

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

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

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

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

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

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

Практичная неделя может выглядеть так:

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

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

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

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

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

Ошибки, которые выводят роль из равновесия

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

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

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

Есть несколько быстрых тревожных признаков:

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

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

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

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

Короткая проверка перед тем, как задавать ожидания

Многие основатели сначала отвечают не на тот вопрос. Они спрашивают: «должен ли CTO писать код каждый день», хотя правильнее спросить: где команда сейчас теряет время.

Смотрите на последние семь дней, а не на идеальную неделю. Календарь, pull request, баг-репорты и переписка в Slack говорят правду быстрее, чем должности в резюме.

Перед тем как решать, насколько hands-on должен быть ваш первый технический лидер, пройдитесь по короткому чек-листу:

• Если этот человек исчезнет на три дня, сможет ли кто-то другой вести планирование и сохранять движение работы?
• Останавливаются ли инженеры на мелких решениях, потому что им нужно одобрение одного человека для названий, инструментов или небольших продуктовых вопросов?
• Большинство недавних багов вызваны размытыми зонами ответственности, плохой передачей задач или неясными приоритетами, а не сложными техническими проблемами?
• Успел ли ваш лидер на прошлой неделе сделать глубокую работу в обычные часы, или ему пришлось догонять всё поздно ночью?
• Помогло бы убрать одну постоянную встречу сильнее, чем добавить ещё один блок под код?

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

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

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

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

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

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

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

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

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

Достаточно короткого чек-листа:

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

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

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

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

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