Спросите любого тимлида, что он делает с большой задачей. Ответ очевиден: «Декомпозирую». Мы умеем дробить фичи на задачи, эпики на сториз. Но почему тогда решения все равно уплывают наверх? Почему команда замирает в ожидании вашего вердикта по любому, даже мелкому вопросу? Ответ прост: мы декомпозируем задачи, но не власть. А в современной разработке скорость принятия решений так же важна, как и скорость кода. Пора научиться делегировать не только работу, но и право решать.
Матрица принятия решений: какие решения вы оставляете за собой, какие делегируете команде
Чтобы перестать быть «бутылочным горлышком», нужно четко определить, где вы незаменимы, а где лишь мешаете процессу. Разделите все решения на четыре категории:
Лидерские (ваши)
Стратегические выборы, которые определяют будущее команды или продукта.
Пример: выбор стека технологий для нового проекта, решение об увольнении сотрудника, согласование ключевых KPI.
*Правило: таких решений должно быть не более 10-15%.*
Консультативные (вы решаете после совета)
Решения, где вам критически важна экспертиза команды.
Пример: выбор конкретной библиотеки для реализации фичи, архитектура модуля.
Процесс: вы запрашиваете мнения, но итоговый выбор за вами.
Совместные (решает команда с вами)
Решения, важные для всех, где вы — равный участник.
Пример: принятие код-стайла, правила код-ревью, процесс онбординга.
Процесс: решение принимается голосованием или консенсусом, ваш голос — один из многих.
Делегированные (команда решает сама)
Оперативные и технические решения в рамках их компетенции.
Пример: как именовать переменные в своем коде, в какой момент делать коммит, как тестировать свой модуль.
*Правило: таких решений должно быть 70-80%. Ваша роль — очертить рамки и не вмешиваться.*
Выпишите эти категории на виртуальной доске и вместе с командой классифицируйте типичные решения. Вы удивитесь, сколько из них можно смело передать в четвертую категорию.
Техника «Решение за 15 минут»: алгоритм для сотрудников, чтобы они действовали самостоятельно
Главный страх сотрудника: «А вдруг я приму неверное решение, и меня накажут?». Чтобы снять этот барьер, внедрите простое правило.
Правило 15 минут:
Если перед сотрудником возникает проблема, он должен потратить не более 15 минут на то, чтобы решить её самостоятельно. В его распоряжении: документация, коллеги и поиск в интернете. Если за 15 минут решение не найдено — он обязан обратиться за помощью.
Что это дает: Снимает паралич выбора: Четкий временной лимит мотивирует действовать, а не перекладывать ответственность.
Развивает компетенции: Сотрудник учится самостоятельно искать ответы.
Экономит ваше время: К вам приходят уже с проанализированной проблемой и, часто, с готовыми вариантами решений.
Ваша задача — донести, что ошибиться в рамках этих 15 минут — не преступление. Ценность самостоятельности выше цены возможной мелкой ошибки.
Как бороться с «вертикальным ожиданием» — когда команда ждет вашего вердикта по любому вопросу
«Вертикальное ожидание» — это привычка команды делегировать решения наверх по умолчанию. Ломается эта привычка не словами, а процессами.
Правило «Сначала предложи решение». На любой вопрос, с которым к вам обращается сотрудник, ваш первый ответ должен быть: «Что ты сам предлагаешь?». Это смещает фокус с поиска ответа у вас на генерацию решения у них.
Легализуйте «право на ошибку». Публично рассказывайте о своих прошлых ошибках в решениях. Когда команда видит, что руководитель может ошибаться без катастрофических последствий, им становится психологически проще брать ответственность на себя.
Создайте «реестр решений». Заведите общий документ (например, в Notion), где команда будет фиксировать важные принятые решения с обоснованием. Это создает базу знаний и снижает тревожность («а вдруг мы уже это решали?»), а также дает вам возможность ненавязчиво отслеживать процесс, не вмешиваясь в него.
Роль «владельца продукта» vs «владельца технологии» внутри команды
Внутри команды можно и нужно распределить не только исполнительскую, но и продуктовую ответственность. Для этого введите две роли:
Владелец продукта (Product Owner) внутри команды
Это не официальный Product Owner, а делегированная роль. Например, на ротационной основе. Этот человек на время спринта отвечает за:
- Приоритизацию технических задач внутри спринта (совместно с тимлидом).
- Коммуникацию с внешним PO или заказчиком по уточнению требований.
- «Защиту» команды от непродуманных изменений в процессе спринта.
Владелец технологии (Technology Owner)
Также ротационная роль. Специалист, который отвечает за:
- Качество определенного модуля или сервиса.
- Актуальность технической документации.
- Инициирование рефакторинга и борьбу с техническим долгом в своей зоне.
Что это дает?
Команда перестает быть пассивным исполнителем. Она начинает самостоятельно управлять своим продуктом и своей технологией. Вы освобождаетесь от роли «главного по всем вопросам» и можете сфокусироваться на стратегии и развитии людей.
Подведем итог
Декомпозиция власти — это следующий эволюционный шаг после декомпозиции задач. Это переход от модели «руководитель-центр вселенной» к модели «руководитель-архитектор системы». Вы создаете структуру, где право принимать решения максимально приближено к тому, кто обладает для этого экспертизой. В такой системе команда растет быстрее, решения принимаются качественнее, а вы наконец-то получаете возможность заниматься тем, что действительно важно для роста, а не для сиюминутного операционала. Вы управляете не процессами, а потенциалом.
🎁 Если вы дочитали статью до конца — значит, вам действительно
важно развивать свой бизнес и избегать ошибок в digital. Еще больше
откровенного и полезного контента без воды читайте в моем личном
Telegram-канале. Подписывайтесь прямо сейчас:
👉 TG: Чегодаев Павел - digital для руководителей