«Антон, есть разговор. Не знаю, как бы сказать повежливее, но завязывай, пожалуйста, с микроменеджментом, я уже на стену от этого лезу!»

Это я-то?! Занимаюсь микроменеджментом??? Да я ведь просто пытаюсь помочь! Судите сами.

Обычный вторник, все работают удаленно, общение происходит в Slack.
12:00
Антон: Как дела с задачей? Могу чем-то быть полезен?
Боб: Нет, спасибо, я уже неплохо продвинулся.
15:30
Антон: Как оно, Боб? Дело движется? Если что-то понадобится, я на связи.
Боб: Да всё в порядке… Закончу к завтрашнему собранию, как и говорил.

Два дня спустя.
13:00
Оповещение на Pagerduty: /появляется
Боб: Беру в работу.
13:15
Антон: Отлично, спасибо. Я тоже посмотрел, похоже, проблема заключается в репозитории X, файле Y, строке 235, если нужна будет помощь с отладкой, обращайся.
Боб: (рукалицо) Антон, есть разговор…

Приведенная в начале статьи реплика вымышленная, однако все примеры взяты из реальной жизни.

Микроменеджмент из хороших побуждений остается микроменеджментом


Два примера, которые вы пронаблюдали выше, представляют два основных проявления микроменеджмента:

  • Требовать, чтобы люди постоянно отчитывались
  • Делать за людей их работу

Микроменеджмент – это не тот порок, в котором бывают повинны только плохие руководители. Хорошие руководители тоже могут от него страдать. Лично я по-прежнему убежден, что мое вмешательство продиктовано искренним желанием помочь. Но тут важно понять: не имеет значения, что именно вами движет. В конце концов, благими намерениями вымощена дорога в ад. Мне понадобилось какое-то время, чтобы принять этот урок.

Я привык работать с джунами только-только из колледжа, а они требуют гораздо больше внимания. Для них всё внове: Docker, микросервисы, Jenkins, конфликты слияния и так далее, поэтому вовлеченность и готовность помочь у руководителя могут сыграть очень большую роль.
Мне до сих пор сложно переключиться на руководство сениорами (а в последний месяц – уже и техлидами), которых это только раздражает и отвлекает от работы.

Так что же делать?

Шаг 0: обозначьте ожидания


Прежде всего это касается тех, кто работает удаленно – необходимо ясно до всех донести, какой режим коммуникации вы предпочитаете.

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

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

Простой способ облегчить для себя этот процесс – попросить команду предоставлять короткие (в одно-два предложения) письменные отчеты в конце дня. Для людей это не составит никакого труда, а вам будет спокойнее.

Шаг 1: настройтесь на своих подчиненных


Это самая распространенная мера против микроменеджмента.

Поговорите со своей командой, расспросите их, какой формат общения им ближе и поддержки какого рода они ждут от вас. Давайте представим себе, что Боб из примера выше – застенчивый стажер, который боится попросить о помощи. При таком раскладе вопросы «У тебя всё в порядке? Могу чем-то помочь?» будут приняты с благодарностью и без всякого раздражения.

Шаг 2: исходите из уровня подготовленности к выполнению задачи


Большая часть руководителей останавливается на первом шаге и приходит к следующей схеме:

  • Если это джуниор, можно его контролировать сколько угодно
  • Если это сениор, лучше оставить его в покое

Это, конечно, лучше, чем надоедать всем без исключения, но все равно никуда не годится. Если какой-то джуниор пишет пятый кряду микросервис, так уж ли вы ему нужны? А если какой-то сениор работает в совершенно новой для себя области, сроки поджимают, проект щекотливый, точно ли стоит бросать его на произвол судьбы?

В своей книге «Высокоэффективный менеджмент» Эндрю Гроув представил понятие подготовленности к выполнению задачи. Цитируя автора, подготовленность к выполнению задачи «представляет собой сочетание уровня достижений, готовности взять на себя ответственность, а также образования, подготовки и опыта в данной области».

Представить концепцию в сжатом виде можно следующим образом:

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

Низкий уровень подготовленности у сотрудника
Основные характеристики эффективного стиля руководства: структурированность, ориентация на задачу, проговаривание «что», «когда» и «как».

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

Высокий уровень подготовленности у сотрудника

Основные характеристики эффективного стиля руководства: минимальное вмешательство со стороны руководства, постановка целей, мониторинг.


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

Один мой знакомый, который всегда превосходно справлялся с работой, нанял джуниора, чтобы тот взял на себя некоторые из его старых задач, в то время как он займется новыми.
Подчиненный справился с задачами плохо. Реакция знакомого была такой: «Он должен совершать собственные ошибки. Только так и учатся!»
Проблема здесь в том, что обучение этого подчиненного оплачивается из кармана клиентов. И это совершенно недопустимо. Ответственность за обучение подчиненного должна возлагаться на его руководителя, а не переходить на клиентов его организации, будь они внешними или внутренними.


В заключение


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

Комментарии (8)


  1. vadimr
    19.04.2024 07:38
    +6

    Проблема здесь в том, что обучение этого подчиненного оплачивается из кармана клиентов. И это совершенно недопустимо.

    Кем недопустимо? Пока клиенты платят, я тут не вижу проблемы. Вдобавок, расходуется рабочее время дешёвого сотрудника вместо дорогого руководителя.


    1. hira
      19.04.2024 07:38
      +11

      Не стоит ещё забывать о том, что ВСЁ оплачивается из кармана клиентов.

      Вообще всё. В любом бизнесе. Иначе быть не может.


    1. avost
      19.04.2024 07:38
      +3

      >Кем недопустимо? Пока клиенты платят, я тут не вижу проблемы.

      Возможно, тут неудачная формулировка и имелось в виду не "платит", а "расплачивается", то есть клиенту попадают ошибочные решения/реализации и клиент страдает. Это действительно недопустимо.

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


  1. ManGegenMann
    19.04.2024 07:38
    +2

    Если это сениор, лучше оставить его в покое

    Только если он уже прошёл этап онбординга. Мне сейчас приходится клещами рвать время на то чтобы мне кто-то давал пояснения и ответы на мои вопросы. Про то что задачи также необходимо буквально выпрашивать мы молчим.

    Чет подозреваю такие проблемы везде. Люди не готовы к найму сениоров и мидлов, думают "ну щас наняли человека опытом, а он там сам разберётся" и это действительно работает, но только если есть подробная документация на каждый из ваших 30 микросервисов и на их взаимодействие и подробное. Также неплохо если вашу систему можно целиком раскатать на локальной машине и тыкать.

    Но мы живем в реальности поэтому документации нет, система из 30 микросервисов на машине не выйдет раскатать, дампа базы для этих целейтем более не существует.


  1. alldark
    19.04.2024 07:38

    Проблема здесь в том, что обучение этого подчиненного оплачивается из кармана клиентов

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

    Вопрос качества (обучения в том числе) здесь идёт параллельно, это не связано с деньгами, а с ответственностью.


  1. FroseMan
    19.04.2024 07:38
    +3

    Раздражает, когда пишет аналитик "могу созвониться с тобой, помочь", а ты делаешь на 100% техническую часть в какой-то новой для всех области. Например, писал под мобилу, а тут надо немного веба сделать. Т.е тебе сложно разобраться, остальным разрабам тоже сложно, а тебе написывают "ну ты там имей в виду, очень важная штука". А то я сам не знаю, лезете тут со своими 5 минутками. "Могу тебе помочь, собрать созвон". В такие моменты хочется сказать "давай ты просто сделаешь за меня, а я созвон соберу, окей епта".


    1. ManGegenMann
      19.04.2024 07:38

      Как же меня морозит с этих созвонов. Мы вот вообще все будем всем табаром делать? Может ещё генирального позовём и весь совет директоров.


  1. AlexKMK
    19.04.2024 07:38

    В чем проблема в темпо раз в 4 часа отписываться на что эти 4 часа потрачены в рамках тикета?

    Когда это поделаешь недельку, то оно потом происходит автоматом, а на своё время начинаешь смотреть по другому.

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