Ті, хто знайомі зі мною, знають, що я ніколи не підтримував ідею ролі Тім Ліда. Хоча раніше я думав, що негативна конотація цієї ролі скоріше пов'язана зі стилем керівництва і що цьому можна навчитися і що до цього можна пристосуватися.
Усі ми знаємо, що стиль керівництва може бути різним. Але зараз я вважаю, що якщо ви маєте вбудовану роль Тім Ліда в команді, то культура зрештою слідуватиме структурі. Це означає, що фігура Team Lead, швидше за все, переважатиме над іншими членами команди, перетворюючи їх на безсилих жертв.
Я в ролі Тім Ліда
Я пам'ятаю, як ще на першому місці роботи у 2001–2003 роках мене призначили Тім Лідом. Це сталося тому, що раніше я брав участь у цьому проєкті та дещо вже знав про предметну область, клієнтів та код. Так, під моїм керівництвом опинилося кілька розробників.
Деякі ухвалені тоді мною рішення насправді були не такі вже й погані. Я впровадив Безперервну Інтеграцію та Модульне Тестування. Але зараз, оглядаючись назад, я точно усвідомлюю, як я стримував свою команду і наскільки сильно контролював її.
Тепер мені навіть соромно згадувати, як я насварив розумного розробника за давно потрібний рефакторинг. Чому я зробив це? Не тому, що я не хотів мати кращий код. І не тому, що я хотів зробити це сам. Ні. Я просто злякався змін, які він вносив. Я думав, що вони можуть серйозно зламати код та затримати доставку, за що на мене покладалася повна відповідальність.
Я почував себе невпевнено та безпорадно. У мене виникало бажання контролювати те, що робить інший розробник, адже інакше він би все зруйнував, у тому числі мою кар'єру. Рівень відповідальності, яка була покладена на мене (чи я сам згодом ще більше покладав її на себе?), була надто великою – я не міг діяти ініціативно та відкрито.
Я перешкоджав необхідним змінам. Я не вів за собою – я блокував.
... минуло 20 років і тепер я знаю, що, мабуть, був занадто молодий для цієї ролі. Але, з іншого боку, хіба така моя поведінка в ролі Тім Ліда не формує закономірність, яку ми можемо будь-де побачити сьогодні? Чи впізнаєте ви себе, або свого Тім Ліда у цій історії?
Відповідальність, покладена на одну людину, зрештою призводить до її перевантаження і стресу. А це може призвести до різних дисфункцій. Безпечна та реактивна гра – це лише одна з тих можливостей, на які натрапив особисто я. Інші можуть поводитися по-іншому в умовах стресу під тиском надто великих очікувань від них. Але понад усе це існує одна закономірність — рівень командування та контролю над іншими згодом підвищується. Тим самим висмоктуючи відповідальність із самої команди.
І це стає зачарованим колом, самовтілюваним пророцтвом. Команда перестає діяти, очікуючи на дії свого лідера, а лідерові нічого не залишається, окрім, як діяти, тому що він не бачить ініціативности з боку команди. Минають місяці та роки, і все, що у вас є, це надміру змучена людина, яка намагається мікрокерувати купою демотивованих людей. Це важка робота та прикре існування.
Так не має бути. Ми можемо працювати набагато краще! Але спершу нам потрібно зрозуміти, як ми створили цю динаміку.
Гарні наміри. Погана динаміка
Зауважте, що призначення Тім Ліда (або аналогічної ролі в команді) завжди починається з добрих намірів:
"Давайте візьмемо в команду досвідченого фахівця (senior), щоб переконатися, що команда приймає правильні рішення".
"Замість того, аби вся команда витрачала свій час на уточнення цієї вимоги, нехай просто Тім Лід подивиться на неї".
"Ми повинні переконатися, що молодші розробники не роблять свій внесок поганими кодами, тому нехай Тім Лід розгляне пропозиції зміни коду".
Ніхто ніколи не був звільнений за висловлювання цих чи подібних тверджень. Вони мають сенс. Вони логічні. Крім того, їх легко можна знайти в інших компаніях, на які ми натрапляли або в яких працювали.
Проте, саме ці пропозиції призводять до негативної динаміки, яку ми щойно обговорювали вище. Введення спеціальної старшої ролі (хоч би як ви її не називали), швидше за все, призведе до обмеження потоку роботи та зростання команди. Саме так працюють вузькі місця у системі.
"Покажіть мені спеціаліста, і я покажу вам вузьке місце!" - Як висловився мій колега-тренер з LeSS і добрий друг Грег Хатчінгс. А Тім Лід згодом стає пекельно крутим фахівцем.
Натомість призначайте Engineering Managers
Чим більше я зараз працюю з великими компаніями, тим більше спостерігаю цю закономірність: роль Тім Ліда скасовується, і замість нього наймають Engineering Manager-а з акцентом на довгострокове технічне процвітання. Насправді це означає, що Engineering Manager працює з кількома командами й робить це крос-функціонально.
Можна було б сказати, що це просто «масштабування» ролі Тім Ліда. Але ні. Це створює зовсім іншу динаміку:
1. Ваші команди вільні від диктатури будь-якого роду
Команди тепер просто команди. Жодних ролей, жодних владних ігор. Плоскі та проактивні, як це визначено у Scrum. Усі рішення, що вимагають участі всієї команди, прийматимуться всією командою. І якщо для деяких процесів потрібно лише представник команди (або два), ці представники, швидше за все, змінюватимуться і ніколи не призведуть до формування «особливих» людей. Особливих людей немає. Є просто блискуче рівні члени команди, що випромінюють потенціал діяти вільно, коли це необхідно.
2. Product Management веде за собою команди
Ми хочемо, щоб людей вели, а не казали, що робити. Ділова людина у команді (наприклад, Власника Продукту в Scrum), яка щодня працює з командою, може дати достатньо пояснень, щоб усі розуміли напрямок та діяли відповідно. Нам не потрібний ще один лідер, щоб переварити, спростити та відгородити команду від реального світу. Нарешті ми можемо почати ставитися до людей, як до дорослих.
3. Зосередьтеся на довгостроковому зростанні
Engineering Manager має працювати з кількома командами, а не з однією. Таким чином, ми зводимо до мінімуму можливість цієї людини знати всі деталі, а потім намагатися мікрокерувати. Ця людина все ще може бути залучена до діяльності з розвитку та досягнення короткострокових цілей. Але не на повний робочий день. І не заради постачання.
Місія Engineering Manager полягає у тому, щоб нарощувати потенціал команд. Щоб інженерія знову стала великою.
Нижче наведено приклад посадової інструкції Engineering Manager в Gusto:
- Наймайте, очолюйте та розвивайте команду талановитих інженерів.- Створюйте та заохочуйте інклюзивну, спільну та високоефективну культуру- Співпрацюйте з нашими командами з data science, операції, управління продуктами та дизайну, щоб керувати та володіти розробкою наскрізних продуктів для складних потреб клієнтів від початкового планування та виконання до остаточного постачання.- Працюйте в тісному контакті з керівництвом, щоб допомогти встановити пріоритети як короткострокових, так і довгострокових дорожніх карт.
Це компанія, де Кент Бек працює Engineering Manager-ом (станом на 2022 рік). І він багато пише про цю роль, свою місію та обов'язки керівництва.
4. Код із командами
Ми хочемо, щоб Engineering Manager-и були... інженерами. Не HR-фахівцями чи лайф-коучами.
Ми завжди хотіли, щоб більш досвідчені інженери передавали свої знання іншим. Тім Ліди були спробою досягти цього, але з поганими наслідками. Тепер Engineering Manager-и, позбавлені цих недоліків, можуть вчиняти правильно.
Engineering Manager-и повинні слідувати підходу «Go Gemba» Lean Manager-ів та програмувати з командами, час від часу приєднуючись до розробки функцій. Але ніколи не поодинці! Швидше за допомогою парного програмування або, що ще краще, за допомогою методів (віддаленого) групового програмування.
5. Engineering Managers у ролі Scrum Masters?
Для когось я зараз можу здатися єретиком... Але якщо ви йтимете за ходом думок у цій статті, то ви побачите, що місія та обсяги роботи Engineering Manager-ів будуть певною мірою перетинатися із завданнями Scrum Master-а. Мій досвід показує, що вони перетинаються на 80% і більше.
То чи потрібні нам обидва? Engineering Manager та Scrum Master для групи команд? Ви можете обирати. Ці двоє можуть сформувати потужну керівну команду для навчання та розвитку інженерних процесів в організації.
Влітку 2021 року компанія Poster POS (українська SaaS для підприємств громадського харчування та роздрібної торгівлі) внесла цю зміну. Вони прибрали з команд роль Тім Ліда та вибрали кілька найнадійніших інженерів, які також були зацікавлені у покращенні виробничої системи шляхом наставництва інших. Тоді я грав роль Large-Scale Scrum Coach та тимчасового Scrum Master у Poster. Разом з Engineering Manager-ми ми сформували команду та керували змінами.
Коли я пішов із компанії, позиція Scrum Master була вакантною. І невдовзі на цю позицію замість Scrum Master-ів взяли Engineering Manager-ів.
Також, допомогло те, що чимало членів команди пройшли навчання фасилітації. Таким чином, вони могли проводити заходи, не покладаючись виключно на Scrum Master-ів. Це трохи полегшило роботу Engineering Manager / Scrum Master.
Вилучення Лідів із команд
Отже, варіанти є. Ви самі побачите, що саме спрацює краще... Але спершу вам потрібно виличути Лідів із ваших команд!
Comments