Почему инженер-менеджер не должен проверять код

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

Этот вопрос возникает постоянно. Но давайте подумаем об этом вопросе (и моем ответе) немного глубже.

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

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

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

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

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

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

Эта таблица объясняет, почему, когда инженер предлагает стать менеджером, я начинаю с серии вопросов "Вы уверены, что вы действительно уверены, вы действительно действительно уверены?", потому что это очень разные роли.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте построим это и посмотрим, что происходит визуально.

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

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

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

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

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

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

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

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

В стороне: о TLM-ing

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

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

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

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

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

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

Распаковка как доходим до конца:

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

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