Две команды готовят общий релиз.

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

Первая сторона предлагает не задерживать релиз. Вторая предупреждает, что после обновления перестанет работать часть пользовательских сценариев.

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

В какой‑то момент один из участников пишет своему начальнику.

«Коллеги снова блокируют релиз. Подключись, пожалуйста».

Это тоже эскалация. Только плохая.

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

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

Проблема осталась на месте, но теперь ею занято больше людей.

Когда надо эскалировать

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

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

В примере с API обе команды могут быть правы.

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

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

Перед передачей вопроса выше полезно проверить четыре вещи.

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

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

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

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

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

Полезное правило выглядит так.

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

Что именно передавать наверх

Хорошая эскалация не начинается с фразы «мы не договорились».

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

Не так.

Команда интеграции блокирует удаление старого поля. Мы уже всё объяснили, но они не готовы.

А вот так:

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

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

Перед эскалацией стоит собрать небольшой пакет.

1. Какой вопрос требует решения.

2. Почему его нельзя закрыть на текущем уровне.

3. Какие варианты реально доступны.

4. Что получает и теряет компания при каждом варианте.

5. Какой вариант рекомендуют участники.

6. Кто должен принять окончательное решение.

7. До какого момента ответ ещё имеет практическую ценность.

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

И вот, собственно, возможный пример эскалации в нашей ситуации:

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

Здесь возникает ещё одна важная проблема. Кто вообще должен принять решение?

Bain использует модель RAPID, где отдельно выделяются роли подготовки рекомендации, обязательного согласования, исполнения, предоставления данных и окончательного выбора. Модель предполагает одного владельца финального решения.

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

На практике не обязательно внедрять весь фреймворк. Часто достаточно заранее ответить на три вопроса.

• Кто готовит варианты?

• Кого обязательно нужно проконсультировать?

• Кто имеет право закончить обсуждение и выбрать один вариант?

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

Как проводить эскалацию без скрытой атаки

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

Сценарий знакомый.

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

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

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

Можно, а иногда даже нужно, сказать прямо.

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

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

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

После передачи вопроса нужен один человек, который координирует процесс.

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

Его задача состоит в другом.

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

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

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

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

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

В нашем примере итог мог бы выглядеть так.

Старое поле сохраняется до версии 4.8. Команда интеграции завершает миграцию до 15 сентября. После этой даты обратная совместимость не гарантируется. Решение принято владельцем продукта из‑за риска нарушения клиентских сценариев. Если миграция не завершена к контрольной дате, вопрос повторно эскалируется.

Теперь у эскалации есть не только вход, но и выход.

Что делать после решения

Не каждая эскалация указывает на плохой процесс.

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

Возможны несколько причин:

1. У команд нет ясных границ полномочий.

2. У решения нет постоянного владельца.

3. Локальные цели конфликтуют между собой.

4. Не определены допустимые риски.

5. Сотрудники боятся принимать обратимые решения без одобрения.

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

После значимой эскалации полезно потратить пятнадцать минут на разбор:

• Почему вопрос нельзя было решить ниже?

• Каких данных не хватало?

• Было ли понятно, кто принимает окончательное решение?

• Можно ли заранее определить правило для следующей похожей ситуации?

• Нужно ли расширить полномочия команды?

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

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

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

---

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

• 22 июля, 20:00. «Как CTO управляет неопределённостью: оценки, планы и ожидания бизнеса». Записаться

• 4 августа, 20:00. «Как аналитику работать с рисками». Записаться

• 5 августа, 20:00. «Оценка проекта: от интуитивных догадок к системному подходу». Записаться

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