Должен ли менеджер кодить?

DISCLAIMER: данные размышления в значительной степени относятся к менеджерам продуктовых компаний и, как мне кажется, менее применимы к миру аутсорса.

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

(*) Об этом не раз писал Joe Duffy в постах и твитах, а также Michael Lopp в своей книге Managing Humans.

Как и в многих других вещах, ответ на вопрос Кодить или нет? несколько сложнее, чем может показаться и не подразумевает бинарной логики в ответе да или нет.

Почему нужно перестать кодить?

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

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

Активное вмешательство менеджера в детали работы команды имеет ряд негативных последствий:

• Микроменеджмент.
  Слишком детальное вникание в задачу приводит к микроменеджменту: Ой, а почему эта задача занимает 3 дня? Я б ее сделал за 2 часа!. Да ну, а чего это ты тут всего два класса, тут стратегия с синглтоном в декораторе нужны!. Я поговорил с заказчиком и нам нужно сделать апишку, через которую мы выставим наружу парсинг данных. Для этого нужен метод, который будет принимать строку и возвращать XDocument, а в случае невавлидных данных бросать CustomArgumentExcception.. Все эти советы могут быть полезны, но они подавляют инициативу и переводят общения из русла проблема-решения в решение-кривое решение.
  Хороший менеджер понимает, что с разными сотрудниками нужно говорить на разном уровне абстракции. Для неопытного человека лучше декомпозировать задачу самостоятельно, а для матерого или около того специалиста, лучше лишь описать задачу и дать ему возможность самостоятельно прийти к решению (которое можно и нужно провалидировать, но свое собственное решение навязывать не стоит).
  
• Подавление инициативы.
  Вместо того, чтобы дать команде ошибаться, вы решаете проблему самостоятельно. Да, это решит проблему сейчас, но будет губительным для команды за пределами текущего спринта. Ошибки это лучший способ познания и попытка оградить от них команду является глупой затеей.
  Даже если сейчас менеджер является самым опытным, он вряд ли сможет принимать решение за всех членов команды, да и просто статистически, все они не могут быть правильными.
  
• Совмещать две роли очень сложно.
  Кодирование и менеджмент требуют разного режима работы мозга. Менеджер должен одновременно держать в голове множество вещей: Потереть с Василием о его проблемах на следующем one-on-one, Оповестить моего менеджера о возможных задержках в сроках, Узнать, в чем проблема с текущим релизом у QA-менеджера, Решить проблему с освещением, которое перенесли уже 4 раза, Навести порядок с багами и т.п.
  В процессе разработки фичи используется другой режим работы мозга: нужно погрузиться в одну задачу и думать ее до посинения. Попытка совместить эти два режима работы обычно приводит к плачевным результатам, в результате код, который выходит из-под пера менеджера дурно пахнет, а задачи, которые лежат непосредственно на нем никуда не двигаются.
  Очень хорошо проблемы совмещения заметны по многим тим-лидам, которые зачастую выполняют часть менеджерской работы с множеством митингов, и пытаются браться за сложные задачи на проекте. Обычно выходит плохо и там, и там.
  

Почему нужно продолжать кодить?

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

Подавляющее число менеджеров таки обладает техническими навыками, которые помогают им понимать, что что-то идет не так, что внутренние процессы протухли, а Вася Пупкин явно вешает лапшу на уши. Но поскольку индустрия не стоит на месте, технические навыки менеджера не только атрофируются в связи с отсутствием практики, но и банально устаревают. А это значит, что у менеджера пропадает основа, на которой *могут* строиться некоторые из его решений.

Вот несколько моментов, почему стоит подумать о поддержании навыков кодирования хотя бы на базовом уровне:

• Говорить с командой на одном языке.
  Актуальные технические навыки позволяют говорить с командой на одном языке. Даже если какие-то тонкости будут не понятны, то базовые знания позволят понять проблему в общих чертах: Мы тут боремся с утечками памяти в .NET приложении и стараемся уменьшить время жизни объектов, чтобы они не переживали нулевое поколение. Мы изначально выбрали изменяемые структуры данных, а теперь отгребаем проблемы в многопоточной среде. Нам нужно сделать неизменяемый фасад, но до этого измерить memory footprint новой версии.
  
• Быть частью команды.
  Иногда полезно дать понять команде, что менеджер еще могёт закатать рукава и пофиксить багу. Технари уважают технарей и плохо относятся к руководителям, которые окончательно оторвались от мира разработки. Спускаясь иногда с менеджерских небес на землю позволит менеджеру лучше понять проблемы команды: насколько эффективны инструменты, какие есть проблемы с CI-сервером, что не так с дизайном и покрытием тестами.
  Подобное понимание может изменить отношение к задачам без видимого результата, которые до этого казались бессмысленными, ибо не приносили пользу заказчику или бизнесу.
  
• Улучшать процессы исходя из современного понимания технологий.
  Технологии не стоят на месте, а вместе с ними развиваются и процессы. Все эти devops-ы, микросервисы, облака и тучи, все это меняет то, как выглядит процесс разработки. Менеджер должен понимать, как все это влияет на жизнь разработчиков и быть с индустрией хотя бы чутка на одной волне.
• Декомпозиция задач по стыкам компонентов.
  Помимо кодинга, менеджеру полезно понимать немного в дизайне и архитектуре. Это нужно для того, чтобы задача была разбита по швам системы, а не была ровно размазанна по всем компонентам. И хотя иногда именно cross-cutting изменения полезны, важно, чтобы это происходило осознанно, а не по воле случая.

Итого?

У менеджера есть куча своих задач и он никогда не сможет выполнять работу наравне с разработчиками. Более того, подобные попытки приведут к плачевным последствиям из-за нехватки времени и обилия других задач.

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

Можно взять пример Джо Даффи, который будучи директором по разработке продолжает радовать техническими постами и явно увлекается новыми технологиями.

Many years ago, a mentor of mine set two - and only two - rules for our team: 1) no jerks, 2) everybody codes. Ever since, I've kept them.

Joe Duffy (@xjoeduffyx) May 7, 2015