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

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