Техническое делегирование для основателей, которые раньше программировали

Почему основатели, которые раньше программировали, застревают в задачах

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

В первую неделю эта привычка помогает. К шестому месяцу она начинает мешать.

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

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

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

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

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

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

Что остаётся за вами, когда вы перестаёте программировать

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

Это не значит, что нужно сидеть в коде. Ваша работа — задавать правила, а не выбирать каждое имя метода, проверять каждый pull request или решать каждый странный баг, который всплыл во вторник днём.

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

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

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

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

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

Выберите первый поток работы, который можно передать

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

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

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

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

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

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

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

Напишите стандарты, которыми команда действительно сможет пользоваться

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

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

Сначала уложите это в одну страницу

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

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

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

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

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

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

Установите бюджеты, ограничения и точки проверки

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

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

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

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

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

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

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

Как передать один участок за 30 дней

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

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

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

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

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

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

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

Простой пример из продуктового спринта

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

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

После этого команда берёт всё на себя. Продуктовый менеджер решает, что первой версии достаточно трёх экранов. Техлид выбирает стек. В этом случае они не усложняют и используют тот же Next.js app и PostgreSQL database, которые уже у них работают. Никто не просит основателя одобрять каждый endpoint или каждую таблицу.

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

Ежедневные решения остаются у команды. Это включает оценки, формулировки интерфейса, форму API, детали покрытия тестами и небольшие компромиссы вроде выпуска экспорта сначала в CSV, а PDF — позже.

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

Ошибки, из-за которых вас снова затягивает в задачи

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

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

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

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

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

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

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

Быстрые проверки перед тем, как отойти в сторону

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

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

Перед тем как убрать себя из повседневной рутины, используйте короткий стресс-тест:

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

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

Следите за самым частым ложным сигналом: команда двигается быстро, но только потому, что всё ещё спрашивает: «А что бы ты сделал?». Это не самостоятельность. Это задержка в вежливой форме.

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

Когда стоит привлечь внешнюю помощь

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

Внешняя помощь имеет смысл, когда одна и та же картина повторяется месяц или два. Вы вмешиваетесь в архитектуру, разблокируете code review, разруливаете споры о приоритетах и принимаете финальное решение по инцидентам. Команда занята, но прогресс всё равно упирается в ваш стол.

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

Хороший внешний эксперт должен начинать не с инструментов, а с ролей, лимитов на расходы, прав на решения и точек проверки. Кто может одобрить смену библиотеки? Кто может принять технический долг ради скорости? Что по-прежнему требует одобрения основателя, а что нет? Эти правила важнее, чем ещё одна панель управления.

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

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

Если вам нужен такой внешний взгляд, Oleg Sotnikov на oleg.is работает со стартапами как Fractional CTO и advisor. Его опыт охватывает software engineering, работу CTO, лидерство в стартапах и AI first operations, поэтому он хорошо подходит основателям, которые хотят выйти из очереди задач.