Делегирование ломается не из-за плохих людей. Оно ломается из-за отсутствия приборной панели.
Представьте: вы отдали руководителю целое направление. Через месяц спрашиваете: — Как дела? — Всё хорошо.
Ещё через неделю приходит эскалация от бизнеса и выясняется, что backlog вырос в два раза, сроки поплыли, несколько проблем повторяются месяц, а команда давно работает в аварийном режиме.
После такого у руководителя обычно включается защитный механизм.
Начинаются статусы. Чаты. Созвоны. «А покажи задачу». «А почему так решили?» «А кто ответственный?”
И вот вы уже не делегируете. Вы микроменеджерите.
Для себя я пришёл к довольно простой мысли:
между слепым доверием и микроменеджментом должен находиться слой объективных метрик.
Когда я отдаю направление, я хочу перестать контролировать способ работы, но продолжать видеть состояние системы.
Например, в разработке есть DORA-метрики:
Deployment Frequency — как часто мы доставляем изменения;
Change Lead Time — как быстро изменение доезжает до production;
Change Fail Rate — какая доля изменений приводит к проблемам;
Failed Deployment Recovery Time — как быстро команда восстанавливается после неудачного изменения.
Это хороший пример не потому, что DORA решает все проблемы разработки.
А потому что четыре показателя позволяют быстро увидеть две вещи: скорость и устойчивость delivery. Современная DORA-модель именно так рассматривает software delivery performance.
То же самое можно построить практически для любого направления.
Поддержка: SLA, backlog, время первого ответа, время решения, количество повторных обращений, доля эскалаций.
Инфраструктура: доступность, latency, error rate, MTTR, capacity.
Продукт: конверсия, активность, retention, экономика ключевого сценария. Важно другое: метрики не должны жить отдельно.
Они должны соединяться в причинно-следственную цепочку.
Например: растёт Change Fail Rate → становится больше инцидентов → растёт нагрузка на поддержку → увеличивается backlog → ухудшается SLA → страдает клиент.
И вот тогда у руководителя появляется настоящая система управления.
Мне не нужно каждый день спрашивать:
«Что у тебя происходит?»
Я это вижу. Если показатели нормальные — я не вмешиваюсь.
Если они начинают отклоняться — мне важно понять три вещи:
Руководитель это видит? Он понимает причину? У него есть план?
Если да — он продолжает управлять самостоятельно.
Если нет — тогда уже включаюсь я.
Поэтому для меня делегирование — это не просто передача задач.
Это передача права принимать решения при сохранении прозрачности результата.
Причём чем выше уровень руководителя, тем меньше мне интересно, как именно он решает задачу.
И тем важнее понимать, что происходит с системой, за которую он отвечает.
Наверное, поэтому я всё меньше верю в формулировку:
«Нужно просто доверять людям».
Доверять нужно.
Но управление начинается там, где к доверию добавляются данные.
Иначе это не делегирование. Это надежда.
· 10.08
Есть ещё один нюанс. DORA не показывает потенциальную мощность команд, так как не учитывает простои в работе (space учитывает) по внутренним и внешним факторам. Ну и обе системы не покажут, почему вырос бэклог, и не освобождают от базовых управленческих мероприятий при делегировании задач.
Поэтому делегирование ломается не от плохих людей, а от плохил управленческих навыков.
Мы же все прекрасно знаем - "хороший человек - это не профессия", ровно как и плохой человек - это не профессия)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён