Спостереження за машинами — Середня частина v5.1
При обговоренні організації команд мені часто задають питання: "Чому б не дати технічному лідеру керувати командою?" Моя відповідь — шипіння, як у вампіра, якому дали священну воду. На наступне питання: "Оскільки ви хочете мати менеджерів у своїх командах, чи може менеджер виконувати кодові рецензії?" — я загоряюсь вогнем.
Це питання постійно виникає. Але давайте трохи глибше подумаємо про це питання (і мою відповідь).
- Чому не повинен технічний лідер керувати командою?
- Чому не повинен інженерний менеджер виконувати кодові рецензії?
Як і з усім в технологіях, відповідь залежить від ситуації. Тут я намагаюсь відповісти на вічне питання "Чому TL не повинен керувати командою і чому EM з командою достатнього розміру не повинен рецензувати код?".
Ми розглядаємо три аспекти при відповіді на це питання: визначення ролі, складність комунікації в команді і розмір команди. Давайте розкриємо мої роздуми з корисними графіками. Попередження: дуже легка математика вперед.
Відмінність між ролями менеджера і технічного лідера
Спочатку розглянемо визначення ролей. Менеджер інженерії та технічний лідер — це дві різні ролі з різними навичками. Хтось може бути добрим у одній ролі, але не в іншій (і навпаки). Наприклад, найкращий програміст у команді не завжди є найкращою особою для організації всіх справ.
Однак команда потребує обох ролей для оптимальної роботи. Тому давайте порівняємо і зіставимо ці ролі.
Різниця у ролях і відповідальностях між TL і EM
Ця таблиця показує, чому, коли інженер просить стати менеджером, я починаю з раунду питань "Ти впевнений, що ти справді впевнений, що ти справді, дійсно впевнений", — оскільки це дуже різні ролі.
Ця таблиця відображає партнерство між технічним лідером і менеджером інженерії — розподіл праці між організаційно-комунікаційними функціями та глибоким технічним мисленням на практиці. Ролі є рівними за рівнем і обсягом на команді, але вони виконують різні дії для підтримки успіху команди.
Для того щоб партнерство між менеджером і лідером працювало, вони повинні будувати довіру між собою.
- Менеджер повинен делегувати технічне керівництво команди технічному лідеру і виходити з деталей. Менеджери не повинні виходити з автобуса і забувати десятиліття технічного досвіду. Однак управління в основному є політичною роботою, і менеджери повинні поважати межі. Все інше — це мікроменеджмент і порушення довіри.
- Технічний лідер повинен делегувати кар'єрний розвиток, ріст команди, комунікації та координацію роботи інженерному менеджеру і фокусуватися на архітектурі, технічних виборах, технічному напрямку і допомозі у виконанні.
Однак це розмежування менеджера/лідера не потрібно існувати до того часу, поки в команді не буде щонайменше 4 осіб. Нижче цього розміру команди межі розмиваються. Після розміру команди >= 4 ролі розділяються, і інженерний менеджер повинен фокусуватися на команді і інвестувати у партнерство довіри з технічним лідером.
Давайте побачимо, чому цей розмір >= 4 є точкою перегину.
О(n²) складність комунікації
Друге, давайте поговоримо про комунікації. Менеджер будує добре працюючу команду на міцних фундаментах комунікацій. При додаванні нових членів до команди шляхи комунікації на команді множаться. Інтуїтивно ми думаємо, що складність комунікацій в команді зростає в O(n) при додаванні людей до команди, але тут Міф про людський місяць на 100% правий.
Складність комунікацій в команді зростає (n * (n-1))/2) при додаванні нових людей до команди — або O(n²) квадратичний час.
- Спочатку ви єдиний член своєї команди, тому весь день говорите з собою.
0 шляхів комунікації, і не забувайте брати перерви на здоров'я.
- Ви додаєте 1 особу A до вашої команди. Тепер ви розмовляєте з A, і A розмовляє з вами — 1 шлях комунікації.
- Ви додаєте 1 особу B до вашої команди. Таким чином, ви керуєте 3 шляхами комунікації — ви — A, ви — B і A — B.
- Ви додаєте ще 1 особу C до вашої команди. Тепер ви керуєте 6 шляхами комунікації.
- І так далі.
Візуалізація шляхів комунікації в команді — всі мають спілкуватися з усіма!
Як тільки ми збудуємо команду з 5 осіб (6 загалом, ви + 5 інженерів) і додамо менеджера продукту та дослідника даних, менеджер команди повинен буде підтримувати 26 ((8*7)/2) взаємопов'язаних комунікаційних шляхів у команді, щоб команда могла виконувати свої завдання. Додайте сюди кілька партнерських команд і взаємодію з маркетингом, продажами та обслуговуванням клієнтів — управління командою раптово стає основною роботою.
Усі ці комунікаційні зв'язки є інвестицією в час. Менеджер є павуком в складній мережі комунікацій, включаючи:
- Чітке уточнення пріоритетів,
- Підтримка виконання команди,
- Координація статусів і випусків з зацікавленими сторонами,
- Забезпечення плавності процесів команди,
- Комунікація цілей команди та індивідуальних цілей, очікувань та успішності для кар'єрного зростання,
- Розбирання вузлів комунікації в команді,
- тощо.
Просто управління зустрічами навколо команди стає складним зі зростанням команди. Негативна сторона зростання команди називається дисекономія масштабів — чим більше масштабу додається до системи, тим більш жорсткою стає система і тим вище складність накладних витрат. Ця складність — причина, чому стендапи зупиняються зі збільшенням кількості людей на зустрічі.
І команда не може масштабуватися нескінченно — додавання нескінченної кількості людей до команди призведе до її розпаду при взаємопов'язаних комунікаційних зв'язках, що дорівнюють або перевищують [число Данбара,](https://en.wikipedia.
/org/wiki/TheMythicalMan-Month) менеджер вже не зможе керувати складністю комунікацій самостійно. Поріг становить близько 17 різних осіб (136 зв'язків), перш ніж менеджеру доведеться почати пріоритизувати взаємини, розбивати команду на дві або подальше делегування.
Вибух складності не пояснює, чому менеджер не повинен програмувати, але пояснює, чому календар менеджера перетворюється на "класичний календар менеджера" при певному розмірі команди, і час стає дорогоцінним.
Давайте побудуємо це графічно і побачимо, що відбувається візуально.
Крива розміру команди
В третьому розділі ми поговоримо про комунікації у залежності від розміру команди. Ми всі тут інженери. Якщо ми щось можемо зробити, то це побудувати графіки.
Ми будуємо графік складності взаємопов'язаних комунікацій і розміру команди, щоб побачити, коли менеджер повинен вийти з технологій і зосередитися на накладних витратах комунікації, необхідних для добре функціонуючої команди. (Ми включаємо менеджера в підрахунки, тому ці дані включають менеджера + інженерів.)
Графік розміру команди проти взаємопов'язаних комунікацій
При 1–3 членів команди взаємопов'язані комунікації керовані групою. Це все ще невелике і легке. І на цьому етапі лідер команди може виконувати роль Технічного Лідера Менеджера (TLM) — лідера невеликої технічної команди, який може все ще писати код і виконувати технічні функції, зберігаючи багато аспектів ролі менеджера: розвиток інженерів, проведення оцінок ефективності, управління накладними витратами співпраці з сусідніми командами та інше. Накладні витрати комунікації ще не стали приголомшливими, і можливо носити обидві шапки.
Закони квадратів починають діяти після 4, коли вже є 6 шляхів, які треба узгодити.
/org/wiki/TheMythicalMan-Month) менеджер більше не може самостійно керувати складністю комунікацій. Поріг становить приблизно 17 різних осіб (136 зв'язків), перед тим як менеджеру доведеться почати пріоритизувати відносини, розбивати команду на дві або подальше делегування.
Вибух складності не пояснює, чому менеджер не повинен кодити, але пояснює, чому календар менеджера перетворюється на "класичний календар менеджера" при певному розмірі команди, і час стає дорогоцінним.
Давайте побудуємо це графічно і побачимо, що відбувається візуально.
Крива розміру команди
У третьому пункті ми поговоримо про комунікації в залежності від розміру команди. Ми всі тут інженери. Якщо ми щось можемо зробити, то це побудувати графіки.
Ми будуємо графік складності взаємопов'язаних комунікацій і розміру команди, щоб побачити, коли менеджеру варто вийти з технологій і сконцентруватися на накладних витратах комунікації, необхідних для добре функціонуючої команди. (Ми включаємо менеджера в підрахунки, тому ці дані включають менеджера + інженерів.)
Графік розміру команди проти взаємопов'язаних комунікацій
При 1–3 членів команди взаємопов'язані комунікації керовані групою. Це все ще мале і легке. І на цьому етапі лідер команди може виконувати роль Технічного Лідера Менеджера (TLM) — лідера невеликої технічної команди, який може все ще писати код і виконувати технічні функції, зберігаючи багато аспектів ролі менеджера: розвиток інженерів, проведення оцінок ефективності, управління накладними витратами співпраці з сусідніми командами та інше. Накладні витрати комунікації ще не стали приголомшливими, і можливо носити обидві шапки.
Закони квадратів вступають в силу після 4, коли потрібно узгодити 6 шляхів.
6 не відчувається як великий наклад, але почніть думати про зростання, продуктивність, пріоритети і вирівнювання для 4 осіб, і вкладений час вистачає, щоб технічний вихід почав зменшуватися, і щось має дати — або вихід, або вірність комунікаціям — якщо одна особа виконує обидві ролі. Інженери перестають зростати. Код перестає випускатися. Команда заплутується в найважливіших речах.
4 — це чарівне число, коли Технічний Лідер Менеджер (TLM) повинен зробити вибір між Технічним Лідером чи Інженерним Менеджером, але не обома разом.
Як тільки до нас приєднується 5 членів команди, TLM-інг вилучається. Що станеться, якщо ніхто не вийде вперед і не прийме на себе роль комунікаційного лідера для команди? Частіше ніж ні, команда розпадається на безлад і перестає рухатися вперед у своїх пріоритетах. Команда і її зацікавлені сторони занадто заплутані. Хтось повинен встановити ясність і процеси, щоб дозволити інженерам робити те, що вони роблять найкраще: створювати чудові речі. Ця роль — це повноцінна робота.
Взаємопов'язана складність комунікацій — це також причина, чому великі команди природно розбиваються на підкоманди з 1–3 осіб для фокусу на проекті. При розмірі команди 1–3 накладні витрати комунікації управляються, і технічна робота виконується. Але, як тільки до команди додається 4-та особа, ми потрапляємо в світ кривої розміру команди...
Особливості: Про TLM-інг
Видно, що роль TLM є ідеальною для лідера, який може виконувати як управління людьми, так і технічну роботу, і охоплює краще обидві світи. Крім того, для малих компаній перетворення технічного лідера на TLM є зручним хаком для швидкої побудови команди.
Але TLM не є довгостроковою позицією, оскільки в кінцевому підсумку ролі Технічного Лідера і Інженерного Менеджера відрізняються. В результаті TLM — це тупик: виконання двох ролей одночасно (погано) без можливості керувати обсягом (технічним або командним), на який здатна спеціалізована людина в одній з цих ролей.
В кінцевому підсумку, ТЛМ (Technical Lead Manager) повинен обрати одну сферу або іншу для інвестиції 100% свого часу, інакше вони можуть стагнувати, оскільки не можуть розширювати свій обсяг.
Чому Інженерному Менеджеру не варто робити огляди коду
Зрештою, зведемо ці моменти разом і встановимо дві факти:
- Технічний Лідер і Інженерний Менеджер — це дві ролі, які співпрацюють для досягнення командної роботи. Тому вони повинні мати чіткі ролі та обов'язки і співпрацювати в міжособистісному партнерстві.
- Команди досягають точки перелому у розмірі приблизно на 4, коли хтось повинен віддати свій час комунікаціям для того, щоб команда працювала. Інакше команда розпадається на чорну діру безладу.
При розмірі команди >= 4, інженерний менеджер повинен зосередитися на своїй основній ролі — управлінні комунікаціями всередині і поза командою, фокусуванні на зростанні інженерів (також комунікації), і розумінні пріоритетів команди (знову ж таки, комунікації). А при достатньому розмірі команди >= 4, технічний лідер повинен зосередитися на архітектурі, технічних виборах і технічній роботі команди. Розділяй і перемагай — ось як команда досягає успіху.
Розкриваючи, як ми доходимо до кінця:
- Основна роль інженерного менеджера — управління комунікаціями всередині і за межами команди, включаючи кар'єрне, виконавче, планування та встановлення процесів команди. Ця робота з комунікаціями є значним вкладом у час.
- Після досягнення достатнього розміру команди менеджер повинен зробити вибір між технічним досвідом і інвестиціями в узгодження та комунікації через високу складність міжособистих зв'язків.
- Інженерний менеджер, який переглядає код, не тільки занедбує свою основну роль, але й мікроменеджмент технічного лідера. Ця дія є порушенням довіри.
-
І не лише мікроменеджмент, але й зневажливо до технічного лідера.
-
Це не означає, що інженерний менеджер не може брати участь у технічних обговореннях (особливо архітектурних оглядах), але технічний лідер визначає технології.
Отже, чому інженерному менеджеру з командою достатнього розміру не варто переглядати код. Довіра, делегування і комунікація — це основа ролі інженерного менеджера, і в цьому суть.
Перекладено з: Why an Engineering Manager Should Not Review Code