Микроменеджмент полицейского, «матушкин» менеджмент тетушки и мастерский менеджмент шерифа — в чём разница стилей управления, как определить свой стиль и как его изменить.
1 марта 2021
Менеджмент в Мэйберри: разбор трех сильно отличающихся стилей управления
Оригинальная статья: Managing in Mayberry: An examination of three distinct leadership styles
Микроменеджмент полицейского, «матушкин» менеджмент тетушки и мастерский менеджмент шерифа — в чём разница стилей управления, как определить свой стиль и как его изменить — в переводе нашего основателя Ивана Боровикова.
В Северной Каролине, недалеко от гор Блю Ридж (не так далеко, как могло бы показаться) есть городишко под названием Мэйберри.
Несмотря на то, что главная местная автомагистраль была построена в обход города, в городе-тезке популярного ТВ-шоу 1960-х жизнь бьет ключом, и приличный объем автотрафика каждое утро въезжает в центральную часть Мэйберри с севера по 52-му шоссе. Во время консалтинговой недели, пока мы были в городе, у нас была возможность наблюдать события, связанные с ремонтом дороги, и поведение трех местных жителей, каждый из которых продемонстрировал свой собственный стиль управления проектом. Давайте подробнее посмотрим на то, насколько эти стили управления пересекаются с распространенными стилями управления в софтверных проектах.
Когда из-за дорожных работ сразу к северу от города было перекрыто 52-е шоссе, весь утренний трафик, направляющийся в город с севера, был вынужден уходить на правое ответвление на развязку, чтобы въехать в центр города через Ки-стрит. К сожалению, для этого машинам приходилось делать левый поворот на Ки-стрит, пересекая довольно активный трафик, движущийся с востока на запад:
Городской совет опасался, что во время утренних «горячих» часов очередь из машин, ждущих левый поворот на Ки-стрит, вытянется за пределы рампы на само 52-е шоссе. Учитывая высокий скоростной лимит на 52-м (65 миль/ч, примерно 120 км/ч), это могло привести к серьезным авариям. Поэтому городской совет решил выделить полицейского офицера и привлечь две группы добровольцев на работу на перекрестке с Ки-стрит, чтобы предотвратить выход затора на 52-е шоссе.
Три подхода к менеджменту
Будучи человеком дела, полицейский (назовем его Барни) приехал на место действа в понедельник и быстро оценил ситуацию. Он решил, что на пересечении выезда с шоссе и Ки-стрит нужен человек-светофор (регулировщик). Поскольку процесс согласования установки светофора в стране может занять месяцы, полицейский решил регулировать движение вручную. Каждое направление получало свой «зеленый свет» по очереди: сначала те, кто ехали по Ки-стрит на запад (включая левый поворот на рампу в южном направлении), потом — поток с рампы в любом направлении на Ки-стрит. План Барни, однако, сработал не очень. Движение было парализовано в обе стороны на Ки-стрит. К концу часа пик Барни взмок, устал, был несколько разочарован, и ему пришлось выписать несколько предупреждений водителям, позволившим себе недвусмысленно грубые жесты в его адрес.
Во вторник участница одной из волонтерских команд (отзывчивая местная женщина, известная как тетушка Беа) сказала, что она знает, как нужно разрулить ситуацию. Она предположила, что ситуации, когда водителям не нужно пересекать путь следования друг друга, не нуждаются в регулировании. Поэтому она не стала вмешиваться в движение по Ки-стрит, позволив водителям беспрепятственно проезжать и поворачивать направо с рампы и на рампу. Когда кому-то требовалось повернуть налево, Беа тормозила движение по Ки-стрит и позволяла этой машине проехать. Подход тетушки Беа сработал лучше (по крайней мере, никто не показывал ей средний палец), но тем не менее движение по Ки-стрит было более затрудненным, чем можно было бы ожидать, так что в конце часа пик тетушка Беа изрядно намучалась.
В среду появился шериф Энди. Он прихватил с собой шезлонг и бутылочку лимонада. Он устроился на шезлонге в тени в месте, где ему был хорошо виден перекресток и значительная часть рампы, по которой машины двигались с 52-го шоссе на Ки-стрит, и начал потягивать лимонад. Когда хвост пробки на рампе начал приближаться к шоссе, он встал, перекрыл движение по Ки-стрит и дождался, пока все накопившиеся на рампе машины проедут. После этого он вернулся к своему лимонаду. Кроме описанного, Энди больше не делал ровным счетом ничего. Несмотря на его очевидное бездействие, перекресток, похоже, работал как надо. Люди спокойно реагировали на ситуацию, водители, поворачивающие направо, создавали разрывы для тех, которые поворачивают налево. В целом всё работало примерно так, как и до появления тех, кто начал пытаться помочь — просто немного лучше.
Надев наши «шапочки консультантов», мы осознали, что стали свидетелями трех совершенно разных стилей менеджмента: микроменеджмента в стиле Барни, родительского подхода тетушки Беа и мастерского менеджмента от Энди. Поскольку эти три стиля часто встречаются и в софтверных проектах, мы решили рассмотреть их более детально, чтобы понять, какие из уроков мы можем применить у себя в софтверном мире.
Вопрос стиля
Каждый из наших менеджеров делает различные предположения, определяющие их стиль управления: в частности, предположения о людях, которыми он собирается управлять, и о роли менеджера. Эти предположения определяют то, как менеджеры подходят к критически важным активностям в управлении. Джерри Вайнберг в своей книге «Качественное управление разработкой ПО: системное мышление» описал пять критических активностей:
- Понимание проблемы, которую нужно решить.
- Планирование способа решения этой проблемы.
- Сбор информации о том, чем на самом деле заняты люди, которыми предполагается управлять.
- Использование правил и моделей процессов для определения следующего шага.
- Предпринятие действий, чтобы направить группу в нужном направлении.
Эти активности в сумме формируют систему обратной связи, которая «рулит» проектной командой. То, как эти активности исполняются — то есть, как менеджер определяет проблему, какие собирает наблюдения, каким правилам это подчиняется и какие корректирующие действия предпринимаются, — и определяет суть происходящего: куда бежит команда, как команда будет воспринимать проект в целом и, в конечном итоге, насколько будут удовлетворительными результаты.
Микроменеджмент
Барни практиковал стиль микроменеджмента, который базируется на предположении, что менеджер должен контролировать всё, что делают остальные члены команды. Большинство микроменеджеров не отходят от контроля самостоятельно, они действуют исходя из предположения, что если перестать контролировать процесс, то ничего не будет сделано. У микроменеджеров также часто встречается тенденция предполагать, что те люди, которыми они управляют, будут делать только то, что им явно было сказано, — не больше и не меньше.
Эти предположения описывает роботов лучше, чем людей. Логично, что, когда Барни сказал, что нам нужен «человек-светофор», он описывал ситуацию, в которой и менеджер, и те, кем он управляет, были скорее механизмами, чем людьми. Возможно поэтому так много хороших разработчиков становятся микроменеджерами, когда они получают свое первое повышение: они просто «программируют биороботов», которые работают на них!
Используя модель Вайнберга, мы можем увидеть, как предположения Барни определили его взгляд на критические менеджерские активности:
- Проблема, которая должна быть решена, — персонально убедиться в том, что всё работает по порядку.
- План, которому следовал Барни, практически соответствовал тому, что он делает всё сам. Он персонально определял движение каждого конкретного автомобиля. Это, помимо всего, означает, что его план должен был быть достаточно простым, чтобы он мог контролировать его исполнение всё время.
- Даже с простым планом Барни был перегружен настолько, что не мог видеть более широкую картину. Стоя посередине перекрестка, он находился не в той позиции, которая бы позволяла видеть, что там происходит с пробкой на рампе.
- Даже если бы у него получилось собрать лучшие наблюдения, менеджероцентрическая модель процессов не позволила бы ему сделать что-то большее. Основополагающее предположение, что он лично отвечает за каждую машину, пересекающую перекресток, означает, что ему особо нечего делегировать: он не может полагаться на водителей в большей мере, кроме как то, что они будут делать, что им сказано сделать.
- Действия Барни были сильно ограничены. Поскольку он был вынужден контролировать буквально каждую машину, он не мог покинуть свое место в центре перекрестка. В конце концов, он просто не мог делать сильно больше, чем он уже делал: махать руками водителям еще более энергично, надеясь, что они проедут быстрее.
Поскольку менеджер должен сделать (или как минимум одобрить) все решения, в единицу времени может происходить только одно действие, тогда как всё остальное остается ждать в очереди. Когда упрощение, централизация информации и наблюдение превращаются из удобств в недостатки, это создает препятствие, которое непосредственно влияет на планирование и исполнение проектов.
Ред.: Сериализация — последовательное выполнение
Упрощение. Поскольку весь проект целиком должен находиться под контролем менеджера постоянно, план должен быть достаточно простым для того, чтобы одна персона могла полностью погружаться в него до деталей. Это задает верхнюю границу сложности проектов: если проблема, которую нужно решить, находится выше этой границы, менеджеру приходится как-то упростить её (например, пускать движение по дороге только в одну сторону). Сериализация действий в целом является общим случаем упрощений в микроменеджерских проектах, при том что это приводит к бессмысленным тратам усилий и времени. Когда сериализации недостаточно, менеджер может начать выкидывать какие-то «неважные» части из проектного плана. Микроменеджеры печально знамениты своей склонностью к переупрощению до той степени, что из софтверного проекта исключаются обязательные для успешного запуска компоненты.
Централизация информации. Поскольку менеджер — единственное лицо, которое может принимать решения, то становится критически важным, чтобы он получал достаточное количество качественной информации о ходе проекта. К сожалению, разрешаются только те наблюдения, которые менеджер сам заложил в проектный план. Но этот же менеджер всегда слишком занят, принимая каждое решение. Слишком занят для того, чтобы вообще хотя бы за чем-то наблюдать. Таким образом, на практике микроменеджеры обычно бегут вслепую, принимая решения на основании небольшого количества актуальной информации или вовсе без неё.
Наблюдение. Необходимость в получении четкого утверждения для каждого действия заметно увеличивает количество времени, необходимого для того, чтобы завершить задачу. Таким образом, микроменеджмент стремится к неэффективности, когда куча людей ждет менеджера, чтобы он сказал им, что делать дальше. Менеджер как «бутылочное горлышко» — это ключевая структурная проблема. Эта практика приводит еще и к проблемам с людьми — таким, как подавление инициативы. Предположение менеджера включает в себя постулат, что управляемые люди не могут ничего сделать за пределами функций, которые им определил менеджер. А что, если рабочие хотят сделать что-то еще, кроме как следовать правилам, — потому что они знают лучший способ решить задачу или видят проблему в плане? Микроменеджер не позволит этому случиться. Это вызывает краткосрочно неприятные эмоциональные всплески, а долгосрочно — долгие бессмысленные дни на работе для сотрудников такого менеджера.
Большинство людей не любят такой стиль менеджмента. Кто-то будет реагировать на это тупым механическим подчинением, безвольно ожидая следующую пачку указаний от менеджера. Остальные могут выбрать для себя какую-то из форм скрытого сопротивления, таких как «работа строго по правилам» — буквально следовать инструкциям менеджера, не делая ни одного отступления, даже когда эти инструкции ведут к провалу. Другие могут сопротивляться более открыто, пользуясь вечной перегруженностью и расфокусированностью менеджера, чтобы получить то, что они хотят. Понятно, что такие типы поведения только создают положительную обратную связь, укрепляющую убежденность микроменеджера в том, что нужно еще более строго микроменеджерить. Отсюда микроменеджеры обычно отчаянно перегружены.
В итоге является ли микроменеджмент в целом приемлемой практикой? Определенно, если проблема, требующая решения, достаточно мала для того, чтобы один менеджер целиком контролировал весь проектный план и проектная команда согласна строго следовать каждой команде микроменеджера. Несмотря на то, что такое регулярно возникает, это не самая частая ситуация в софтверном мире.
Обычная причина микроменеджмента — это недавно повышенный, технически грамотный менеджер, стремящийся помочь запутавшемуся сотруднику или спасти какую-то часть софтверного проекта. Это создает взаимозависимую динамику, когда менеджер становится спасителем, а сотрудники — беспомощными. Фактически создается следующая подобная ситуация: когда снова что-то пойдет не так, менеджер немедленно ворвется помогать и так далее, пока не случится что-то, что сломает этот паттерн.
Несмотря на то, что микроменеджерские проекты могут приводить (и часто это делают) к успешным продуктовым запускам, это часто случается вопреки, а не благодаря. Точно есть более эффективный и менее разрушительный путь управления ситуацией.
«Матушкин менеджмент»
Тетушка Беа выбрала более добрый, мягкий стиль, который мы называем «матушкиным менеджментом». Тетушка позволяет водителям самостоятельно принимать какую-то часть решений, вмешиваясь только тогда, когда думает, что требуется её помощь. Однако её основное убеждение всё еще довольно близко к убеждению Барни: «Люди, которыми я управляю, способны делать некоторые простые вещи без прямого указания, но серьезные, значительные решения, особенно когда речь идет о противостоянии и конфликте, — всё еще находятся под моим строгим контролем».
Если микроменеджер видит менеджмент людей скорее как управление машинами, то матушка-менеджер видит людей скорее как детей, способных делать какие-то простые вещи самостоятельно, но нуждающихся в защите от всего потенциально опасного. Так же как и микроменеджер, матушка-менеджер необязательно зловреден или невероятно жаждет контроля. Тетушка Беа не особо нуждалась во власти над другими водителями, она просто знала, что они не могут принимать важные решения без её помощи. Она просто и представить себе не могла ситуацию, что кто-то будет поворачивать налево в разрыв, создавшийся из-за того, что едущий в обратном направлении водитель повернул направо. Потому что в этой ситуации нет контролирующей стороны, которая определяет, кому поворачивать, а оба водителя точно не могут самостоятельно эту очередность определить.
Матушкины предположения тетушки Беа определили её взгляд на ключевые менеджерские активности:
- Проблема, которую надо решить, звучит как что-то вроде «позаботиться о людях, которым надо пересечь трафик, направляющийся в другую сторону». Как и в случае Барни, она описывает проблему в персональных терминах. Это её проблема, не проблема водителей.
- Поскольку тетушка Беа видит водителей как человеческих созданий, которые могут делать простые вещи без посторонней помощи, её план был менее жестким, чем план Барни. Она как минимум смогла позволить нескольким событиям происходить одновременно, но под исключительным условием, что в случае чего она берет ситуацию под собственный контроль, что эквивалентно последовательному исполнению.
- Более распределенный план тетушки Беа требовал чуть более детализированных наблюдений, чем у Барни. Ей необходимо было видеть и выделять ситуации, когда явно требовалась её помощь — в частности, левые повороты. Обратите внимание, что она не наблюдала факт, нужна ли была её помощь людям при левых поворотах, а её основополагающим предположением было то, что включение левого поворотника означал запрос на помощь. Так же как Барни, она провела всё свое время, стоя посреди перекрестка, точки, с которой не было видно реальное положение вещей на рампе.
- Из-за матушкиного базового предположения, что управляемые люди не могут самостоятельно справиться с любой формой противостояния или конфликта, процессная модель тетушки Беа диктовала то, что она должна персонально разруливать такие ситуации. Поэтому её реакция на любую ситуацию, хотя бы чуть-чуть выходящую за рамки ординарной, была максимальной — остановить трафик и управлять вручную.
- Как и Барни, тетушка Беа работала исходя из весьма ограниченного списка возможных действий, в частности ограниченного тем, что ей необходимо было находиться посреди потока. Если её действия не приносили результата, то всё, что она дополнительно могла предпринять — только интенсивнее делать то, что она уже делала.
Как и в случае с микроменеджментом, матушкин менеджмент может работать, когда базовое убеждение правильное и решение задачи относительно простое. Проблема в том, что большинство фирм — разработчиков ПО несколько отличаются от детских садиков и большая часть разработки — не рутинный процесс, требующий разрешения большого количества конфликтов. Интерфейсы, разделение проекта, декомпозиция задач, протоколы — это всё «левые повороты» с точки зрения матушки-менеджера, который в этом случае должен персонально убедиться, что все работают хорошо совместно. Это создает структурную проблему, похожую на микроменеджмент. Похожую, но другую. Поскольку какая-то часть работы делается сотрудниками самостоятельно, менеджер в меньшей степени представляет из себя узкое место по сравнению с ситуацией микроменеджмента.
Тем не менее, поскольку процесс еще во многом менеджероцентричен, фактический объем работы, который может делаться параллельно, часто меньше ожидаемого. Мы заканчиваем историю на процессе, который почти эффективен: практически параллельное исполнение, относительно контролируется и страшно близок к автономии сотрудников.
Параллельное (почти) исполнение. Только заранее определенные рутинные вещи могут исполняться параллельно. Пока движение машин по дороге идет строго прямо или направо, план тетушки Беа выглядит как вполне рабочий. Но она не может предсказать, сколько именно машин хочет повернуть налево. Когда множество людей начинают поворачивать налево, её план разваливается. Точно таким же образом фактическая производительность софтверного проекта под матушкиным менеджментом определяется из того, насколько много частей проекта являются «рутинным процессом», не требующим прерывания или разрешения конфликта. Если требуется много прерываний, гораздо больше, чем предполагалось, то большая часть разработчиков, работающих над параллельными задачами, остаются без дела, в ожидании решения менеджера. Это может превратить план с изначально параллельным исполнением в последовательное исполнение на практике.
Близорукость. Матушки-менеджеры делают больше наблюдений, чем микроменеджеры, но они всё равно ограничивают свои наблюдения специфическими пунктами плана. Если эти пункты плана не совпадают фактически с исключениями, которые требуют вовлечения менеджера, матушка-менеджер будет тратить время и усилия на неправильное или бесполезное, одновременно упуская наблюдения, которые действительно важны для успеха проекта.
Нянечка. Матушка-менеджеры действуют менее подавляющим образом, чем микроменеджеры, поскольку матушка всегда позволяет своим «деточкам» делать несколько вещей самостоятельно. Индивидуальные разработчики могут работать самостоятельно до момента, пока их работа вписывается в общий поток и не вызывает конфликтов. Но в первый момент проявления чего-то нестандартного весь процесс тормозится до момента принятия решения менеджером. Менеджер должен заниматься всеми решениями, которые действительно важны, — и это размывает индивидуальный вклад в решение проблемы в целом примерно так же эффективно, как микроменеджмент. Тут возможны широкие вариации: менеджер, который видит своих сотрудников как подростков, контролирует их меньше, чем тот, который видит своих сотрудников скорее как детсадовцев. Тем не менее большинство людей, которые работают в разработке софта, имеют высшее образование, и становится прямо любопытно, действительно ли мы правильно используем результаты их дорогостоящего образования, менеджеря их как детей?
Если мы стремимся найти стиль управления, который более применим и эффективен, чем микроменеджмент и матушка, мы должны начать с изменения наших базовых предположений. Барни видит людей как машины, которые надо программировать. Беа относится к сотрудникам как к детям, которым надо помочь. Теперь давайте посмотрим, что происходит, когда Энди относится к ним как к самостоятельным взрослым личностям.
Мастерский менеджмент
Энди взял путь, который поначалу вообще не выглядит как менеджмент. Он просто уселся в свой шезлонг, потягивал лимонад и наблюдал за пробкой на рампе на съезде с 52-го шоссе. Когда пробка стала слишком большой, он прогулялся до перекрестка, перекрыл движение по Ки-стрит и разгрузил рампу. После этого он вернулся к своему лимонаду. Мы описываем стиль Энди как мастерский — потому что из всех трех менеджеров он был единственный, кто действительно управлял ситуацией.
Ключ к стилю управления Энди заключался в его главном убеждении: водители — взрослые люди, которые в большинстве ситуаций способны о себе позаботиться, а его роль как менеджера — поддержать этих компетентных взрослых так, чтобы они могли самостоятельно проехать перекресток. Это коренным образом отличается от убеждений Барни или Беа. Энди был достаточно уверен в своих компетенциях и в умениях водителей, чтобы убрать себя из центра работы.
Поскольку Энди не поставил себя в центр водоворота событий, он получил приличный запас гибкости и эффективности в своих ключевых менеджерских активностях:
- Энди видел решенную задачу как безопасное и эффективное движение трафика через перекресток. Также он осознавал, что большую часть времени движение машин через перекресток не требовало никакого вмешательства: люди поворачивали там каждый день без каких-либо проблем. Какая здесь возникала уникальная проблема, которая могла требовать вмешательства? Объезд, который увеличил трафик на рампу съезда с 52-го шоссе, что иногда может приводить к образованию длинной пробки на рампе, а пробка, в свою очередь, может приводить к дорожному инциденту. Обратите внимание на отличие: тогда как Барни и Беа определили задачу в терминах «что мы лично должны делать», Энди определил задачу в контексте результата, который должен быть достигнут вне зависимости от того, кто именно делает работу. Сделав это, Энди расположился так, чтобы удобно обозревать и подруливать системой, которая работает, — вместо того, чтобы стать одним из работающих винтиков в этой системе.
- С его пониманием задачи, которая должна быть решена, Энди смог собрать эффективный план решения. Водители должны быть ответственны за проезд перекрестка. Он и его команда менеджмента должны мониторить состояние пробки на рампе и обеспечить ей своевременную «зачистку», когда (и если) она начинала создавать угрозу безопасности. Несмотря на то что Барни мог бы, наверное, обвинить Энди в отсутствии вообще какого-либо плана, факт в том, что максимально простой план Энди позволил работать достаточно сложным процессам. Поскольку Энди не пытался контролировать низкоуровневые действия водителей, его план предполагал делегирование этого непосредственно водителям. Это позволило водителям работать параллельно, что они и сделали: водители, ожидающие левого поворота с рампы, использовали пробелы, возникающие из-за поворачивающих направо.
- Теперь, имея определение задачи и план, Энди смог понять, какие наблюдения ему нужны. Для того чтобы поддерживать пробку подальше от 52-го шоссе, он должен был наблюдать за рампой — не перекрестком. Поэтому он расположился в стороне, там где мог видеть рампу. Это еще одно критическое отличие стиля Энди. Стоя в центре перекрестка, Барни и тетушка Беа получали огромный объем информации, большинство из которой было нерелевантно решаемой задаче. Они не были в правильном месте, чтобы видеть на самом деле важное. Конечно, Энди не игнорировал происходящее на перекрестке, но и не делал на этом главный фокус.
- Стиль Энди использовал две процессные модели. Первая: если пробка собирается на рампе — надо остановить Ки-стрит и разгрузить рампу. Второе: если что-то блокирует перекресток, это надо убрать немедленно. Всё остальное время процессная модель Энди говорила «давайте дадим водителям самим проехать».
- В итоге Энди предпринял менее заметное вмешательство, чем Барни или тетушка Беа. Большую часть времени всё выглядело так, будто он вообще ничего не делает. Тем не менее, когда требовалось вмешательство, он знал, какое действие и в каком объеме было необходимо. Было бы неправильным сказать, что действия Энди были проще, чем действия Барни или Беа. По факту его редкие вмешательства требовали больше умений. В конце концов, Барни и тетушка Беа уже пробовали стоять в центре перекрестка, получая полное внимание всех водителей. Энди тоже приходилось приходить на перекресток, добиваться внимания водителей, временно перехватывать их самоуправление, добиваться исполнения водителями их инструкций и, в конце концов, восстанавливать самоуправление. Это задача, требующая определенных умений.
Как и два стиля, которые мы обсудили ранее, мастерский менеджмент работает тогда, когда базовые утверждения справедливы. В разработке софта, когда управляемые люди опытны, компетентны и зрелы, эти базовые утверждения чаще всего правильны. В этом случае мастерский менеджмент решает структурные и поведенческие проблемы, которые мы видели в случае микроменеджмента и матушкиного менеджмента.
Делегирование, являющееся составной частью плана, означает, что большинство конфликтов и разногласий разруливается без перехватывания менеджера, то есть большую часть времени люди не ждут внимания менеджера. Когда проблема действительно требует менеджерского вмешательства, то ей не приходится вставать в очередь и ждать разрешения более минорных конфликтов.
Поддержка параллельной работы означает, что мастерский подход может работать в проектах, которые слишком сложны для того, чтобы быть понятыми во всех деталях одним менеджером, — и большинство софтверных проектов попадают именно в эту категорию.
Поскольку управляемые люди тоже получают кусок самоуправляемой работы, они становятся способными поставлять полезные наблюдения, которые микро- или матушка-менеджер почти наверняка упустил бы.
Мастерский подход предполагает управление скорее проектом, чем людьми. Большую часть времени люди, задействованные в проекте, свободны в выборе своих собственных методов в рамках определенных базовых границ (например, ехать по правильной части дороги или применять корпоративные стандарты в инструментарии). Это позволяет направить креативную энергию на создание прибыльных продуктов, а не на поиск очередного способа переиграть систему.
Короче говоря, мастер-менеджер, как Энди, наблюдает и управляет системой. Если проблема хорошо осознана, план адекватен и адекватны люди, которые делают работу, то менеджеру мало что в реальности нужно делать. В отличие от микро- и матушкиного менеджмента, мастера тратят большую часть своего времени на наблюдения и скорее редкую, чем гиперактивную деятельность. Но не будьте одурачены: когда Энди сидел в кресле со своим лимонадом, он гораздо эффективнее контролировал ситуацию, чем Барни или тетушка Беа.
Если мастерский менеджмент так хорош, то почему мы не так часто его встречаем? Потому что в некотором роде это тревожно, в том числе для менеджера:
Вид может быть обманчив. Мастерски управляемые проекты иногда определенно выглядят как хаос. Когда Энди управлял перекрестком, трафик проходил во все стороны одновременно, хаотично по сравнению с аккуратным и упорядоченным поведением под управлением Барни. Однако под управлением Энди через перекресток при этом проезжало больше машин, и они это делали безопасно, несмотря на хаотичный, на первый взгляд, вид процесса. Многие софтверные проекты уже выглядят именно так, как этот хаос. Приведет ли мастерский менеджмент к тому, что они станут еще более хаотичными? Мы сомневаемся: подозреваем, что хаос в разработке происходит из-за сопротивления микро- и матушкиному менеджменту.
Сила — во власти. Мастерский проект требует определенного, отличающегося образа мышления. Большинство людей ассоциируют слово «менеджер» со словом «власть». Однако движение от микроменеджмента в сторону мастерского менеджмента предполагает отдачу большого куска менеджерской власти и силы людям, которыми предполагается управлять. Мастер-менеджер однако обладает большей реальной властью, согласно Бэрри Ошри (цитирован в книге Вайнберга «Становясь техническим лидером»), если мы определим власть как способность «действовать способом, который увеличивает способность наших систем к росту и развитию в их среде».
Измерять то, что значимо. В некоторых организациях (особенно тех, где микроменеджмент является корневой практикой) мастер-менеджер вряд ли получит повышение. В конце концов, он не будет делать много «видимого» менеджмента по сравнению с микро- и матушками-менеджерами вокруг себя. Для микроменеджера, который принимает решение о повышении, будет легко прийти к выводу, что проект был успешен «несмотря на бездействие мастер-менеджера», а не благодаря ему.
Но мастерский менеджмент также предполагает и вознаграждение. Мастерам часто не надо так фанатично впахивать, как микро- и матушкам-менеджерам. Как мастеров, их реже можно обнаружить в офисе в три утра в попытке разрешить какую-то очередную тривиальную задачу. И они получают огромное удовольствие от осознания, что они на самом деле эффективные лидеры, когда проектная команда говорит «мы сделали это сами».
Микро-, матушкин или мастерский менеджмент
Лучший способ определить свой стиль менеджмента — задавать вопросы и наблюдать за тем, что происходит.
Когда вы появляетесь в офисе, разбегаются ли подотчетные люди, как листья на ветру? Кажется ли вам, что они выполняют работу, потому что так предписано, или в том числе они руководствуются духом и личной мотивацией? Врываетесь ли вы в проект и начинаете ли писать код, когда случается какая-то проблема? Если да, то, скорее всего, вы микроменеджер.
Организовали ли вы рабочий процесс с настолько минимальным количеством взаимодействий, что работа в команде идет совсем гладко? Включаетесь ли вы в вопросы, чтобы убедиться, что у всех всё хорошо? В сложных ситуациях прибегаете ли к микроменеджменту? Возможно, сердцем вы ощущаете, что всё делаете правильно, но по факту вы матушка-менеджер.
Тратите ли вы достаточно времени на наблюдение за тем, что происходит, думая о воздействии будущих событий на команду и проект и планируя, что с этим делать? Если да, то, возможно, вы мастер-менеджер.
Если вы хотели бы поменять свой стиль управления, есть несколько важных вопросов для обдумывания. Первое: как вы пришли к своему текущему варианту менеджмента? Для большинства из нас на способ, которым мы управляем проектами, повлияли люди, которые управляли нами, и обстановка, в которой управляем мы. Осознание этих влияний и ограничений текущей рабочей ситуации может помочь определиться с тем, подходящее ли сейчас время для внедрения новой модели. Важно еще обдумать, насколько вам самим комфортно с текущим стилем. Если достаточно комфортно в текущем статус-кво, возможно, и не нужны никакие изменения. Но если вы ощущаете перегрузку или переработку и постоянно занимаетесь тушением пожаров, то, возможно, настало время перемен.
И последнее: что бы вы хотели, чтобы случилось? Мы видели, как понимание задачи у Барни, Беа и Энди сформировало их уникальную реакцию, и точно так же это работает и с вами. В момент, когда вы осознаете, чего хотите, вы сможете придумать и исполнить планы, которые помогут достичь своих целей и поддерживать беспроблемное движение трафика по магистрали.
