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

Почему основатели застревают

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

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

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

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

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

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

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

Когда нужен аварийный ремонт

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

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

Прямое написание кода обычно имеет смысл в нескольких случаях:

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

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

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

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

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

Вот для этого и нужен аварийный ремонт. Сначала остановить кровотечение, потом отойти в сторону.

Когда важнее навести порядок в архитектуре

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

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

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

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

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

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

Именно такую работу Oleg Sotnikov делал на масштабе продакшна: убирал дублирующие сервисы, ужесточал CI/CD и удерживал высокую доступность при гораздо меньшей команде. Для этого и нужна чистка. Сначала убрать повторяющуюся боль. Тогда команда сможет выпускать новый функционал, не наступая на те же грабли каждую неделю.

Когда коучинг команды работает лучше

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

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

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

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

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

Как код все еще помогает

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

Обычно это означает несколько точечных шагов вместо того, чтобы брать на себя целые фичи:

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

Именно так Oleg Sotnikov часто работает со стартап-командами: достаточно практично, чтобы учить, но не настолько, чтобы команда перестала думать сама. Если ваши инженеры понимают продукт и умеют кодить, коучинг обычно дает лучшую отдачу, чем временно приглашенный ведущий разработчик.

Как решить в первую неделю

Первая неделя должна ответить на бизнес-вопрос еще до споров о фреймворках или стиле кода. Где компания прямо сейчас теряет деньги, время или доверие?

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

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

Запишите сегодняшние проблемы простыми словами:

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

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

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

Пересматривайте выбор каждую неделю. Факты в стартапе меняются быстро. Система, которая в понедельник выглядела стабильной, к пятнице может превратиться в аварийный ремонт. Команде, которой на прошлой неделе нужна была помощь с кодом, на следующей неделе может понадобиться коучинг, когда срочные баги уже убраны. Хорошая поддержка CTO не бывает жесткой. Она меняется вместе с ситуацией.

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

Небольшая SaaS-компания шесть недель подряд срывала релизы. Каждая пятница выглядела одинаково: код вроде бы был почти готов, тесты падали, последние исправления накапливались, и никто не знал, кто может одобрить финальное слияние.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Два вопроса многое исправляют:

• Что именно должно измениться в ближайшие 30 дней?
• Как мы поймем, что CTO пора отойти в сторону?

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

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

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

Проверьте это, прежде чем давать доступ, назначать проект по чистке или просить коучинг команды:

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

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

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

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

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

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

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

Простой фильтр помогает:

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

Спросите любого временного CTO, сколько времени он ожидает тратить на код в первый месяц. Не принимайте расплывчатый ответ. Хороший ответ звучит примерно так: «Я буду писать код около 60% времени в течение двух недель, чтобы потушить пожары, а потом снизится до 20%, пока я документирую риски и помогаю команде». Это показывает, что человек понимает, зачем он работает руками и когда отойдет в сторону.

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

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

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

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