Делегирование – это не про навык
«Я просто плохо делегирую» – одно из самых распространенных объяснений, которые дает себе предприниматель. Передал ответственность – результат не устраивает. Назначил руководителя – все равно приходят с вопросами. Нанял сильного человека – через месяц инициативы у него поубавилось.
Вывод напрашивается сам: «нужно научиться делегировать правильно». Читаем книги, проходим курсы, меняем стиль управления…
Но проблема не в навыке. Делегирование – это не личная компетенция предпринимателя. Это следствие того, как устроена система управления. Без нее делегирование невозможно по определению. Как бы хорошо вы ни выстраивали отношения с командой.
Когда ответственность есть, а полномочий нет
Компания в сфере услуг. Два собственника и наемный CEO. Один собственник – инвестор. Второй – владелец продукта, сезонного и единственного. CEO нанят для того, чтобы развивать бизнес и обеспечивать финансовый результат.
Первые месяцы все шло нормально. Бизнес развивался в тех рамках, которые были заданы. Но экономика продукта была такова, что LTV едва покрывал затраты на привлечение и исполнение. Расти на одном продукте было практически невозможно.
CEO предложил решение: расширить продуктовую линейку. Новые продукты для той же аудитории – чтобы увеличить LTV. И старый продукт адаптировать для новой аудитории – чтобы снизить сезонность. Это был очевидный путь к финансовому результату, за который с него спрашивали.
Собственник, отвечавший за продукт, был против. По разным причинам – часть объективных, часть личных. Новые продукты не появлялись. Конфликт затянулся на несколько месяцев.
Формально CEO был назначен управлять бизнесом. Фактически – ключевые решения оставались за собственниками. Продукт – у одного. Финансы – у другого. Ответственность за результат – у CEO. Полномочий, достаточных для его достижения, нет.
Это не конфликт характеров. Это архитектурная проблема. Делегирование без передачи полномочий – это не делегирование. Это перекладывание ответственности без инструментов для ее реализации.
Что обнаружилось при разборе процессов
Конфликт выглядел как личный – два человека с разными взглядами на развитие бизнеса. На самом деле это был симптом отсутствия управленческой архитектуры.
Когда начали разбирать, выяснилось: не было четкого ответа на базовые вопросы. Где заканчивается зона собственника-продуктолога и начинается зона CEO? Какие решения CEO принимает единолично, какие согласовывает, какие остаются только за собственниками?
Без этого CEO не мог двигаться вперед – каждый шаг за пределами привычного сценария упирался в чужую зону или требовал согласования, которое не проходило. Часть процессов, в частности, оказание услуги и клиентский опыт, де-факто находилась в зоне собственника-продуктолога, хотя нигде это не было зафиксировано. CEO туда не мог войти. Собственник оттуда не хотел выходить.
Не было матрицы принятия решений. Поэтому каждое нестандартное решение становилось либо поводом для конфликта, либо просто останавливалось.
Проблема была не в людях и не в продукте. Проблема была в том, что архитектура управления не определяла, кто что имеет право решать.
Что изменилось после
Когда процессы, роли и полномочия были расписаны, решение нашлось само – и оказалось приемлемым для всех сторон.
Собственник, отвечавший за продукт, сохранил полный контроль над тем, что ему было важно: содержание услуги, методология, стандарты качества. Все остальное – процессы оказания услуги, клиентский опыт, операционное управление – перешло к CEO.
Также CEO получил полномочия развивать новые продукты независимо – привлек отдельного владельца продукта, который разработал новые направления. Финансовый результат стал достижимым.
Собственник-инвестор увидел движение к прибыли.
Конфликт, который длился несколько месяцев, решился не через переговоры о характерах и амбициях, а через фиксацию того, кто за что отвечает и кто что имеет право решать.
Это не только про топ-менеджмент
Показательно, что эта ситуация возникла на самом высоком уровне – между собственниками и профессиональным CEO с опытом. Люди компетентные, мотивированные, с реальными полномочиями на бумаге. И даже здесь делегирование не работало, пока не была выстроена архитектура.
Если это происходит на уровне топ-менеджмента, что говорить об уровнях ниже, где руководители менее опытны, зоны ответственности еще менее четкие, а цена каждого управленческого сбоя накапливается незаметно.
Делегирование не работает на любом уровне по одной и той же причине: не потому, что люди слабые, а потому, что среда не выстроена.
Что должно быть выстроено
Делегирование становится возможным только тогда, когда выстроена система управления целиком. Не отдельные элементы, а архитектура:
- четкие зоны ответственности – каждый знает, где его территория начинается и заканчивается
- полномочия, соответствующие ответственности – право принимать решения там, где есть ответственность за результат
- описанные процессы – понятно как работа устроена, что от кого ожидается и как воспроизводится без конкретного человека
- показатели – по которым объективно видно, справляется ответственный или нет (и где именно не справляется), без ручного контроля сверху
- управленческий ритм – решения принимаются регулярно и на соответствующем уровне, а не в режиме пожара
- правила принятия решений – что решается самостоятельно, что согласовывается, что принимается только наверху
Это не список рекомендаций. Это минимальная архитектура, без которой делегирование остается иллюзией, независимо от того, насколько вы умеете объяснять задачи.
Вопрос не в том, умеете ли вы делегировать. Вопрос в том, есть ли в вашей компании система, внутри которой делегирование вообще возможно.
Если каждый раз, передавая ответственность, вы обнаруживаете, что она возвращается, вероятно, дело не в ваших навыках и не в сотруднике. Вероятно, архитектура управления просто не предусматривает того, кому, как и что именно можно передать.