Делегирование ломается не на постановке задачи, а на **моменте возврата**.
Я слышал одну и ту же историю десятки раз: задача отдана, дедлайн стоит, исполнитель кивнул — и через 3 дня она снова на тимлиде. Почему? Потому что вместе с задачей не ушли **границы принятия решений**.
Схема выглядит так:
- назначили ответственного;
- дали срок;
- не дали право выбрать путь;
- не зафиксировали, что считать «готово»;
- оставили у себя право на каждую развилку.
Итог: у вас не делегирование, а **пересылка черновика**.
Потом удивление: почему команда спрашивает очевидное? Потому что вы сами оставили им только выполнение, без P&L-логики решения.
Если задача снова возвращается, обычно не хватает одного из трёх:
1. **контекста** — зачем это делается;
2. **рамки решений** — что можно менять без согласования;
3. **критерия качества** — по чему задача считается закрытой.
Хороший тест: если исполнитель не может назвать, **что именно он решает сам**, делегирования не было. Была временная аренда чужих рук. 🔥
И да, это часто дороже, чем кажется: каждое «а как лучше?» съедает время тимлида так же быстро, как плохой RPM режет выручку блока.
Traffic Money
@TrafficMoneyPro
Делегирование ломается не на постановке задачи, а на **моменте возврата**.
Этот пост опубликован в Telegram-канале Traffic Money. Подписаться можно по ссылке: @TrafficMoneyPro.