Кесарю — кесарево, слесарю — слесарево (с) Народная мудрость.

В жизни каждого руководителя наступает момент, когда он вынужден оставить часть работы, которую раньше выполнял с большим удовольствием (вы же обратили внимание на слово «часть», да?). Другими словами, кодить или не кодить? Вот в чём вопрос. Точнее для меня вопроса нет. Про это ниже.

Дисклеймер:

Менеджером я называю любого, кто так или иначе занят управлением кем-то и чем-то. Это может быть и старший инженер, который управляет работой мидлов так или иначе, и тимлид, и начальник отдела, и СТО. В тексте ниже я использую этот термин для простоты повествования, потому как на самом деле, чем выше руководитель, тем больше он менеджер в классическом понимании, и тем более явно вылезает эта проблема, но если бы я начал описывать все градации ошибок менеджеров, начиная от синьора и выше, я бы написал книгу:)

Я много лет менеджер, и чуть поменьше лет руковожу большими командами, поэтому в тексте явно это читается. Если команда маленькая, то всё, что написано стоит делить на 3.14 как минимум, но не переставать учитывать вообще.

Местами я осознанно сгущаю краски, но куда ж без этого.

Делегируйте проблемы и не возвращайте их

Часто когда менеджер видит проблему, возникает соблазн вмешаться и помочь. Либо что-то закодить и решить проблему самостоятельно, либо очень популярно объяснить людям, как ее исправить. Особенно ярко это проявляется в начале менеджерского пути, когда уровень компетенций в своей «прошлой» работе всё ещё соизмерим с коллегами. Беда в том, что такой подход на самом деле не очень хороший. Часто он разрушительный. Вы как будто не доверяете своей команде и людям, как бы говорите — я тут всё держу под контролем, я за все отвечаю, я всегда спешу на помощь и делаю вашу работу.

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

Мир устроен так, что со временем (и тут очень небольшим) когда становимся менеджерами, наши навыки решения проблем уровнем ниже начинают ослабевать — по крайней мере, должны, если мы становимся, ну или хотим становиться, хорошими менеджерами. Почему? Потому что мы проводим больше времени с людьми в команде и с другими менеджерами и меньше времени с кодом, тестами, требованиями или любой другой частью организации, из которой вы пришли. Т.е. «техническая» работа переходит в менеджерскую. И начинается замещение, которое очень сложно измеримое даже на уровне качественных оценок.

Знай, что ты умеешь и делай это

Лучшее, что можно сделать менеджеру, — это создать среду, в которой люди могут выполнять свою работу наилучшим образом, расти и развиваться. Иногда это означает организацию встреч для решения проблем. Иногда это означает, что у них достаточно серверов, времени на написание тестов, рук для выполнения всех задач. Иногда это означает, что нужно держать других людей, например, вашего менеджера, подальше и не допускать до процесса, чтобы они ничего не испортили. Это может даже означать, что вы помогаете читать код или даже что-то писать или тестировать, помогаете сделать 1:1 или провести ретроспективу. Но на длинной дистанции «техническая» помощь вряд ли будет полезна, хотя всегда (я 15 лет менеджер и всё ещё хочу) будет очень хотеться помочь.

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

Но мой менеджер ожидает, что я сделаю и то, и другое.

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

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

И в ряде случаев придётся объяснять своего руководителю этот факт: управление выше «технической» работы. Вы доверяете работу своей команде. Вы можете помочь ей с решением проблем. Возможно, вы даже сможете внести свой вклад непосредственно в решение задачи или проблемы. Но копаться в коде, тестах, требованиях или управлении проектами только вредит вашей команде.

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

Менеджмент может быть не для вас

Если вы не можете отвлечься от технической работы, то есть пара вариантов:

1. Ваша команда слабая на столько, что никак без вас не может справиться, а значит пора применять управленческие техники для улучшения команды (обучение, найм более опытных сотрудников, перераспределение задач и пр)
2. Вы просто не очень готовы и хотите заниматься управлением, делегированием и вот этим всем, тяготея к реальным задачам, а не к презентациям и графикам. Тогда снова нужно доставать управленческие техники и идти обсуждать этот вопрос со своим руководителем. В конце концов — лучше быть хорошим инженером, чем плохим менеджером.

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

Больше эпизодов про значение личности тут

Обновления блога доступны в Телеграмм-канале

[sgmb id=»1″]