"Давай просто снесём PO" - и почему я этого не сделал

Можно нанять правильных людей. Выстроить экономику найма и удержания. И все равно получить систему, которая не дает нужной скорости. Не потому что люди слабые. А потому что ответственность не распределена, решения зависают, а конфликты между ролями съедают скорость. Точнее, деньги. Именно в этой точке начинается работа с оргдизайном функции.

Проблема

Формальная структура и реальная модель управления - почти всегда три разные версии одной и той же реальности.

Первая лежит в Miro, HRMS, 1С, SAP или вообще в Excel

Вторая - в головах людей

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

Пока все три не совпадают, любые изменения будут вязнуть. Не из-за технологий. Из-за того, что никто не понимает, кто за что реально отвечает. Оргдизайн - это не просто схема на слайде. Это рабочая конструкция ответственности, полномочий и взаимодействия, через которую команда либо дает результат, либо начинает тормозить сама себя.

Кейс

Большая продуктовая команда. Один из ключевых продуктов компании. Существенная выручка, хорошая маржинальность. Четыре основных игрока: BO, PO, DM, TL.

PO давил на команду. TL держал в голове большой технический контур и смотрел на него скорее с архитектурного уровня. В распределение ответственности и передачу знания заходил без большого энтузиазма. DM оказался между тремя огнями - ожиданиями бизнеса, давлением со стороны PO и ограничениями технического контура, который замыкался на TL.

Вместо рабочей связки между BO, PO, DM и TL получился постоянный конфликт ожиданий, полномочий и ограничений.

Изначально ко мне пришли с очень простым предложением: "давай просто снесем PO".

Такая реакция понятна. Когда система перегрета, всегда хочется найти одного виноватого и быстро убрать его из уравнения. Но в таких историях дело почти никогда не в одном человеке. Роли не договорены, границы полномочий размыты, а фактическая система управления живет отдельно от формальной.

Ситуация вышла на уровень борда. CEO зашел ко мне в кабинет и поставил задачу разобраться.

Решение

Пригласил коллег к себе. Не для того, чтобы объяснить им, как правильно. А для того, чтобы они сами собрали матрицу на базе подготовленного мной черновика.

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

Сопротивление было. И не только со стороны TL, но и со стороны PO. ЭГО работает в обе стороны. Каждый защищает свое и матрица, спущенная сверху, не работает. Матрица, которую люди собрали сами, меняет поведение. Отрицать то, что ты сам написал, значительно сложнее. После этого роли перестали спорить за территорию, а решения - зависать на стыках.

Почему RACI работает только через вовлеченность

RACI - инструмент простой. Но сам по себе он ничего не меняет. Самое сложное здесь - сделать так, чтобы человек увидел в этом свою проблему, а не чужую задачу.

Если он этого не видит, он будет кивать на встречах и дальше саботировать за дверью. Когда видит, перестает защищать старую позицию и начинает искать рабочее решение. И первое время это нужно держать под контролем. Иначе матрица так и останется таблицей в Excel.

Что изменилось

Конфликт между ролями перестал ломать работу команды. Решения перестали зависать. Команда начала работать на результат, а не на выяснение, чья это зона.

PO изменил стиль работы с командой, правда через полгода ушел с повышением в другую компанию. TL получил четкие границы, внутри которых его экспертиза начала работать в полную силу. В итоге он стал ИТ БП по этому стриму. DM перестал быть точкой постоянного конфликта между ролями и получил понятный контур ответственности.

Основной вывод

Оргдизайн - это про реальные правила игры внутри команды и функции. Кто за что отвечает. Кто принимает решения. Где проходят границы полномочий. Как связаны команды между собой. Где возникают стыки и конфликты.

Пока формальная структура не совпадает с реальной моделью работы, система управления будет давать сбой. Не из-за технологий. Из-за того, что ответственность и право на решение живут в разных местах.

Когда формальная структура и реальная модель работы совпадают, команда начинает работать как система. А не как группа людей с пересекающимися интересами.

В следующей статье - расскажу, как CIO выстраивает работу с HR. Не как заказчик, а как партнер