«Антон, есть разговор. Не знаю, как бы сказать повежливее, но завязывай, пожалуйста, с микроменеджментом, я уже на стену от этого лезу!»
Это я-то?! Занимаюсь микроменеджментом??? Да я ведь просто пытаюсь помочь! Судите сами.
Обычный вторник, все работают удаленно, общение происходит в Slack.
12:00
Антон: Как дела с задачей? Могу чем-то быть полезен?
Боб: Нет, спасибо, я уже неплохо продвинулся.
15:30
Антон: Как оно, Боб? Дело движется? Если что-то понадобится, я на связи.
Боб: Да всё в порядке… Закончу к завтрашнему собранию, как и говорил.
Два дня спустя.
13:00
Оповещение на Pagerduty: /появляется
Боб: Беру в работу.
13:15
Антон: Отлично, спасибо. Я тоже посмотрел, похоже, проблема заключается в репозитории X, файле Y, строке 235, если нужна будет помощь с отладкой, обращайся.
Боб: (рукалицо) Антон, есть разговор…
Приведенная в начале статьи реплика вымышленная, однако все примеры взяты из реальной жизни.
Два примера, которые вы пронаблюдали выше, представляют два основных проявления микроменеджмента:
Микроменеджмент – это не тот порок, в котором бывают повинны только плохие руководители. Хорошие руководители тоже могут от него страдать. Лично я по-прежнему убежден, что мое вмешательство продиктовано искренним желанием помочь. Но тут важно понять: не имеет значения, что именно вами движет. В конце концов, благими намерениями вымощена дорога в ад. Мне понадобилось какое-то время, чтобы принять этот урок.
Я привык работать с джунами только-только из колледжа, а они требуют гораздо больше внимания. Для них всё внове: Docker, микросервисы, Jenkins, конфликты слияния и так далее, поэтому вовлеченность и готовность помочь у руководителя могут сыграть очень большую роль.
Мне до сих пор сложно переключиться на руководство сениорами (а в последний месяц – уже и техлидами), которых это только раздражает и отвлекает от работы.
Так что же делать?
Прежде всего это касается тех, кто работает удаленно – необходимо ясно до всех донести, какой режим коммуникации вы предпочитаете.
Хороших разработчиков-сениоров лучше вообще зря не беспокоить – когда понадобитесь, они сами к вам обратятся. Если возникает срочная задача, работу над которой непрерывно отслеживают какие-то команды или сотрудники, объясните разработчикам ситуацию, прежде чем просить о регулярных сводках. Не нужно предполагать, что они сами догадаются, почему вы их постоянно дергаете.
Если вы похожи на меня и чувствуете, что порывы всё контролировать очень трудно сдержать, поделитесь своими затруднениями с командой. Скажите, что понимаете, как это раздражает, и пытаетесь работать над собой. Попросите проявлять терпение и давать вам знать, когда вы выходите за рамки.
Простой способ облегчить для себя этот процесс – попросить команду предоставлять короткие (в одно-два предложения) письменные отчеты в конце дня. Для людей это не составит никакого труда, а вам будет спокойнее.
Это самая распространенная мера против микроменеджмента.
Поговорите со своей командой, расспросите их, какой формат общения им ближе и поддержки какого рода они ждут от вас. Давайте представим себе, что Боб из примера выше – застенчивый стажер, который боится попросить о помощи. При таком раскладе вопросы «У тебя всё в порядке? Могу чем-то помочь?» будут приняты с благодарностью и без всякого раздражения.
Большая часть руководителей останавливается на первом шаге и приходит к следующей схеме:
Это, конечно, лучше, чем надоедать всем без исключения, но все равно никуда не годится. Если какой-то джуниор пишет пятый кряду микросервис, так уж ли вы ему нужны? А если какой-то сениор работает в совершенно новой для себя области, сроки поджимают, проект щекотливый, точно ли стоит бросать его на произвол судьбы?
В своей книге «Высокоэффективный менеджмент» Эндрю Гроув представил понятие подготовленности к выполнению задачи. Цитируя автора, подготовленность к выполнению задачи «представляет собой сочетание уровня достижений, готовности взять на себя ответственность, а также образования, подготовки и опыта в данной области».
Представить концепцию в сжатом виде можно следующим образом:
Следует отметить один принципиально важный аспект этого подхода: если уровень подготовленности низкий, мы не можем просто пустить дело на самотек и предоставить людям возможность допускать ошибки:
Не выплескивайте вместе с водой ребенка: микроменеджмент – это не зло в чистом виде. Если вы зайдете слишком далеко в противоположном направлении и вообще не будете принимать участия в повседневной деятельности сотрудников, то от этого пострадают и команда, и организация, и клиенты. На эту тему есть отличная статья Таха Хуссейн с примерами из личной практики.
Это я-то?! Занимаюсь микроменеджментом??? Да я ведь просто пытаюсь помочь! Судите сами.
Обычный вторник, все работают удаленно, общение происходит в Slack.
12:00
Антон: Как дела с задачей? Могу чем-то быть полезен?
Боб: Нет, спасибо, я уже неплохо продвинулся.
15:30
Антон: Как оно, Боб? Дело движется? Если что-то понадобится, я на связи.
Боб: Да всё в порядке… Закончу к завтрашнему собранию, как и говорил.
Два дня спустя.
13:00
Оповещение на Pagerduty: /появляется
Боб: Беру в работу.
13:15
Антон: Отлично, спасибо. Я тоже посмотрел, похоже, проблема заключается в репозитории X, файле Y, строке 235, если нужна будет помощь с отладкой, обращайся.
Боб: (рукалицо) Антон, есть разговор…
Приведенная в начале статьи реплика вымышленная, однако все примеры взяты из реальной жизни.
Микроменеджмент из хороших побуждений остается микроменеджментом
Два примера, которые вы пронаблюдали выше, представляют два основных проявления микроменеджмента:
- Требовать, чтобы люди постоянно отчитывались
- Делать за людей их работу
Микроменеджмент – это не тот порок, в котором бывают повинны только плохие руководители. Хорошие руководители тоже могут от него страдать. Лично я по-прежнему убежден, что мое вмешательство продиктовано искренним желанием помочь. Но тут важно понять: не имеет значения, что именно вами движет. В конце концов, благими намерениями вымощена дорога в ад. Мне понадобилось какое-то время, чтобы принять этот урок.
Я привык работать с джунами только-только из колледжа, а они требуют гораздо больше внимания. Для них всё внове: Docker, микросервисы, Jenkins, конфликты слияния и так далее, поэтому вовлеченность и готовность помочь у руководителя могут сыграть очень большую роль.
Мне до сих пор сложно переключиться на руководство сениорами (а в последний месяц – уже и техлидами), которых это только раздражает и отвлекает от работы.
Так что же делать?
Шаг 0: обозначьте ожидания
Прежде всего это касается тех, кто работает удаленно – необходимо ясно до всех донести, какой режим коммуникации вы предпочитаете.
Хороших разработчиков-сениоров лучше вообще зря не беспокоить – когда понадобитесь, они сами к вам обратятся. Если возникает срочная задача, работу над которой непрерывно отслеживают какие-то команды или сотрудники, объясните разработчикам ситуацию, прежде чем просить о регулярных сводках. Не нужно предполагать, что они сами догадаются, почему вы их постоянно дергаете.
Если вы похожи на меня и чувствуете, что порывы всё контролировать очень трудно сдержать, поделитесь своими затруднениями с командой. Скажите, что понимаете, как это раздражает, и пытаетесь работать над собой. Попросите проявлять терпение и давать вам знать, когда вы выходите за рамки.
Простой способ облегчить для себя этот процесс – попросить команду предоставлять короткие (в одно-два предложения) письменные отчеты в конце дня. Для людей это не составит никакого труда, а вам будет спокойнее.
Шаг 1: настройтесь на своих подчиненных
Это самая распространенная мера против микроменеджмента.
Поговорите со своей командой, расспросите их, какой формат общения им ближе и поддержки какого рода они ждут от вас. Давайте представим себе, что Боб из примера выше – застенчивый стажер, который боится попросить о помощи. При таком раскладе вопросы «У тебя всё в порядке? Могу чем-то помочь?» будут приняты с благодарностью и без всякого раздражения.
Шаг 2: исходите из уровня подготовленности к выполнению задачи
Большая часть руководителей останавливается на первом шаге и приходит к следующей схеме:
- Если это джуниор, можно его контролировать сколько угодно
- Если это сениор, лучше оставить его в покое
Это, конечно, лучше, чем надоедать всем без исключения, но все равно никуда не годится. Если какой-то джуниор пишет пятый кряду микросервис, так уж ли вы ему нужны? А если какой-то сениор работает в совершенно новой для себя области, сроки поджимают, проект щекотливый, точно ли стоит бросать его на произвол судьбы?
В своей книге «Высокоэффективный менеджмент» Эндрю Гроув представил понятие подготовленности к выполнению задачи. Цитируя автора, подготовленность к выполнению задачи «представляет собой сочетание уровня достижений, готовности взять на себя ответственность, а также образования, подготовки и опыта в данной области».
Представить концепцию в сжатом виде можно следующим образом:
Важнейшей переменной, которая определяет, какой стиль руководства даст наилучшие результаты, является уровень подготовленности сотрудника к выполнению задачи.
Низкий уровень подготовленности у сотрудника
Основные характеристики эффективного стиля руководства: структурированность, ориентация на задачу, проговаривание «что», «когда» и «как».
Средний уровень подготовленности у сотрудника
Основные характеристики эффективного стиля руководства: ориентация на человека, упор на двустороннюю коммуникацию, поддержка, совместное обсуждение.
Высокий уровень подготовленности у сотрудника
Основные характеристики эффективного стиля руководства: минимальное вмешательство со стороны руководства, постановка целей, мониторинг.
Следует отметить один принципиально важный аспект этого подхода: если уровень подготовленности низкий, мы не можем просто пустить дело на самотек и предоставить людям возможность допускать ошибки:
Один мой знакомый, который всегда превосходно справлялся с работой, нанял джуниора, чтобы тот взял на себя некоторые из его старых задач, в то время как он займется новыми.
Подчиненный справился с задачами плохо. Реакция знакомого была такой: «Он должен совершать собственные ошибки. Только так и учатся!»
Проблема здесь в том, что обучение этого подчиненного оплачивается из кармана клиентов. И это совершенно недопустимо. Ответственность за обучение подчиненного должна возлагаться на его руководителя, а не переходить на клиентов его организации, будь они внешними или внутренними.
В заключение
Не выплескивайте вместе с водой ребенка: микроменеджмент – это не зло в чистом виде. Если вы зайдете слишком далеко в противоположном направлении и вообще не будете принимать участия в повседневной деятельности сотрудников, то от этого пострадают и команда, и организация, и клиенты. На эту тему есть отличная статья Таха Хуссейн с примерами из личной практики.
