Общие проблемы, которых следует избегать при переходе к менеджеру

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

Вирус ответственности

В книге Алана Уоткинса 4D Leadership ¹ он цитирует работы Роджера Мартина (2003) о «вирусе ответственности». Вирус ответственности - это явление, когда кто-то, продвигающийся на руководящую должность, в попытке улучшить результаты вовлекается в работу, которую вместо этого следует делегировать. Вирусный аспект этого явления - влияние таких действий на все вовлеченные стороны.

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

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

Если практика чрезмерной ответственности не будет решена, менеджер обнаружит, что имеет дело с большим количеством вопросов, помимо своих фактических обязанностей, что приведет к эффектам, указанным на кривой характеристики давления Уоткинса:

Кривая эффективности давления показывает, что, хотя менеджер может чувствовать себя более продуктивным, чем когда-либо - его героическая работа не только принесла успех, но и укрепила то, что технически он все еще имеет «это», - в конечном итоге менеджер станет перегружен работой и перегружен. Еще большее беспокойство вызывает то, что такое поведение может поощряться высшим руководством, поскольку оно демонстрирует, что технический менеджер выходит за рамки служебного долга.

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

Признание того, что менеджмент работает в разных системах

В книге Рэя Дайло Принципы ² он пишет:

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

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

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

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

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

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

Оценивая динамику группы

Групповая динамика³ - это широкий термин, описывающий, как группы людей работают вместе. Ключевой компонент, который упускается из виду, - это роль разных личностей и их влияние на работу команды. Уинсборо и Чаморро-Премузико пишут:

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

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

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

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

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

Заключение

В этой статье я обрисовал несколько подводных камней, которые я считал опасными, пока новый менеджер пытается сориентироваться. Их объединяет то, что, не зная о таких проблемах, они могут иметь эффект, аналогичный техническому долгу. То есть, оставленные нерешенными вопросы, касающиеся плохого делегирования, недостаточного количества ресурсов и несоответствующего состава команды, могут излишне усложнить работу технического менеджера. Будем бдительны и проявлять любопытство к проблемам, возникающим в рамках вашей управленческой практики, мы надеемся, что вы сможете выявить скрытые противоречия и устранить их до того, как они станут настоящими проблемами. Желаемый результат - обеспечить, чтобы как можно больше времени руководства было потрачено на помощь вашей команде и организации в достижении долгосрочных положительных изменений.

использованная литература

1: Алан Уоткинс, 2016 г., Лидерство 4D: конкурентное преимущество через развитие вертикального лидерства. Https://www.amazon.com/4D-Leadership-Competitive-Advantage-Development-ebook/dp/B018IV01MY

2: Рэй Дайло, 2017, Принципы: жизнь и работа. Https://www.amazon.com/Principles-Life-Work-Ray-Dalio-ebook/dp/B071CTK28D/

3: Википедия, Групповая динамика. Https://en.wikipedia.org/wiki/Group_dynamics

4: Winsborough & Chamorro-Premuzic, 2017. Великие команды - это личностные качества, а не только навыки. Https://hbr.org/2017/01/great-teams-are-about-personalities-not-just-skills

5: Хистуан Хорват, Человек, прыгающий на бежевую бетонную стену. Https://www.pexels.com/photo/person-jumping-on-beige-concrete-wall-2244829/