Правила эскалации для основателей, которые одобряют слишком много

Почему одобрения накапливаются

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

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

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

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

Чат‑инструменты добавляют ещё один слой путаницы. Быстрые ответы в Slack вроде «хорошо», «не сейчас» или «спроси меня в следующий раз» решают момент, но не создают повторяемого правила. Скоро компания живёт на разбросанных сообщениях, памяти и догадках.

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

Какие решения должны оставаться за руководством

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

Большинству стартапов достаточно, чтобы руководство держало контроль над несколькими областями:

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

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

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

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

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

Полезно также записать, что руководство больше не будет утверждать. Эта граница часто полезнее красивой диаграммы. «Руководство не будет утверждать рутинные скидки ниже 10%, стандартные правки контракта из юридической библиотеки, компромиссы спринта или обычные исключения поддержки ниже $200» даёт команде конкретику. «Действуйте по суждению» — нет.

Установите пороги по деньгам, времени и риску

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

Большинству команд нужны три вида порогов:

• Деньги: незапланированные траты выше $2,000, контракты свыше $10,000 или скидки выше 15%
• Время: задержки, сдвигающие запуск более чем на два дня, блокирующие другую команду более чем на один день, или добавляющие более восьми часов переработки
• Риск: всё, что касается данных клиентов, меняет юридические условия, ломает платную функцию или может заблокировать пользователей

Точные числа должны соответствовать компании. Самофинансируемому стартапу может понадобиться лимит $500. Финансируемой компании может хватить $5,000. Если почти каждое решение пересекает порог, он слишком низкий.

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

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

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

Чёткие лимиты на бумаге кажутся скучными. Отлично. Скучные правила экономят время.

Постройте таблицу эскалаций

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

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

Начните с недавних решений

Запишите каждое решение простыми словами: «Скидка выше 15%», «Возврат клиенту свыше $500», «Изменение объёма, добавляющее более трёх дней», «Производственный фикс, затрагивающий биллинг». Затем сгруппируйте эти решения по областям. Для небольшой компании обычно достаточно продукт, продажи, поддержка и операции. Если решение никуда не вписывается — это полезная информация: часто это значит, что владение неясно.

Начинайте с обычных, раздражающих согласований. Именно они тянут основателя в детали.

Добавьте важные правила

Каждая строка в таблице должна отвечать на четыре вопроса:

• Кто владеет этим решением в повседневности?
• Какой порог переводит его из рутинного в эскалацию?
• Как быстро этот владелец должен ответить?
• Если он не может решить — кто следующий?

Порог должен быть конкретным. Используйте деньги, время, влияние на клиента, юридический риск или системный риск. «Большая вещь» — расплывчато. «Любой контракт свыше $10,000 ARR» — ясно. «Важный баг» вызывает споры. «Любая проблема, блокирующая оформление заказа более 15 минут» даёт реальный триггер.

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

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

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

Хорошая таблица эскалаций должна казаться почти скучной. Люди читают строку, принимают решение и идут дальше.

Как команды должны эскалировать и решать

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

Хорошая эскалация — маленькая и конкретная. Сотрудник не должен писать «У нас проблема, что делать?». Он должен отправить рекомендацию: что случилось, какие варианты рассмотрели, что предлагают сделать и какое одобрение нужно.

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

Используйте простой формат эскалации

В большинстве случаев достаточно короткой заметки:

• что случилось
• рекомендуемое действие
• стоимость, задержка или риск
• крайний срок для ответа

Держите её короткой. Если для эскалации нужны три страницы, процесс слишком тяжёлый.

Командам также нужны окна ответа. Без них «ожидание одобрения» превращается в вежливый способ скрыть задержку. Установите одно окно для срочных случаев и другое для обычных. Производственный инцидент может требовать ответа в час. Выбор поставщика — ждать до следующего рабочего дня.

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

Другая половина важна так же. Если решение укладывается в порог владельца — он его принимает. Никаких дополнительных подписей. Никаких «просто проверить». Никакого «на всякий случай спросим».

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

Простой пример из маленького стартапа

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

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

Команде не было нужно больше встреч. Им были нужны ясные права на принятие решений.

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

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

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

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

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

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

Расплывчатый язык создаёт ту же путаницу. Если в политике пишут «большая скидка» или «срочный случай», люди будут понимать это по‑разному. Используйте числа и явные триггеры: свыше $1,000, задержка более двух дней, любой юридический риск, любой простой клиента дольше 15 минут.

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

Слабая эскалация создаёт другую проблему. Люди отправляют вопросы наверх без собственной позиции. Они пишут «Что мы должны сделать?» и останавливаются. Это превращает руководство в живую службу поддержки.

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

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

Бычек перед развёртыванием

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

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

Проверьте несколько базовых вещей перед развёртыванием:

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

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

Цель не убрать руководство отовсюду. Цель — сохранить фокус руководства на тех решениях, которые действительно могут серьёзно повлиять на деньги, риск или доверие клиентов.

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

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

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

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

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

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

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