В прошлой публикации я подробно (с картинками) рассказал, как мы институциализировали, т.е. децентрализовали и распределили Е-функцию. А вот тут я делился опытом, как я зарабатывал доверие у своих сотрудников и вместе с ними — у бизнеса.

Сегодня поговорим о том, как мне самому приходилось выдавать кредиты доверия – и все ли они возвращались…

Децентрализация: не просто делегирование

Децентрализация — процесс непростой. По Адизесу, она принципиально отличается от делегирования: - При делегировании руководитель принимает решение, а сотруднику передаёт только право его исполнить. Это безопаснее для лидера — он сохраняет монополию на принятие решений. - При децентрализации сотрудникам (пусть и не всем, а самым доверенным) передаётся право принимать решения в рамках их компетенций.

Как мы увидели в публикациях ниже, количество решений может сильно быстро превысить возможности любого даже самого талантливого руководителя и привести к параличу управления или «Ловушке основателя». Поэтому в наших условиях, когда число сотрудников моего отдела выросло выше всяких разумных норм управляемости, стало просто необходимо децентрализовать управление.

Было ли мне страшно? — Конечно! Был ли у меня выбор? — Вряд ли.

Тогда я еще не знал о методологии Адизеса, но прошел крутые курсы повышения квалификации руководителей в ПСБ. Там я освоил базовые принципы делегирования. Подсознательно я понимал: нужно делегировать именно принятие решений, а не только их исполнение. Можно сказать, жизнь сама подвела меня к тому, к чему Адизес шел десятилетиями.

Как это работало на практике

В большинстве случаев (а это, на секундочку, примерно 25 продуктовых команд + еще примерно дюжина технических руководителей) разделить ответственность и полномочия удавалось простым обсуждением в узком кругу. Но бывали и сложные ситуации. Не буду упоминать имён и должностей — все совпадения случайны.

Случай 1: отсутствие тимлида

В некоторых продуктовых командах не было тимлида — и владельцу продукта приходилось брать эту роль на себя. Многие делали это органично: методология Scrum это предполагает. Но находились и те, кто пытался переложить управление продуктовой командой на технического руководителя — в том числе на меня. К сожалению, лично для меня это закончилось потерей одной из мобильных ролей. Что ж…

Случай 2: расширение зоны ответственности

Бывали и обратные ситуации: некоторые руководители чувствовали в себе столько сил, что начинали вмешиваться в зоны ответственности коллег. Особо часто этим «болели» именно технические руководители. Кажется, что и я сам был какое-то время подвержен этому пороку. Позже в таких случаях я: * хвалил за рвение — инициатива это хорошо; * чётко обозначал границы; * объяснял: я не против делиться задачами и принимать помощь, но прошу предварительно обсуждать это со мной — потому что право принятия решений в зоне своей ответственности я не делегировал.

Удивительно, но такие разговоры всегда проходили конструктивно и даже укрепляли доверие, взаимопонимание и приводили к еще более тесному и сплоченному сотрудничеству.

Выводы: что я понял про доверие и децентрализацию

1. Умение слушать — ключ к разграничению полномочий. Если вы умеете слышать человека (а этому неплохо учит вот эта книга), то договориться о зонах принятия решений несложно. Главное — не жадничать :) 2. Не бойтесь доверять. Люди действуют из лучших побуждений. Если у них есть компетенции, они будут принимать решения не хуже, а иногда и лучше вас. А если ошибутся — вы всегда поможете исправить ошибку. Более подробно об этом будет мой следующий пост. 3. Великие свершения невозможны без децентрализации. Один человек не способен принимать столько верных решений, сколько принимают несколько дюжин квалифицированных сотрудников.