Задача поставлена, исполнитель кивнул. Проходит три дня – дело не сдвинулось с мертвой точки, потому что каждый шаг приходится согласовывать с тем самым руководителем, который поставил задачу. Иллюзия делегирования – тихая и разрушительная управленческая привычка. Руководитель искренне считает, что передал задачу. Исполнитель искренне считает, что ему не дали права ничего решать. В результате оба перегружены, сроки горят, а на ретроспективе звучит одно и то же: «Ну, я же сказал, делайте». Сказал – не значит дал.
Когда возникает иллюзия делегирования
Механизм выглядит так. Руководитель формулирует задачу – обычно достаточно абстрактно: «подготовь предложение», «разберись с клиентом», «запусти процесс». Исполнитель начинает двигаться и упирается в решение, которое выходит за рамки его зоны ответственности: бюджет, срок, приоритет – все нужно уточнить. Каждое такое уточнение – микро-визит к руководителю, который в идеале должен быть доступен и отвечать быстро. Но он делегировал задачу именно потому, что у него нет на нее времени. Получается замкнутый круг: руководитель слишком занят, чтобы отвечать на вопросы по задаче, которую он не может полноценно передать.
Исполнитель между тем теряет инициативу. После третьего «ну решай сам», которое звучит как пассивная агрессия, и пятого «ты что, не мог подождать, я на встрече» формируется простой паттерн: легче вообще ничего не делать без прямого указания. Это не безответственность, а рациональная адаптация к среде, в которой инициатива наказуема.
Почему руководители не передают полномочия
Причин несколько, и большинство из них – психологические, а не организационные:
- Привычка контролировать. Руководитель вырос из специалиста, который привык, что все делается по его стандартам. Ему кажется, что если он не проверит каждый шаг, результат будет недостаточно хорош. Проблема в том, что «недостаточно хорошо» – это субъективная оценка, а не объективный критерий. Пока критерии явно не сформулированы, любой другой результат будет вызывать раздражение.
- Страх ошибки. Если исполнитель примет решение и ошибется, отвечать руководителю. Эта логика кажется железной, но на деле парализует. Ошибки случаются у всех, включая руководителей. Разница в том, что ошибка исполнителя стоит дешевле, потому что она локальна и ее можно исправить. Ошибка руководителя, который пытался контролировать все, стоит дороже – потому что она системна и накапливается.
- Иллюзия скорости. «Проще сделать самому, чем объяснять» – классическая ловушка. В краткосрочной перспективе это правда. В среднесрочной – руководитель оказывается единственным узким местом в каждом процессе. А когда таких процессов десяток, он перестает успевать везде. Задачи начинают застревать не на полпути, а на старте.
- Размытые границы. Руководитель сам до конца не понимает, какие решения можно отдать, а какие – нет. Ему кажется, что он делегировал, но на самом деле он делегировал только исполнение, оставив себе все решения. Это как отдать руль, но оставить свою педаль тормоза. Ехать невозможно.
Рассмотрим типовой сценарий. Руководитель отдела поручает менеджеру подготовить коммерческое предложение для нового клиента:
– Сделай хорошее предложение, клиент серьезный, – говорит он.
– Какой бюджет закладывать? – уточняет менеджер.
– Ну, рыночный.
– Какой срок реализации?
– Стандартный.
– Кто будет на презентации?
– Решай сам.
Менеджер уходит думать. Через день возвращается: «Я думаю, надо предложить три пакета – базовый, расширенный и премиум». Руководитель морщится: «Ну зачем три, давай один нормальный». Еще через день: «А скидку можно дать?» – «Смотря какую». «А если клиент попросит индивидуальные условия?» – «Ну, тогда ко мне».
В итоге менеджер фактически не сделал ничего, кроме черновика, который руководитель переписал сам. Формально задача делегирована. Фактически – руководитель потратил больше времени на микроменеджмент, чем потратил бы на прямое выполнение. Менеджер демотивирован: его решения отменяют, его инициативу пресекают. В следующий раз он просто спросит еще три раза и будет ждать прямых указаний.
Другой сценарий – более тихий, но не менее вредный. Руководитель пишет в мессенджере: «Разберись с той ситуацией». Исполнитель разбирается – в меру своего понимания. Через неделю выясняется, что он разобрался не так. Руководитель расстроен: «Я же сказал – разберись!». Исполнитель в недоумении: «Я разобрался. Ты имел в виду что-то другое?». Проблема не в исполнителе. Проблема в том, что «разберись» – это не постановка задачи. Это пожелание, обернутое в форму поручения.
Из чего состоит делегирование
Если не хватает хотя бы одного из этих четырех элементов, задача не будет делегирована:
- Цель и критерии результата. Не «подготовь предложение», а «подготовь предложение с маржинальностью не ниже 35%, срок реализации – до 6 недель, формат – три сценария с разной ценой». Критерии должны быть проверяемыми. Если результат нельзя проверить без погружения в процесс – критерии сформулированы плохо.
- Границы решений. Четко обозначьте, какие решения исполнитель принимает сам, а какие выносит на согласование. Например: «Бюджет до 200 тыс. – решаешь сам. Выше – ко мне. Срок до 4 недель – твой. Дольше – обсуждаем. Скидка до 10% – твоя. Выше – только после моего ОК». Это не бюрократия. Это карта, по которой исполнитель может двигаться, не останавливаясь на каждом перекрестке.
- Ресурсы и доступы. К кому обращаться за данными? Кто смежники? Какие инструменты доступны? Какой бюджет можно тратить? Бывает, исполнитель формально получил задачу, но не получил доступ к CRM, не знает, кто на стороне производства отвечает за сроки, и не имеет права запросить аналитику у смежного отдела. Задача в таком состоянии – это головоломка.
- Точки контроля. Установить чекпоинты: «В среду покажи черновик структуры. В пятницу – финальный вариант на вычитку». Исполнитель знает, когда его ждут с результатом. Руководитель знает, когда смотреть. Между чекпоинтами – полная свобода действий.
Чек-лист: как правильно делегировать задачу
Перед тем как передать задачу, прогоните ее по этим пунктам. Если хотя бы на один ответ «нет» – задача не готова к делегированию:
- Могу ли я сформулировать, что именно считаю успешным результатом? Не процесс, а конкретный выход.
- Я знаю, какие решения исполнитель будет принимать самостоятельно, а какие – со мной?
- Есть ли у исполнителя доступы, ресурсы и информация, необходимые для выполнения?
- Понимает ли исполнитель, в каких случаях он может действовать без согласования?
- Определены ли точки контроля без промежуточных проверок?
- Готов ли я принять результат, который отличается от моего идеального, но укладывается в критерии?
- Я смогу не вмешиваться между чекпоинтами, даже если кажется, что «я бы сделал иначе»?
Если на последний вопрос вы честно отвечаете «нет», проблема не в делегировании, а в нежелании отпустить контроль. Никакие методики тут не помогут, пока вы это не признаете.
Как выйти из цикла микроменеджмента
- Признать масштаб проблемы. Посчитайте, сколько раз за неделю сотрудники приходят к вам с вопросами по задачам, которые вы делегировали. Если больше трех-четырех – делегирование не работает. Не потому что исполнители некомпетентны, а потому что им не передали достаточно контекста и полномочий.
- Провести аудит своих задач. Выпишите все, что вы контролируете лично. Разделите на три категории: то, что действительно требует вашего участия (стратегия, ключевые переговоры, кадровые решения); то, что можно контролировать реже (достаточно еженедельного чекпоинта вместо ежедневного); то, что вы вообще не должны контролировать (операционные задачи, которые давно пора отдать).
- Начать с малого. Выберите одну задачу, которую вы микроменеджерите по привычке. Сформулируйте критерии. Определите границы решений. Назначьте чекпоинт. И отпустите. Не вмешивайтесь между чекпоинтами, даже если хочется.
- Легализовать ошибки. Скажите исполнителю прямо: «Если ты примешь решение в рамках своих границ и ошибешься – мы это разберем и исправим. Это нормально. Хуже, если ты будешь каждый раз бежать ко мне, и задача будет стоять». Когда люди знают, что ошибка внутри границ – не катастрофа, они начинают действовать.
- Обратная связь по результату, а не по процессу. Когда исполнитель приносит результат, обсуждайте результат. Не то, как он к нему шел. Если результат укладывается в критерии – примите его, даже если путь был другим. Если не укладывается – разберите, почему. И скорректируйте либо критерии, либо границы на следующий раз.
Выводы
Делегирование без полномочий – это способ создать видимость движения при реальном простое. Руководитель остается узким местом. Исполнитель теряет мотивацию. Задачи не движутся. Организация буксует.
Выход прост по формуле, но не по исполнению: передавайте вместе с задачей цель, границы, ресурсы и точки контроля. Все остальное – свобода действий. Да, будут ошибки. Да, результат не всегда будет таким, каким вы его представляли. Но он будет, и с каждым разом – лучше.
Потому что делегирование – это навык, как для исполнителя, так и для руководителя. Оба учатся. Оба ошибаются. Но только тот, кто готов отпустить контроль, получает работающую команду. Остальные получают иллюзию и бесконечный список задач, которые «вроде бы» делегированы, но почему-то не выполняются.
Также читайте:
Согласен. И удивительно редко на этом моменте акцентируют внимание.
В общем случае (в рамках нормативного подхода) будут наказаны оба, но состав нарушений будет различаться: если руководителю "прилетит" за тактическую (обычно) или стратегическую (реже) близорукость, то исполнителя "награда найдет" по факту реализации операционного риска - в силу позиции исполнителя проблема обычно лежит в вопросах следования инструкциям.
В своей практике я предпочитаю разделять:
1) вопросы операционного риска, принятие убытков по которым на собственное удержание является просто "ценой ведения бизнеса", и она должна перекладываться в полном объеме на расходы,
2) вопросы стратегического и бизнес-рисков - они связаны с пакетами компетенций менеджмента, соответственно, должны рассматриваться через призму OKR и отложенного бонусирования.
Но при этом "входным билетом" в менеджмент, даже начального уровня, я считаю способность сотрудника понимать более общую картину, умение ставить цели по SMART и знание практик делегирования в рамках RACI.
Это может и не быть нарушением. Как может не быть и инструкций. Но это не меняет общее правило - результат не получен, ответственность несут оба, каждый за своё.
Но работа не сводится к вопросам разделения рисков. Всё это относится к исполнению - так или иначе работа должна быть сделана. Делегирование именно об этом. Иначе просто нет предмета для обсуждения. Возникающие при этом те или иные риски неизбежны, в каждом случае свои.
Было бы прекрасно. Если бы.
Вопрос: это буквально входной билет в менеджмент начального уровня или уже доказанные на практике способности, подтверждённые хорошими результатами? На какой позиции сотрудник уже видит общую картину, (правильно) расставляет приоритеты, цели и задачи, принимает решения о делегировании и пр.? Что это сотрудник обычно делает на рабочем месте?
Способность видеть общую картину звучит интригующе. Если серьёзно, таких людей много не бывает - вне зависимости от занимаемой позиции. Гораздо проще плыть по течению.
Если инструкций нет - это уже вина руководителя: человека взяли под непонятный функционал. Если будет ошибка - комиссия по аудиту будет разбираться с тяжестью последствий и рассматривать возможность ответственности менеджера. С точки зрения методологии это трактуется как классический операционный риск.
Это зависит от точки зрения (viewpoint) в периметре моделирования бизнес-процесса.
С позиций акционеров интересен скорректированный на риск возврат на инвестированный капитал, поскольку его можно сравнивать с альтернативными вложениями. По составу операций (если только речь не идет о чистом НИОКР) многие бизнесы оперируют похожими образами, а вот управление рисками в них разное. Соответственно, и делегирование типовой операции в одном случае будет выполнено эффективно, а в другом - может сорваться из-за процедурных неоптимальностей. Ни состав работ, ни необходимость в делегировании принципиально не изменятся, но вот себестоимость процесса вырастет.
А это, кстати, достаточно легко достигается, как минимум - в консалтинге. Средний выпускник вуза (интерн) приходит в эту точку по итогам квартала работы. Через полгода от него либо избавляются, либо продвигают в консультанты первого года.
И - опять же - он должен видеть более общую картину в рамках своей области, разумеется никто не станет ожидать от такого сотрудника понимания бизнеса в целом - это не у всех партнеров получается. Однако, для правильной организации рядового исполнителя качественный онбординг и конкурентный отбор по итогам работы становятся весьма неплохой точкой входа на менеджерскую позицию. А дальше работает "Принцип Питера".
Допустим, что есть процессы, процедуры, правила, цепочки согласования, утверждения и эскалации. Компания практически идеальна в этом смысле. Но они редко покрывают 100% того, чо приходится делать на рабочем месте. Думать и затем делать пока приходится. Да и о делегировании там всё уже расписано, и проблема отсутствия полномочий, как в статье, просто не возникнет.
Инструкции - это другое. Они редко пишутся на буквально каждое шевеление пальцев. И обычно это не книга кулинарных рецептов с максимально подробным описанием каждого шага. Если деятельность не 100% формализована - такие тоже есть. Но и при их наличии можно ошибиться. тем более, если что-то делегировано человеку с пока недостаточным опытом и практикой. На ошибках учатся, если способности к обучению не утрачены. См. статистику провалов больших проектов.
Каждый вопрос имеет, на мой взгляд, смысл решать на своём уровне. Где акционеры со своими заботами и где исполнители, которым что-то делегировали. Я бы на пару минут отвлёкся от раскопок в части корпоративного управления - оставаясь в рамках ветки.
Думаю, что это частный случай. И он совсем не о делегировании. Консалтинг - особый бизнес. Возьмите большое производство с иерархией, там много менеджеров нескольких уровней. У каждого своя работа, начиная с текучки.
Интересно, кто из них видит общую картину - и какую именно. Вдруг у каждого своя. Такое я встречал, как и неизбежный конфликт интересов.
Принцип Питера, насколько я вижу, работает всегда. Вполне применим и к делегированию, причём к обоим участникам. Лишь бы правильные выводы делались вовремя.
Я не встречал в реальности организацию, в которой бы все процессы шли идеально, еще реже можно говорить о полноте инструкций. Но здесь я бы преимущественно выделил вектор: руководитель, понимающий суть работы исполнителя, будет стремиться создать инструкции даже не для исполнителя - для себя: так он сможет ограничить зону собственного контроля, но дополнительно и даст свой периметр исполнителю.
На практике обычно согласовывается зона ответственности (некая лимитная ведомость), в рамках которой исполнитель может принимать решения. Но именно для создания такой ведомости требуется оговорить те процессы, которые она будет покрывать. Делается это в инструкциях. Более "продвинутые" компании осваивают RACI.
Да. Часто исполнители, особенно - на крупных промышленных производствах, редко задумываются о задачах акционеров. Собственно это и правильно - платят им за выполнение работ на своем участке.
Но если контур этих работ оказывается определен нечетко - возникают различные толкования, которые с неизбежностью сведут производство к хаосу. Часто спасает то, что уже на уровень младшего менеджмента выдвигаются люди (бригадиры, прорабы и проч.), которые видели эти "игры" на ранних этапах своей карьеры, поэтому распознают их безошибочно. Дополнительное общение со средним менеджментом позволяет им видеть несколько дальше, поэтому и доносить управленческие решения получается более четко.
Я привел консалтинг в качесстве примера в силу двух обстоятельств.
Во-первых, мало какая область деятельности отличается той интеллектуальной интенсивностью, какая требуется в консалтинге уровня Big3/4. Это приводит к естественному "выгоранию" персонала в течение 2-4 лет, что ставит "в полный рост" задачу по постоянному пополнению штата без потери его эффективности.
Во-вторых, мало кто задумывается, как именно формируется маржа в консалтинговом бизнесе. В идеале - "закрыть задачи" по цене самого дешевого консультанта, но продать их по рыночной ставке. В норме это должно приводить к рентабельности 40% и выше (против 10-20%% в обычных бизнесах).
Но здесь же автоматически возникает вопрос: как вчерашний выпускник ВУЗа может сказать руководителю, например, завода, где тот проработал последнюю треть века, что конкретно следует менять? И почему вообще его будут слушать? И вот в этот момент "на сцену" выходит технология - процесс "натаскивания" консультантов на то, чтобы они в любом случае оказывались полезны любому бизнесу - даже тому, о котором еще вчера они могли не слышать вовсе.
Кроме того, нужно нивелировать различные персональные особенности так, чтобы они не мешали работе команды, но наоборот - усиливали ее. Сделать это без четких инструкций не получится, делегирование полномочий будет являться неизбежным.
А вот конфликты интересов всеми осознаются, и ими управляют. В простейшем случае - через матрицы полномочий и ответственности, через контрольные сессии раз в квартал/полугодие, через еженедельные сессии на проектных комитетах и, наконец, в рамках текущей работы менеджера проекта и директора практики.
Если вдруг интересны детали - есть маленькая (и неплохая) книжка Итана Расила The McKinsey Way, в которой на первых 30 страницах он описывает основные идеи. Они особо пригодны для консалтинга, но я внедрял их и на крупных производствах (нефтегаз, химия, логистика) - в целом получалось похожим образом.
Люди всегда хотят иметь определенность, и наличие четких инструкций, понимание предела ответственности и возможность обратной связи от менеджера сильно упрощают любой бизнес.
Да. Исключений из Принципа я не видел также.
И не Вы один.
Пока не понимаю, как такая схема работает, но можно начать с другого - в зависимости от качества и содержания определенных документов.
Возьмём две должностные инструкции и оргсхему. Покажём, что из первой делегируется во вторую полностью млм частично. Пометим, что с точки зрения полномочий и персоналий нужно подтвердить в организации. Добавим все актуальные рабочие материалы и планы на обсуждаемые темы.
Существующие на данный момент процессы, процедуры и пр. не меняются. Надеемся, что они документированы и не требуют постоянного личного вмешательства и знания предыстории. Вполне возможно, что с ними придётся дополнительно (или в первый раз) ознакомиться и задать владельцам процессов какие-либо вопросы.
Знаю по себе. Об этом знает любой, кто видел и оплачивал соответствующие счета, смотрел, хотя бы некоторое время, на список исполнителей и сравнивал его с реальностью.
Его и не будут. Только из вежливости. Но обычно в переговорах и продажах участвует несколько человек, включая крупнокалиберных и матёрых. Кто потом делает работу - отдельный вопрос, важнее имена тех, кто на обложках документов и хорошо знает правила игры
Есть - и совсем неплохая. Нужно будет посмотреть, что там о делегировании.
.
Самый "чистый" пример, видимо, можно привести из сферы финансов: трейдинговые подразделения в явном виде имеют установленные лимиты на размер открытых позиций: совокупно, по сегментам рынка, по инструментам, по валютам и проч., но в рамках этих лимитов трейдер имеет свободу делать все, что хочет. За ним в параллели наблюдают аудиторы и рисковики: системные ограничения трейдинговых терминалов не позволяют "ошибаться" в рамках первой линии контроля, а послед. контроль по итогам дня выявляет моменты, где этого трейдеру хотелось.
Это мне очень напомнило систему KRAFT в группе DnB: текстовые блоки инструкций фактически сопровождали диаграммы процессов (похожие на BPMN), и тут же были контакты ответственных в рамках оргструктуры, которые имели полномочия именно в конкретном куске инструкции.
После продажи начинается рядовая работа, куда привлекать уровень партнеров не будет экономически рентабельно. В итоге приходится обходиться компетенциями консультантов, но они - проделав большую работу по установлению фактологии - оперируют выявленными фактами, поэтому приходится их слушать: спорить с мнением консультанта легко, спорить с фактами, приведенными в поддержку конкретной выдвинутой гипотезы сильно сложнее.
Глава 13 завершается примером такого:
Это совсем не о делегировании. Обычная работа с лимитированной доверенностью + круглосуточная многоуровневая система контроля. Но скандалов пока хватает.
Ничего об этом не знал, но выглядит разумно. Думаю, что что-то подобное есть в каждой большой компании со сложной структурой и не самыми простыми процессами.
Не уверен, что действительно нужно копировать диаграммы процессов - можно просто сослаться на текущую версию документа с описанием. Они же меняются.
Обычно так чаще и бывает по всем понятным причинам.
Понял. Пока это не о делегировании. Классический Task Management с планами и распределением обязанностей. Не заметил изменений в обязанностях упомянутого в примере Лотара. Придётся перечитать.
Нет, не совсем так. По итогам годового планирования акционерам доводятся предложения по фиксации KPI/OKR по ряду направлений бизнеса, в т.ч. и по казначейским операциям. За их достижение ответственность несет глава казначейства, который сам в дальнейшем распределяет управленческие лимиты как предложения для Комитета по рискам.
Если участники Комитета согласятся с пофамильными списками целей и лимитов для трейдеров (исходя из их прошлого опыта, индивидуальных особенностей, планов на год) - они попадут в лимитную ведомость. То есть глава казначейства делегирует свои возможности по заработыванию плановых показателей на нанятых им сотрудников. В случае неуспеха отвечать будут и он, и сотрудники. Это в точности соответствует определению делегирования полномочий.
На самом деле - это сильно удобнее текста: каждый блок процессной схемы содержит именно тот абзац, который его описывает. Соответственно, актуализация документов сводится просто к "сборке" блоков в единый файл. При этом изменения в самом блоке и связанных документах производятся локально.
Такая схема позволяет держать актуальными очень большие массивы связанных документов, при это обеспечивая их согласованность между собой, а также контроль зон ответственности исполнителей. Модель работала более 20 лет назад - даже на том уровне развития IT, правда DnB NOR Bank ASA был крупнейшим банком Скандинавии (больше консодидированного Сбербанка), поэтому он мог позволить себе нанимать методологов мирового класса.
Не уверен. Делегирование (!) какой-то функции менеджера сотруднику на нижнем уровне как-либо связано с мнением участников Комитета (!)? Возможно, есть какая-то специфика, которую я не понимаю.
Если контора - условно - рубит лес, то нет смысла говорить, что это делегирование работы лесорубам по решению главы конторы. Их работа именно и ровно в этом состояла и состоит. А выше есть, например, бригадиры. И водители лесовозов. Все заняты.Все работают на план.
Как очевидна и работа трейдеров, если они не роботы. Лимиты - уже детали. И в Вашем абзаце говорится о постоянной работе. Трейдерам как-то сверху определили рамки, включили контроль, они пошли делать деньги. А уровней менеджмента в организации может быть сколько угодно.
Схема понятна, вопрос о версионности внешних документов. Копирование никак технически не обеспечит согласованность документов внутри массива - эта проверка и другая работа по изменениям делается заранее собственниками документов, затем они вступают в силу после соответствующего решения. Но какой-то период рассогласования во время перемен может случиться.
Я бы оставил прямые отсылки на актуальные версии. Иначе инструкции придётся менять чаще, чем хотелось бы. Впрочем, DnB мой совет не понадобится.