Менше погоджень, більше відповідальності: Антон Асеєв про автономію команд під час масштабування

Чому в компанії, яка зростає, поступово накопичуються погодження?

Зазвичай це реакція на конкретні помилки. Щось пішло не так — додали перевірку. Потім ще одну, щоб підстрахуватися. Кожна окремо виглядає логічною, але через певний час навіть просте питання проходить кілька рівнів управління. Проблема виникає тоді, коли правила додають, але майже ніколи не переглядають. Я б почав із запитання: які погодження досі захищають бізнес, а які просто залишилися за звичкою?

Автономія команди — це менше контролю?

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

Як визначити, які рішення можна передати команді?

Я дивився б на два критерії: ціну помилки та можливість її швидко виправити. Скажімо, зміну внутрішнього інструмента, яка не зачіпає клієнтів і відповідає погодженій архітектурі, цілком може ухвалити сама команда. А ось зміна публічного API, від якого залежать інтеграції партнерів, потребує ширшого обговорення. Межа проходить не між «важливими» й «неважливими» людьми, а між різними рівнями ризику.

Як зробити відповідальність персональною, а не розмитою між учасниками процесу?

Потрібен зрозумілий власник рішення. Не обов’язково одна людина має робити все самостійно: вона може залучати інженерів, продуктову команду, безпеку чи фінанси. Але наприкінці має бути ясно, хто обирає варіант і відповідає за його виконання. Інакше виникає знайома ситуація: автор розраховував на перевірку керівника, керівник — на експертизу автора, а відповідальність нібито поділили, але фактично втратили.

Чим замінити нескінченні погодження?

Прозорістю рішень. Для типових питань часто достатньо коротко зафіксувати: що вирішили, чому обрали саме цей варіант і які ризики врахували. Керівник бачить логіку та результат без потреби ставити підпис на кожному кроці. Водночас мають існувати чіткі підстави для ескалації — наприклад, питання безпеки, значні витрати чи зобов’язання перед клієнтом. Автономія працює краще, коли правила винятків відомі заздалегідь.

Що робити, якщо команда помилилася?

Спершу розібрати рішення, а не шукати винного. Чи вистачало людям інформації? Чи були зрозумілими обмеження? Чи не суперечили одне одному цілі? Після цього можна змінити правила або додати потрібну експертизу. Якщо після кожної помилки забирати повноваження, команда швидко навчиться лише одному — безпечніше нічого не вирішувати самостійно. Водночас серйозні ризики не можна ігнорувати: тут важливі і відповідальність, і належні запобіжники.

Як у такій моделі змінюється роль CEO?

CEO менше займається маршрутизацією щоденних запитів і більше — цілями, пріоритетами та конфліктами між напрямами. Його завдання — побудувати систему, у якій команда розуміє, куди рухається бізнес і де проходять межі її рішень. Коли керівник необхідний для кожного погодження, компанія масштабує залежність від однієї людини, а не здатність працювати самостійно.

З чого почати, якщо компанія хоче спростити процеси?

Взяти кілька типових рішень за останній місяць і простежити їхній шлях: хто додавав нову інформацію, де виникала затримка, чи змінив керівник фінальний варіант. Потім обрати одну команду й на визначений період передати їй частину повноважень. Дивитися потрібно не лише на швидкість, а й на якість рішень та кількість проблем, що потребували ескалації. Якщо затримок менше, а ризики залишаються під контролем, модель можна поширювати далі.