Узкое место основателя в технических решениях и как его устранить

Когда каждое техническое решение ложится на основателя

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

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

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

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

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

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

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

Как замедление проявляется в повседневной работе

Узкое место у основателя редко выглядит драматично в начале. Команда всё ещё выпускает фичи. Чаты по-прежнему оживлённые. Все выглядят занятыми. Проблема проявляется в мелких задержках, которые копятся всю неделю.

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

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

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

Некоторые признаки повторяются снова и снова:

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

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

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

Что замечают кандидаты на собеседованиях

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

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

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

Это меняет саму роль. На бумаге компания может нанимать staff engineer, engineering manager или head of engineering. На практике работа превращается в следующее: собрать варианты, оформить их, ждать основателя и потом защищать решение, которое ты сам не принимал. На это мало кто из сильных кандидатов согласится уйти со стабильной работы.

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

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

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

Как кодовая база начинает отражать один мозг

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

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

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

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

Часто появляются такие признаки:

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

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

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

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

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

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

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

Обычно их можно разделить на четыре группы:

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

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

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

Вмешивайтесь только тогда, когда решение:

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

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

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

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

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

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

У команды B2B‑софта из 12 человек была привычка, которая сначала казалась безобидной. Любое изменение базы данных — даже новый индекс или переименование колонки — шло на утверждение основателю. Именно он писал первую версию продукта, поэтому ему доверяли. Это работало, когда в компании было четыре человека. При двенадцати это стало тормозить всё.

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

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

У основателя осталось только два типа решений:

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

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

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

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

Ошибки, которые делают узкое место ещё хуже

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

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

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

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

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

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

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

Быстрая проверка на ближайшие две недели

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

Начните с каждого технического вопроса, который доходит до основателя. Две недели ведите его в одном общем документе или чат-треде. Записывайте кратко:

• кто задал вопрос
• о чём было решение
• мог ли на него ответить лида или senior engineer
• нужен ли был ответ в тот же день
• какая работа ждала ответа

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

В тот же период отслеживайте время ожидания PR. Не просто считайте открытые pull request'ы. Отмечайте, сколько они лежат, на кого ждут и нужен ли основателю реальный технический ревью, а не просто личное спокойствие. Если код стоит из-за комментариев к именам, структуре папок или мелким деталям реализации, команда просит разрешения, а не ревью.

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

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

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

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

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

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

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

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

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

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

Если передача ощущается неуклюже, скорее всего правила жили в голове одного человека. Обычно именно тогда помогает внешний советник. Олег Sotnikov на oleg.is работает со стартапами как Fractional CTO и startup advisor, помогая основателям разложить владение архитектурой, структуру команды и границы решений, не забирая на себя всю функцию.

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