Де закінчується автономія команди: Станіслав Андрєєв, COO SharksCode, – про рішення, які не можна делегувати

Як ви для себе визначаєте межі автономії команди?

Я аналізую наслідки рішення та можливість його переглянути.

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

Інша ситуація, коли рішення впливає на роботу інших команд чи зобовʼязання перед клієнтами. Тут уже недостатньо оцінювати його лише з позиції одного підрозділу.

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

Які рішення керівник має залишати за собою за будь-яких умов?

Насамперед ті, що мають довгострокові наслідки для людей і компанії.

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

При цьому я не вважаю правильним, коли керівник ухвалює такі рішення без обговорення. Потрібно почути безпосереднього менеджера та позицію HR. Особливо в складній ситуації, де є різні погляди.

Але фінальну відповідальність не можна перекладати на колектив. Команда не повинна опинятися в ситуації, коли від неї фактично вимагають вирішити долю колеги.

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

Що ще потрапляє в цю зону?

Стратегічні пріоритети і розподіл ресурсів.

Команда може чудово розуміти, як реалізувати певний проєкт. Але це не означає, що саме вона має визначати, чи варто компанії братися за нього зараз.

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

Тому керівництво має визначати пріоритети й пояснювати, чому саме вони важливі. Не менш важливо прямо говорити, від яких завдань компанія тимчасово відмовляється.

Іноді вчасна відмова від того, що зараз не є пріоритетом, приносить більше користі, ніж запуск нового проєкту.

Станіслав Андрєєв COO SharksCode

Як щодо безпеки та зобовʼязань перед клієнтами?

У цих питаннях автономія має працювати в межах чітких правил.

Уявімо, що команда знайшла спосіб пришвидшити реліз, прибравши один із етапів перевірки. З погляду окремого завдання це може здаватися хорошою ідеєю, адже реліз вийде швидше.

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

Те саме стосується змін у роботі з клієнтськими даними або доступів до критичних систем.

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

Швидкість важлива, але вона не повинна створювати проблеми, за які потім відповідатиме вся компанія.

Чи означає це, що автономія працює лише в межах дрібних завдань?

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

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

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

Тому керівник має дати команді достатньо контексту для самостійної роботи. Не обовʼязково розкривати всі управлінські деталі. Важливо пояснити ціль і ситуації, у яких потрібне погодження.

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

За якими ознаками можна зрозуміти, що автономія почала шкодити?

Один із перших сигналів зʼявляється тоді, коли рішення окремих команд починають створювати проблеми для інших.

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

Інший сигнал повʼязаний із тим, що проблеми стають помітними керівництву занадто пізно.

Я не вважаю, що команда повинна погоджувати кожне складне завдання. Але про ризики, які можуть вплинути на строки чи клієнтські домовленості, керівництво має дізнаватися до того, як вони перетворяться на проблему.

Ще одна ознака полягає в тому, що незрозуміло, хто відповідає за фінальний результат. Коли рішення ухвалювали всі потроху, після невдачі часто виявляється, що відповідального немає.

Для мене це вже питання якості управління.

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

Потрібно розділяти відповідальність за напрям і контроль кожного кроку.

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

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

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

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

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

Яку пораду ви дали б керівникам компаній, які зараз швидко масштабуються?

Не чекати першого серйозного конфлікту, щоб визначити, хто за що відповідає.

У невеликій команді багато речей працює завдяки особистим домовленостям. Люди давно знають одне одного й часто ухвалюють рішення без формальних процедур.

Але зі зростанням компанії цей підхід поступово перестає працювати. Нові співробітники не знають усіх домовленостей, а одне й те саме питання може проходити кілька рівнів погодження.

Тому я б радив зафіксувати, які рішення команда ухвалює самостійно, а які залишаються за керівництвом. І обовʼязково визначити, хто відповідає за результат.

Це не має бути великий документ із десятками сторінок правил. Навпаки, чим зручніше ним користуватися в щоденній роботі, тим краще.

Автономія має прискорювати роботу без зайвої плутанини. І якщо для кожного рішення потрібно йти до керівника, проблема не обовʼязково в несамостійності команди. Можливо, керівництво так і не визначило, що готове їй довірити.