Техническое узкое место согласований, когда основатель утверждает всё

Как выглядит одобрение со стороны основателя

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

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

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

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

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

Простой тест быстро всё показывает: если основатель исчезает на один день, что всё ещё выходит в работу? Если честный ответ — «почти ничего», значит, согласование стало барьером, а не подсказкой.

Как появляется эта очередь

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

Потом команда усваивает простую привычку: сначала спрашивай.

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

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

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

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

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

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

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

Чем это обходится компании

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

Первая цена — это календарное время. Рутинные вопросы накапливаются: переименовать поле, поправить API, выбрать библиотеку, изменить план выката. По отдельности они не выглядят драматично. Вместе они превращают суждение одного человека в очередь, а эта очередь становится частью продукта.

Команда становится тише

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

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

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

Основатель платит дважды

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

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

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

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

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

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

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

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

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

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

Этот двухминутный ответ пришёл с опозданием на семь дней.

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

Какие решения основатель должен оставить за собой

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

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

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

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

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

На практике основателю стоит оставлять за собой четыре типа решений:

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

Всё остальное должно уходить на уровень ниже.

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

Как распределить суждение и не потерять контроль

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

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

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

Правило может быть простым: инженеры могут утверждать обновления зависимостей, если тесты проходят и пакет не затрагивает auth, billing или хранение данных. Продакт может утверждать изменения текста в интерфейсе, если экран не влияет на checkout, onboarding или юридическое согласие.

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

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

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

Лучше всего это работает на реальном примере. Если команда постоянно ждёт, пока основатель утвердит каждый production hotfix, дайте engineering lead право чинить то, что восстанавливает сервис, не меняя поведение продукта. Раз в неделю разбирайте такие исправления. Если hotfix меняет логику billing, основатель по-прежнему принимает финальное решение.

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

Ошибки, которые мешают изменениям

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

Это не делегирование. Это домашнее задание с отложенным ответом.

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

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

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

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

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

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

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

Быстрая проверка вашего текущего процесса

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

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

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

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

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

Наглядный пример помогает увидеть это сразу. Допустим, команда зафиксировала 26 вопросов к основателю за одну неделю. Медианное ожидание — 9 часов для дизайн-решений, 5 часов для исключений из ревью и 14 часов для одобрения релизов. Семь вопросов повторяются. Два лида по-разному отвечают, кто может утвердить hotfix. У этой команды проблема не со скоростью. У неё проблема с суждением.

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

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

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

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

Начните с одной страницы

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

Оставьте только то, что нужно владельцу для работы:

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

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

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

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

Если это кажется сложнее, чем звучит, это нормально. Многие основатели хорошо знают систему, но никогда не записывали своё суждение. Если вам нужна внешняя помощь без найма full-time executive, Олег Сотников на oleg.is как раз занимается таким: помогает разложить права на решения, коучит лидов и чистит пути согласований.

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