Вжиться в новую роль менеджеру, который перешёл из рядов разработчиков, может быть непросто. Он искренне хочет как лучше, но при этом часто переносит старые привычки и методы в уже иную ситуацию, где он может не только испортить отношения в коллективе, но и подорвать процесс разработки. Dice Insights собрал 5 распространённых ошибок новоиспечённых менеджеров-экс-разработчиков. Материал перевел и опубликовал DEV.BY.
Переживает синдром героя
Менеджер с этой проблемой не даёт команде шанс самостоятельно решать задачи и учиться на ошибках, а значит и развиваться. Такой менеджер не уверен в себе, он влезает везде и всюду, ведь без него никак не обойдутся.
Будь то для того, чтобы потешить своё эго, или потому, что ему не даёт покоя чужой успех, менеджеру с синдромом героя нравится думать, что он единственный может справиться с той или иной задачей.
Подчинённым стоит попробовать обсудить с ним такое поведение — только критика должна быть не оскорбительной, а конструктивной. Можно привести примеры ситуаций и объяснить, к чему привели действия менеджера и как повлияли на настрой коллектива.
Одна из функций руководителя — создавать комфортные условия для роста сотрудников. Если он будет отбирать у них задачи, это отобьёт желание проявлять инициативу, и они просто уйдут.
Не даёт чётких инструкций
Менеджерам из числа разработчиков бывает сложно ясно формулировать указания. Если человек привык быть неформальным лидером и вдохновлять других собственным примером, то получив «официальную» власть, он должен понимать, что теперь на нём лежит ответственность за постановку задач, дедлайнов и при необходимости — правил и требований.
В таком случае, чтобы избежать недопонимания, эксперты советуют фиксировать решения и план дальнейших действий в письменном виде. Когда команде нужно сделать выбор, можно выслать боссу список вариантов, предложить принять решение и ответить по почте. При устном обсуждении стратегий и приоритетов все договорённости тоже нужно записывать.
Микроменеджит
Некоторые новоиспечённые менеджеры до ужаса боятся делегировать задачи. Они тоже страдают от неуверенности, и чтобы проследить, что все задачи выполняются, заставляют команду отчитываться на бесконечных митингах.
Сотрудникам нужно попытаться убедить босса оставить их в покое, перестать дергать на митинги и просто дать делать свою работу. Можно спросить, зачем делать совещания так часто — возможно, его жёстко контролирует вышестоящий менеджер, и это аукается команде. Нужно дать понять, что микроменеджмент вредит процессу разработки, и убедить, что команда справится с заданиями.
Вмешивается
Если менеджер — по совместительству отличный разработчик, то его опыт и помощь ценят, и это идёт на благо всем. Если человек не был хорошим кодером до повышения, но при этом навязывает своё ограниченное видение и постоянно вмешивается в разработку, к добру это не приведёт.
Команда может попробовать мягко поставить менеджера на место, напомнить, что есть разделение труда и у каждого — свои обязанности, а ему следует заняться, например, коммуникацией с заказчиками или продакт-менеджерами.
Тормозит принятие решений
Некоторые менеджеры излишне педантично продумывают каждое решение, даже самое незначительное. Это может очень быстро застопорить рабочий процесс.
Сотрудники могут подтолкнуть такого босса в желаемом направлении и показать свою способность принимать решения. Например, можно представить ему какие-то факты или исследования, на которых они строили свои аргументы. Если это не сработает, нужно брать ситуацию в свои руки и самим принимать необходимые решения.
