Делегирование. Почему это сложнее, чем кажется, и как я с этим разобрался.

Большинство статей про делегирование написаны людьми, которые объясняют теорию. Я расскажу про практику — включая то, что шло не так.
Пятнадцать лет операционного управления научили меня одному: руководитель, который держит всё у себя, демонстрирует не силу, а отсутствие выстроенной системы. И рано или поздно это становится ограничением для всего подразделения.

strong>Главный барьер — не страх, а информационная целостность.
Когда я начинал делегировать, меня останавливал не страх, что сделают хуже. Меня останавливало ощущение, что я теряю картину происходящего.
Я называю это информационной целостностью. Есть задачи, которые держат в голове полное понимание системы. Пока они у тебя — ты видишь всё. Как только они уходят — начинаешь узнавать о проблемах не от команды, а от клиентов или от вышестоящего руководства. Это и есть момент, когда целостность нарушена.
Это не интуиция — это конкретный индикатор. Если информация о проблеме дошла до тебя через команду — система работает. Если она пришла снаружи или сверху — ты потерял нить.
Поэтому управленческие решения я не делегирую никогда. Всё остальное делегируется при правильных условиях.

strong>Как я структурировал зоны ответственности.
Это не универсальная схема — это принцип, который каждый адаптирует под свою структуру.
Входящие обращения, адресованные отделу, закрывают сотрудники отдела. Техническую экспертизу обеспечивает инженер — он владеет ею глубже меня. Документацию и администрирование ведут соответствующие специалисты. Управленческие решения, стратегия, работа с ключевыми клиентами и партнёрами — моя зона.
Как только эти границы стали чёткими, высвободилось время, которое раньше уходило на задачи, не требующие моего уровня компетенций.

strong>Три вопроса перед делегированием.
Первый: разрушит ли передача этой задачи мою картину системы? Если да — оставляю.
Второй: есть ли человек с нужными компетенциями и пониманием инструментов для решения именно этой задачи? Не просто свободный человек — а тот, кто справится.
Третий: не перегружен ли он прямо сейчас? Делегирование перегруженному сотруднику — это не делегирование, это создание новой проблемы.
Если все три в пользу передачи — отдаю. Если хотя бы один нет — выполняю сам или откладываю передачу до подходящего момента.

strong>История, которая изменила мой подход.
Я поставил задачу: собрать статистику обращений за год. Делегировал сотруднику и переключился на другие приоритеты. Через несколько дней получил результаты — человек собирал данные вручную, не используя инструменты выгрузки и фильтрации. Несколько дней работы вместо получаса.
Я задал себе неудобный вопрос: почему так произошло?
Ответ был про меня. Я делегировал задачу, не убедившись, что человек понимает инструменты для её решения. Мы разобрали ситуацию спокойно, я показал как работают выгрузки. Следующий раз та же задача заняла двадцать минут.
Этот случай сформулировал для меня правило, которое я с тех пор не нарушаю: прежде чем делегировать задачу, убедись, что исполнитель понимает инструменты для её решения. Иначе ты делегируешь не задачу — ты делегируешь проблему.

strong>Делегирование как инструмент развития команды.
Когда передаёшь задачу человеку, который с ней раньше не сталкивался, он развивает самостоятельность, расширяет компетенции, понимает, что ему доверяют. Для большинства людей это один из сильнейших мотиваторов.
Ты получаешь время для задач своего уровня. Он растёт. Система становится устойчивее, потому что компетенции распределяются по команде, а не концентрируются в одном человеке.
Антикризисный директор, который не умеет делегировать, — это узкое место всей системы. В момент кризиса, когда нагрузка резко возрастает, такой руководитель становится первым, кто ломается под давлением.