Я на самом деле видел, что происходит, когда «технический менеджер» слишком сильно вовлечен в повседневную механику проекта, и это не красиво. В нашем случае рассматриваемый менеджер не был мастером схватки, но пытался принять некоторые из этих решений; если бы у нас на самом деле не было отдельного мастера схватки для игры в защиту, то это было бы гораздо более болезненным.
(Кстати, это был не мой менеджер, поэтому я чувствую себя достаточно объективным в этом вопросе.)
Я перейду к тому, что я видел в качестве основного конфликта интересов; если вы не думаете, что что-то из этого применимо к вашей ситуации, то, возможно, вы можете сделать и то, и другое. Но убедитесь, что вы регулярно проверяете эти предположения, чтобы убедиться, что вы не попадаете ни в одну из следующих ловушек:
Технические руководители обычно отвечают за определенную роль в нескольких командах. Если это только одна команда, то это скорее «лидерство», чем «менеджер». Такое распределение ответственности означает меньше времени для команды и меньше времени для проекта / продукта, и, как правило, приводит к управлению стилями «наезд и беги».
Технические менеджеры имеют много других управленческих обязанностей для бизнеса. Они должны проводить коучинг / обучение, анализ производительности, интервьюирование / прием на работу, долгосрочное планирование инфраструктуры / ресурсов и многое другое. Это может легко стать работой на полный рабочий день само по себе и означает, что очень мало остается потратить на содействие.
Напряженный график может также навязать себя команде; Техническим менеджерам может потребоваться (или они захотят) пригласить членов команды на совещания в то время, которое команда считает неподходящим. Обычно работа мастера схватки заключается в том, чтобы управлять и пытаться устранить прерывания, но невозможно быть объективным в этом, когда у вас есть собственный график для беспокойства. Скрам-мастерам редко приходится встречаться отдельно с членами команды, потому что все эти встречи уже запланированы (встречи, ретроспективы и т. Д.)
Технические менеджеры должны иметь дело со сквозными проблемами проекта, и их естественным побуждением будет попытка стандартизировать все - библиотеки, управление исходным кодом, алгоритмы, макеты, цвета, что угодно. Хотя это на самом деле может быть хорошей вещью для компании, в конечном итоге никому не придется сражаться за то, что команда хочет сделать, и у них могут быть очень веские причины хотеть сделать что-то по-другому. Это противоречит идеалам «непрерывного улучшения», лежащим в основе Scrum и подобных методологий.
Менеджеры, которые имеют опыт работы в роли, которой они управляют, будут иметь свои довольно сильные представления о том, как должна выполняться работа и сколько времени это займет. Для менеджера это неплохая вещь , но как для мастера схватки это часто будет означать смещение членов команды к проектам или оценкам, с которыми они иначе не согласились бы - и они, вероятно, знают больше, чем вы, о рассматриваемой проблеме.
Члены команды всегда будут иметь проблемы с разграничением между запросом и заказом. Они не скажут вам этого и могут даже не осознавать этого сами. Даже если вы ясно даете понять, что вы просто спрашиваете, а не говорите, в их умах вы все равно являетесь их менеджером, и есть риск на уровне карьеры, чтобы сказать «нет». Это, вероятно, самая коварная из всех проблем, потому что вы ничего не можете с этим поделать - важно их отношение, а не ваше .
Если вы уверены, что никогда не попадете ни в одну из этих ловушек, тогда сделайте это ... но я повторяю, убедитесь, что вы часто проверяете свои предположения, общаясь со своей командой (и другими командами / менеджерами!) и убедитесь, что они не происходят тонким или неосознанным образом, который, возможно, вы не замечаете.
Положительно отметить, что я добавлю, что тот факт, что вы считаете проблему достаточно важной, чтобы на самом деле задать вопрос, означает, что вы, вероятно, довольно хороши в обеих ролях. Забота о команде, а не только о собственных карьерных амбициях, вероятно, составляет более половины того, что такое хороший менеджмент, в любом случае, в моих книгах.
... но быть хорошим в обоих случаях не обязательно означает, что вы можете быть хорошими в обоих одновременно, все время . Будьте осторожны с этим.