👀 Руки прочь от кода: почему технический менеджер не должен ревьюить код

При обсуждении состава команды меня часто спрашивают: «Почему у вас нет техлида, который управляет командой?». В ответ я шиплю, как вампир, подвергшийся воздействию святой воды. После следующего вопроса: «Учитывая, что вам нужны менеджеры в ваших командах, может ли менеджер по-прежнему проводить проверки кода?» я загораюсь.

Этот вопрос возникает постоянно.

• Почему техлид (tech lead, сокращенно — TL) не должен управлять командой?
• Почему технический менеджер (engineering manager, сокр. EM) не должен проводить код-ревью?

Как и все в технике, ответ зависит от ситуации. Здесь я пытаюсь ответить на извечный вопрос: «Почему TL не должен руководить командой и почему EM с командой достаточного размера не должен проверять код?». При ответе на этот вопрос мы учитываем три аспекта: определение роли, сложность взаимодействия в команде и размер команды. Давайте проиллюстрирую мои рассуждения с помощью полезной графики. Предупреждение: впереди очень легкая математика.

Разница между ролями менеджера и техлида

Во-первых, давайте опишем роли. Технический менеджер и техлид— это две разные роли с разными наборами навыков. Кто-то может быть хорош в одной роли, но не в другой (и наоборот). Например, лучший программист в команде не всегда лучший организатор.

Однако для оптимальной работы команде нужны обе роли. Итак, давайте сравним и сопоставим роли.

Данное изображение и все остальные взяты отсюда. Разница в роли и ответственности между TL и EM

Вот почему, когда инженер просит стать менеджером, я начинаю с серии вопросов «Вы уверены, вы действительно уверены, вы действительно-действительно уверены?» — потому что это очень разные роли.

Эта таблица отражает партнерские отношения между техлидом и техническим менеджером — разделение труда между организационными и коммуникационными трудами и глубоким техническим мышлением. Роли одинаковы по уровню и масштабу в команде, но каждый предпринимает разные действия для поддержки успеха команды.

Чтобы партнерство менеджера и лидера работало, им необходимо построить доверительные отношения между собой.

• Менеджер должен делегировать техническое руководство командой техническому руководителю и действовать стратегически. Менеджеры не должны выпадать из автобуса и забывать десятилетия технического опыта. Однако управление — это, по сути, политическая работа, и менеджеры должны уважать границы. Все остальное — это микроуправление и нарушение доверия.
• Технический руководитель должен делегировать работу по карьере, развитию команды, коммуникациям и координации техническому менеджеру и сосредоточиться на архитектуре, технических решениях, техническом руководстве и помощи в выполнении.

Однако это различие между менеджером и руководителем может отсутствовать, пока в команде не наберется хотя бы 4-х человека. Ниже этого размера команды линии размываются. После того как размер команды >= 4, роли разделяются, и технический руководитель должен сосредоточиться на команде и инвестировать в доверительное партнерство с техническим руководителем.

Давайте посмотрим, почему размер >= 4 является точкой перегиба.

O(n²) сложность связи

Во-вторых, давайте поговорим о коммуникациях. Менеджер строит хорошо работающую команду на прочных основах коммуникации. По мере того как мы добавляем членов в команду, пути коммуникации в команде умножаются. Мы интуитивно думаем, что сложность взаимодействия в команде возрастает на O(n) по мере того, как мы добавляем людей в команду, но здесь Mythical Man Month на 100% соответствует действительности.

Сложность коммуникаций в команде возрастает (n * (n-1))/2) по мере того, как к команде присоединяются новые люди, или за O(n²) квадратичное время.

• Сначала вы единственный человек в своей команде, поэтому весь день разговариваете сами с собой. 0 путей сообщения, и не забывайте делать перерывы на здоровье.
• Вы добавляете 1-го человека А в свою команду. Теперь вы разговариваете с А, а А разговаривает с вами — 1 канал связи.
• Вы добавляете 1-го человека B в свою команду. Итак, теперь вы управляете тремя коммуникационными путями — вы — А, вы — Б и А — Б.
• Вы добавляете в команду еще 1-го человека C. Итак, теперь вы управляете шестью коммуникационными путями.
• И так далее.

Как только мы создадим команду из 5 человек (всего 6, вы + 5 инженеров) и добавим менеджера по продукту и специалиста по данным, менеджер команды должен поддерживать (8*7)/2 = 26 взаимосвязанных каналов связи, чтобы команда могла работать. Добавьте несколько команд партнеров и займитесь маркетингом, продажами и обслуживанием клиентов — управление командой внезапно становится повседневной работой.

Все эти коммуникационные взаимосвязи представляют собой инвестиции во времени. Менеджер — это паук в паутине сложных коммуникаций, включая:

• Четкое определение приоритетов.
• Введение командной работы.
• Согласование статуса и релизов с заинтересованными сторонами.
• Бесперебойное управление процессами команды.
• Обсуждение командных и индивидуальных целей, ожиданий и результатов для карьерного роста.
• Распутывание коммуникационных узлов в команде.
• и т. д.

Простое управление встречами в команде становится сложным по мере роста команды. Отрицательной стороной роста команды является отсутствие эффекта масштаба: чем больше масштаба добавляется к системе, тем более жесткой она становится и тем выше затраты на сложность. Эта сложность является причиной того, что чем больше людей участвует в совещании, тем быстрее оно прекращается.

И команда не может масштабироваться бесконечно — добавление бесконечного количества людей в команду приведет к тому, что команда взорвется. При коммуникационных взаимосвязях, равных или превышающих число Данбара, менеджер уже не может самостоятельно управлять сложностью связи. Порог составляет около 17-ти разных людей (136 контактов), прежде чем менеджер должен начать расставлять приоритеты в отношениях, разбивать команду на две части или делегировать дополнительные полномочия.

«Взрыв сложности» не объясняет, почему менеджер не должен программировать, но объясняет, почему календарь менеджера превращается в «классический календарь менеджера» при определенном размере команды, а время становится ценным.

Давайте визуализируем это и посмотрим.

Кривая размера команды

В-третьих, мы говорим об общении с командой. Мы все здесь инженеры. Если мы можем что-то сделать, так это графики.

Мы строим график сложности взаимосвязанных коммуникаций и размера команды, чтобы увидеть, когда менеджер должен отказаться от технологий и сосредоточиться на накладных расходах на связь, необходимых для хорошо функционирующей команды. (Мы включаем менеджера в подсчет, так что это подсчет менеджер + инженеры.)

При 1–3 членах команды коммуникационными соединениями управляет группа. Группа еще маленькая. И при таком размере руководитель группы может выполнять роль технического ведущего менеджера (TLM) — лидера небольшой технической группы, который по-прежнему может писать код и выполнять технические функции, сохраняя при этом многие аспекты роли менеджера: подготовка инженеров, проведение обзоров производительности, управление накладными расходами на сотрудничество с соседними командами и т. д. Коммуникационная нагрузка еще не стала непомерной, и можно носить обе шляпы.

Законы квадратуры начинают действовать после 4-х, когда нужно согласовать 6 путей. Шесть путей не кажутся большими накладными расходами, но если начать думать о росте, производительности, расстановке приоритетов и согласовании для 4-х человек, это потребует достаточных временных инвестиций, чтобы технические результаты начали снижаться, и что-то должно измениться – либо результаты, либо качество коммуникаций – если один человек выполняет обе роли. Инженеры перестают расти. Код перестает поставляться. Команда начинает путаться в самых важных вещах.

4 — это магическое число, когда TLM должен сделать выбор между Техническим руководителем или Техническим менеджером, но не обоими сразу.

Рассмотрим команду из 5-ти человек. Что произойдет, если никто не выступит и не возьмет на себя коммуникационную роль в команде? Чаще всего команда скатывается в трэш и перестает двигаться вперед по своим приоритетам. Команда и заинтересованные стороны слишком запутались. Кто-то должен установить ясность и наладить процесс, чтобы позволить инженерам делать то, что у них получается лучше всего: потрясающе выполнять свою работу. Эта роль — полноценная работа.

Сложность взаимосвязанных коммуникаций также является причиной того, что большие команды естественным образом разбиваются на подгруппы по 1–3 человека, чтобы сосредоточиться на проекте. При размере команды 1–3 накладные расходы на коммуникацию вполне управляемы, и техническая работа выполняется. Но, добавив четвертого человека, мы вошли в мир кривой размера команды…

Отступление: О TLM-инжиниринге

Казалось бы, роль TLM — это идеальная роль, которая позволяет лидеру выполнять некоторую управленческую и техническую работу и включает в себя лучшее из обоих миров. Более того, для небольших компаний преобразование технического лида в TLM — удобный лайфхак для быстрого создания команды.

Но TLM не является долгосрочной позицией, потому что, в конечном счете, роли технического руководителя и технического менеджера различны. В результате TLM оказывается в тупике: он выполняет две роли одновременно (плохо), не имея возможности управлять масштабами (техническими или командными). В конечном итоге, TLM придется выбрать одну роль для инвестирования 100% своего времени, иначе он окажется в застое.

Почему технический менеджер не должен проводить код-ревью

Наконец, сведя эти следы вместе, мы установили два факта:

• Технический руководитель и технический менеджер — две роли, которые объединяются для совместной работы. Поэтому у них должны быть четкие роли и обязанности, и они должны сотрудничать во взаимном партнерстве.
• Команды достигли критической точки размера ~4, когда кто-то должен посвятить свое время коммуникациям, чтобы команда работала. В противном случае команда рухнет в черную дыру трэша.

При размере команды >= 4 технический менеджер должен сосредоточиться на своей основной роли — управлении коммуникациями внутри и вне команды, сосредоточении внимания на росте инженера (также на коммуникациях) и понимании приоритетов команды (опять же на коммуникациях). А при размере команды >= 4 технический руководитель должен сосредоточиться на архитектуре, технических решениях и технической работе команды. Разделяй и властвуй — вот как команда добивается успеха.

Выводы:

• Основная роль технического менеджера заключается в управлении коммуникациями внутри команды и за ее пределами, включая вопросы карьеры, производительности, планирования и настройки командных процессов. Эта коммуникационная работа требует значительных затрат времени.
• После достижения достаточного размера команды менеджер должен обменять техническую эрудицию на инвестиции в коммуникации, потому что коммуникационные взаимосвязи высоки.
• А при достаточном размере команды накладные расходы на коммуникацию могут быть настолько высокими, что менеджер должен выбирать и выбирать, иначе он будет перегружен одной этой работой из-за сложности.
• Технический менеджер, который выполняет код-ревью, не только пренебрегает своей основной ролью, но и контролирует техническое руководство на микроуровне. Эта деятельность является нарушением доверия.
• И это не только микроуправление, но и снисходительность к техническому руководителю.
• Это не означает, что технический руководитель не может участвовать в технических обсуждениях (особенно обзорах архитектуры), но технический руководитель управляет технологией.

Доверие, делегирование полномочий и коммуникация — вот что лежит в основе роли технического менеджера.