"Делегируй это" - Часть 2
Выбор исполнителя
Окей, мы договорились с собой о том, какой результат считать достаточно хорошим. И за какое время мы сможем его получить. Как выбрать исполнителя?
Рассмотрим возможные отношения "человек - делегируемая задача", которые часто встречаются на практике. Во всех случаях будем предполагать, что человек, как минимум, не оказывает активного сопротивления полученным задачам и базово мотивирован работать.
Мотивация – отдельная большая тема, про неё выйдет другая статья.
a. Человек выполнит задачу легко и абсолютно без рисков. Он такое много раз делал.
Тактически безопасно: если сотрудника не собьёт автобус, он и правда справится. Скорее всего, даже не придётся переделывать.
Дефолтный вариант в одном из трех случаев:
- Планка "достаточно хорошего" результата находится близко к уровню "безупречно". Например: ты реализуешь критичную логику в биллинге своего сервиса, ошибка приведёт к многомиллионным потерям в секунду
- Времени на задачу мало. Например, релизить нужно "завтра" (или даже "вчера")
- Человек подустал и хочет спокойной и размеренной работы, без челленджей и напряжения
Почему этот вариант – не дефолтный на все случаи жизни?
У него есть стратегическая проблема:
Если человек является абсолютно безопасным и надёжным исполнителем для задачи, скорее всего, сам он воспримет задачу как рутину. Она не будет вызовом, не поможет ему выйти на новый уровень и так далее. Если делегировать только таким способом, сотрудники начнут протухать и перестанут развиваться. Самые проактивные – начнут менять работу.
Так что используй эту схему делегирования с умом.
––
b. Человек "наверное" справится. Задача чуть сложнее, чем те, что он часто решает. Или в целом является для него новой, но ты веришь, что он разберётся.
Стратегически – лучший вид задач для развития сотрудников и команды. Ровно такое делегирование позволяет прокачивать людей и поддерживать нематериальную мотивацию в работе. Эту схему делегирования обязательно нужно использовать, если хочешь развивать команду.
Но у неё, конечно, есть тактические риски. Наше "наверное" будет реализовываться: человек споткнется, поймет что-то неправильно, придётся переделывать и тд.
Поэтому:
- Не используй эту схему, если сделано должно быть "завтра" или "идеально".
- Как можно конкретнее и детальнее сформулируй "образ результата". О нём – в параграфе ниже
- Убедись, что человек мотивирован более, чем на уровне "ну, ладно, так уж и быть". Без этого трудности и ошибки могут его серьёзно подкосить
––
c. Человек почти гарантированно не справится. Его уровень значительно ниже, чем необходимый для выполнения задачи
– Зачем мы вообще обсуждаем этот кейс? Вроде всё очевидно – делегировать задачи по такой схеме не стоит, так ведь?
Да. Ну..почти.
Есть интересный корнер-кейс: человек ну очень хочет научиться решать такие задачи и вырасти. Глаза горят, в бой рвётся, но задача превышает его скилл даже не в 2, а, скажем, в 10 раз. Например, инженер недавно научился в существующие микросервисы правки вносить, а у тебя на носу – большой новый проект, где нужно по сервису в неделю клепать.
Очевидно, человек не может стать ответственным за проект. Но, если задачу можно декомпозировать или срок не супер-сжатый, полезный выхлоп может дать такая схема:
- Выбрать компетентного ответственного за проект (иногда – это ты. Иногда – другой инженер из команды)
- Рвущегося в бой новичка поставить ответственным за часть задачи + понаблюдать за ходом проекта в целом. Ответственного за проект – попросить его поменторить
Проект сойдётся позже, чем при полном выполнении компетентным сотрудником, но даст стратегические преимущества:
– Более прокачанный по хардам и, что важно, мотивированный новичок– Более прокачанный по софтам (да – эти навыки тоже нужно развивать) инженер высокого уровня– Усиленные горизонтальные связи в команде
Повторюсь, делать это можно если у новичка много мотивации и сроки проекта позволяют. Ну и "старичка" надо не забыть спросить :)
Подписывайся на мой ТГ-канал, чтобы первым узнавать о новых статьях. 👇