#131. Management debt

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

І я подумав: а чи існує тоді management debt?

Не провів вчасно 1:1, відклав складний фідбек, не налаштував якийсь процес це не борг, а скоріше просто відкладена робота, беклог менеджера.

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

Не розібрались один раз з ownership — кожна наступна суперечка знову потребує менеджера. Не навчили людину приймати певні рішення — менеджер продовжує приймати їх сам. Не дали складний фідбек — проблема залишається, починає впливати на інших, а через пів року розмова стає в п'ять разів складнішою. Не полагодили planning — кожен реліз знову перетворюється на emergency. Не домовились, як керуємо ризиками — кожен новий ризик виявляється тоді, коли варіантів вже майже немає. Не засетапили регулярні вантувани — не побудували відностии, відірвалися по очікуванням і ще купа всього.

Як і з technical debt, суть не в тому, шо ми один раз шось не зробили, а в тому, шо через це кожен наступний цикл стає дорожчим.

Причому цей борг не обов'язково виникає через поганий менеджмент. Часто взяти його прямо зараз — цілком раціональний вибір. Швидше самому прийняти рішення, ніж навчити людину. Простіше ще раз вручну розрулити конфлікт, ніж перебудовувати ownership. Простіше дотиснути реліз героїзмом, ніж зупинитись і переробити planning. Проблема починається, коли тимчасове рішення перестає бути тимчасовим.

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

Немає нормального ownership — потрібен менеджер на кожному рішенні. Немає пріоритизації — потрібні нескінченні синки. Немає risk management — потрібні нічні rescue operations. Не вирішили проблему з перформансом — сильніші люди забирають на себе роботу слабшого.
Результат при цьому виглядає нормально. Реліз вийшов, рішення прийняте, клієнт не пішов. Просто система кожен раз обслуговує борг людськими зусиллями.

Як у будь-якого боргу, у management debt є відсотки. Чим довше проблема залишається невирішеною, тим більше ви за неї платите. І платити можна дуже різною валютою.

Часом команди і менеджера
Люди знову обговорюють проблему, яку можна було один раз перетворити на систему. Панікою — кожен реліз закінчується авралом. Якістю — коли часу вже немає, єдина змінна, шо залишається, це наскільки поганий результат ви готові прийняти.

Втратою опцій
Два місяці тому можна було обирати між A, B і C. За тиждень до релізу вибір перетворюється на "випускаємо так або не випускаємо взагалі". Management debt зменшує optionality: чим пізніше вирішуєш проблему, тим менше хороших рішень залишається.

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

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

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

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