Коли технологічна компанія розширюється, управління часто стає затором. Рішень накопичується все більше, команди змушені чекати на дозволи довше, ніж безпосередньо працювати. Антон Асеєв, керівник IT-компанії SharksCode, пояснює, як зберегти темп розвитку через делегування повноважень і чому керівникам доводиться переосмислювати власну функцію.
Бюрократія виникає рідко як результат свідомого рішення. Звичайно, після якоїсь неприємної помилки додають перевірку, щоб запобігти повторенню. За рік-два виходить, що для впровадження простої функції потрібні підписи кількох осіб, половина з яких на лікарні. Така система часто прикривається турботою про якість, проте насправді захищає керівника від тривоги через невизначеність. Маркер проблеми видно в календарі, коли узгодження займають більше часу, ніж робота. Інший сигнал тривоги — коли розробник у чаті повідомляє про очікування затвердження і переходить на інше завдання. Компанія тоді рухається зі швидкістю найзавантаженішої людини, що зазвичай сидить на верхівці ієрархії.
Автономія команди — це можливість приймати рішення в межах своєї компетенції без попереднього схвалення. При цьому команда відповідає за результат і може обґрунтувати своє рішення. Це часто плутають із вседозволеністю, хоча насправді потрібна чіткіша структура. Люди повинні знати межі своєї відповідальності та критерії оцінки. Аналогія з футболом: під час матчу гравці не біжать до тренера питати про дозвіл на пас, вони приймають рішення за секунди, бо розуміють стратегію та свою роль. Кожне рішення варто оцінювати за вартістю можливої помилки та складністю її виправлення. Більшість щоденних завдань в розробці легко скасувати, тому команда має діяти швидко самостійно — кожен день очікування дорожче за потенційну ошибку. Інше — з рішеннями, які важко змінити, як вибір архітектури на роки чи великі видатки. Там доцільно залучити більше людей. На практиці таких рішень мало, тож решту перевірок можна прибрати.
Керівники часто бояться втратити контроль, але затвердження дає лише видимість безпеки. Керівник фізично не може вникнути в кожне рішення, часто підписуючи його, не розібравшись. Замість контролю на вході варто запровадити прозорість на виході: команда сама вирішує й коротко записує логіку, керівник отримує загальну картину й втручається лише при системних проблемах. Роль CEO змінюється з диспетчера на архітектора — він вибудовує систему, де якісні рішення народжуються без його участі. Насамперед він ставить цілі, щоб кожен міг звіритися з ними. Важлива культура, де про помилки говорять відкрито без пошуку винних, інакше люди знову будуть просити дозволу на кожен крок.
Перехід починається з аудиту погоджень: проглядають останній місяць і перевіряють, скільки рішень керівник насправді змінив. Зазвичай виявляється, що більшість схвалюють без змін, такі ланки прибирають першими. Далі обирають одну команду для тесту й дають їй більше свободи в чітко визначеній зоні. Автономія спирається на довіру, яку будують поступово. Штучний інтелект прискорює роботу спеціалістів — розробник із сучасними інструментами робить за день те, на що раніше йшов тиждень. Проте це не має сенсу, якщо результат потім чекає тиждень на затвердження. Саме тепер команди повинні мати право рухатися в темпі, який дозволяють технології.
