Як менеджеру практично прокачати ефективне делегування

«Ніхто не зробить так, як мені треба!», «Краще зроблю сам, ніж проситиму», «Ой, довше пояснювати, ніж робити», «Тільки я можу закрити це завдання». Такі фрази можна почути, мабуть, від кожного другого менеджера. І не лише початківців, а й тих, хто вперто вірить у свою незамінність і відмовляється прийняти факт, що хтось може зробити на такому ж рівні або навіть краще.

Мене звати Орест Дмитрасевич і останні дев’ять років я займаюсь управлінням та менеджментом в різних ролях: я був скрам-мастером і допомагав робити еджайл-трансформації, керував маленькими та великим проєктами та програмами (від трьох до 85 людей), будував проєктні офіси та розвивав PM-компетенції в ELEKS та Abto Software.

Зараз я — менеджмент-консультант та засновник платформи розвитку лідерів Kaizen Hub, де ми прокачуємо рівень професійності українських PM та допомагаємо українським бізнесам подолати операційний хаос. Одним з наших проєктів є ютуб-канал, де ми обговорюємо всі дотичні до менеджменту та лідерства питання. Буду вдячний за ваші підписки!

Типові помилки менеджера-початківця — закривати собою всі завдання, боятися просити допомогу, хаотичний розподіл обов’язків і, як наслідок, ефективне делегування зазнає фіаско. Я сам таким був і чудово це розумію — саме тому і хочу поділитись з вами своїм досвідом, який допоміг мені почати делегувати.

Чому людям важко делегувати: причини в голові

Делегування — це навичка, яка формується з досвідом і практикою. Якщо ви не народилися з приміткою «За замовчуванням вміє делегувати», то з вами все ок. Малюки вчаться тримати ложку, учні — ручку, перукарі — ножиці. Менеджери повинні навчитися делегувати.

Є кілька причин, чому керівники можуть ухилятися від делегування завдань. У скількох з них ви можете знайти себе чи вашого менеджера?

  1. Вважаєте, що для пояснення завдання знадобиться більше часу, ніж для того, щоб виконати його самостійно.
  2. Хочете відчувати себе незамінними для своєї команди через наявність унікальних конкретних знань.
  3. Насолоджуєтесь виконанням певної роботи, тому не хочете її віддавати нікому.
  4. Відчуваєте провину за додавання додаткової роботи для вашої команди.
  5. Відсутність впевненості чи довіри до того, кому потрібно передати завдання.
  6. Вірите, що ви єдині, хто може правильно виконувати роботу.

Я, мабуть, був у всіх шести ситуаціях з шести — і це теж окей в певних ситуаціях і контексті. Дійсно, якщо це термінове завдання, то немає сенсу витрачати час на пояснення і ще й можливо потім переробляти за кимось. Але без делегування ви не тільки перевантажите свій графік, а ще й заберете класні можливості для навчання та розвитку у членів вашої команди.

У перші роки своєї роботи керівником я, здається, найбільше страждав від другого пункту. Тоді здавалось, що я мушу забирати на себе всі задачі й тільки так доведу свою важливість для команди. Але мені пощастило з менеджером, яка на той момент сказала, що не бачить ніяких проблем, якщо я на роботі дивитимусь серіал за умови, що в моїй команді все працюватиме добре :)

Це змусило мене переосмислити ставлення до ролі менеджера і я зрозумів, що нема нічого страшного в тому, щоб, наприклад, прийти до свого керівництва і сказати, що у вас вже все добре з поточною командою і є вільний час для додаткових завдань — це буде вам лише в плюс! І взагалі, зараз я можу сказати, що одна з основних задач крутого менеджера — це стати непотрібним своїй команді :)

Як почати делегувати

Вам відразу треба прийняти, що ефективне делегування вимагає довготривалої адаптації, і результат не буде помітним відразу. До того ж спочатку часу на організацію процесу йде у два-три рази більше. Це нормально. Ці початкові вкладення дадуть вам змогу бути ефективнішими в довгостроковій перспективі. Менеджер повинен почати з самоустановки, що виконавець готовий до покрокової реалізації завдання.

Проте для успішного делегування треба закрити п’ять факторів:

  1. Чітка й зрозуміла інструкція: ніхто не зобов’язаний читати ваші думки (за винятком, якщо ви менеджер екстрасенсів). Але тут важливо також не переборщити — делегування це здебільшого про те, щоби розповісти про очікуваний результат, ніж про максимально чіткий план дій. Тобто, ви кажете людині, що очікуєте в кінці, а як цього результату досягти — має вирішувати вже людина, якій делегували. Бо інакше це просто постановка завдань, а не делегування.
  2. Прописані етапи виконання завдання з адекватними дедлайнами (терміново «на вчора» — не підходить).
  3. Контроль і фіксація статусів виконання завдань, але без фанатизму, коли перевіряється кожен крок і вимагається звіт раз у годину. Відразу на початку домовтесь про чіткі майлстоуни, коли ви обговорюватимете хід завдання.
  4. Аналіз попередніх результатів: цікавтеся, підказуйте, пропонуйте допомогу з повагою до чужих ідей, ініціативи (проактивні виконавці цінуються).
  5. Баланс між зауваженнями та заохоченням: при робочій субординації не забувайте, що ви делегуєте людям, а не роботам (діалог вітається).

Довіряйте людям, яким делегуєте. Відпустіть внутрішнього перфекціоніста. Аналізуйте сильні сторони виконавців — використовуйте людський ресурс зі здоровим глуздом без стресу та вигорання.

Сім рівнів делегування

Також важливо розуміти, що делегування це не чорно-білий прямолінійний процес — делегувати можна по-різному. В цьому плані мені дуже допоміг інструмент з Management 3.0 — Delegation Poker. Цей підхід визначає сім рівнів делегування і допомагає вам передати відповідальність іншим людям у контрольований і поступовий спосіб.

Отже, які ж рівні делегування можуть бути?

  1. Tell. На цьому рівні ви приймаєте рішення за інших і можете пояснити свою мотивацію. Обговорення цього питання не бажане і не передбачається. Тобто — жодного делегування, це можна назвати й нульовим рівнем 🙂
  2. Sell. Ви все ще приймаєте рішення замість команди, але тут вже намагаєтеся переконати їх у правильності вибору, і цим допомагаєте їм відчути причетність.
  3. Consult. Ви спочатку запитуєте команду і враховуєте їхню думку, але фінальне рішення за вами. Тут вже починає зароджуватись командна робота.
  4. Agree. Ви обговорюєте ситуацію зі всією командою і під кінець цього обговорення досягаєте консенсусу щодо рішення.
  5. Advise. Тут влада починає поступово переходити до команди — ви висловите іншим свою думку і будете сподіватись, що вони прислухаються до ваших мудрих (чи не дуже 🙂) слів, але фінальне рішення буде їхнім, а не вашим.
  6. Inquire. Ви дозволяєте команді прийняти рішення, лише запитуєте в них про обґрунтування після цього.
  7. Delegate. Рівень «Боженька»! Ви повністю залишаєте рішення за командою і навіть не хочете знати про деталі, щоб не засмічувати ваш мозок.

Важливо розуміти, що цю концепцію не слід застосовувати до окремих маленьких задач — набагато краще це працюватиме, якщо ви визначите ключові сфери прийняття рішень і що з цього ви делегуєте.

Для прикладу, я як менеджер проєкту визначив, що вибір проєктної методології буде відбуватись на другому рівні делегування: я приймаю рішення про те, який фреймворк використовувати, і продаю його команді. Як консультант, я частіше працюю на п’ятому рівні — я пропоную рішення організаціям, а вони вже вирішують, чи дослухатись до мене, чи ні.

Більше про рівні делегування і загалом про те, як почати делегувати, ми також обговорювали в цьому епізоді подкасту «Майже Вчасно».

Підсумок

Як підсумок, скажу лише, що іноді найцінніше, що ви можете зробити як менеджер — це делегувати вашу роботу. Делегування не тільки дає вам більше часу, щоб зосередитися на завданнях, які мають більш стратегічне значення, це також дає членам вашої команди можливість брати участь у цікавих проєктах та розвиватись.

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
я приймаю рішення про те, який фреймворк використовувати

Ну і які варіанти?

Для прикладу, я як менеджер проєкту визначив, що вибір проєктної методології буде відбуватись на другому рівні делегування

На сьомому і тільки на сьомому.

Тут здебільшого розробники сидять. Загубилися?
Тобто умовний ПМ пише за мене код, покриває його тестами, пояснює девопсам, що і як задеплоїти, среться з QAшниками і переконує бізнес, що вимоги треба писати на папері, а не розказувати на випадкових мітингах випадковим людям? Золотий ПМ.
Але останнє хай делегує мені. Бо поки жодна менеджерська срака з цим не справилася.

Тільки я можу закрити це завдання

Це було про менеджера чи Ліда
Менеджер зазвичай знає деталі поверхнево.
Тоді наступне питання

Списувати бюрократичні обов’язки менеджера на команду яка і так тоне ?

Підписатись на коментарі