Заметка о делегировании

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

Изображение с сайта https://cs8.pikabu.ru/images/big_size_comm/2018-09_5/1537797917175474742.jpg


Давай по новой, Миша, все не так (с)

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

Сначала я хотел сесть и все переделать, но задача была слишком объемной, чтобы вот так просто ее переписать. Тогда я решил попросить коллегу все переделать исправить свой код по моим замечаниям. Я открыл свои же требования, чтобы писать замечания по пунктам: я смотрел в них, и в реализацию, потом снова в требования, потом снова в реализацию. Никаких противоречий между ними не было! Качество реализации было на высоте, то есть весь вопрос был в том, что задача была решена не так, как ее бы решил я.

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

Какие выводы я сделал:

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

Вы что, и есть за меня будете?

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

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

Это неправильные пчелы

Один мой знакомый как-то сказал, что делегировать нужно все, что тебя не развивает. Спорное утверждение, проверять его я, конечно, не буду. Мне ближе позиция Питера Друкера. В "Эффективном руководителе" он описал ее так: 
Традиционный смысл, вкладываемый в понятие "делегирование" прав и полномочий, придает самому процессу неверную окраску. Рациональное распределение нагрузок — это отнюдь не "делегирование", не перекладывание своих функций на других, а частичное высвобождение своего времени для концентрирования сил и внимания на наиболее важных участках работы и предоставление своим коллегам и подчиненным возможности проявить свои способности.
Что-то еще добавить к выводам Друкера сложно. Остановлюсь на таком варианте: 
  • Не спешите делегировать всю свою работу. Исходите из целей организации и вашей эффективности.
На этом время историй закончилось. Еще очень хочется рассказать про другой не менее важный процесс - эскалирование. Но о нем в следующих выпусках. 

Комментарии

Популярные сообщения из этого блога

4 дисциплины исполнения. Реальный опыт

Про мышление и быстрое обучение

Waterfall на прокачку: добавляем Agile