Организационная модель для гибких организаций: unFIX

Ну что, давайте уже перейдем к модели? Поехали!

В модели unFIX экипаж это команда, обычно состоящая из 3-7 человек. Большее количество возможно в зависимости от контекста, но во многих случая я бы этого не рекомендовал. Как я объяснял в своей первой книге, оптимальный размер команды это пять человек (другие фреймворки предлагают семь, но по-моему, гибридный формат работы требует несколько меньшего размера команды). Участники команды в основном полностью выделены на работу в составе экипажа, но могут резервировать небольшую часть недели на работу в интересах форума или клуба (см. ниже).

Хотя каждый экипаж может быть командой любого типа, обычно большинство команд скорее всего должны быть поточно-ориентированными. Эти самоорганизующиеся, кроссфункциональные команды (в терминах фреймворка LeSS - feature teams) управляют своими встречами (планирование, чек-ин, обзор, ретроспектива). Управляют своей документацией и релизами. Могут действовать в соответствии с командными договоренностями, определяющими идентичность команды, общие правила и что-либо еще. В отличие от LeSS, эта модель допускает не только поточно-ориентированные экипажи. Для существования других трех топологий команд могут быть хорошие основания.

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

Некоторые называют экипажи скводами, подами, ячейками, и это абсолютно нормально. Мне нравится "экипаж", потому что это слово предполагает, что участники управляют путешествием совместно. Экипаж корабля заботится о корабле и его пассажирах. Экипаж самолета отвечает за самолет и его перелет. В IT-компании каждый экипаж отвечает за кодовую базу и релизы. Следуя принципу динамических команд, мы ожидаем, что эти экипажи стабильны, но не статичны. Смена экипажа время от времени не должна быть трудной для людей.

На уровне базы могут существовать правила и ограничения относительно того, кто может быть капитаном экипажа, учитывая навыки, синьорность, срок работы в компании и т.д. Капитаны могут назначаться или избираться. Однако у капитана никогда нет функции линейного руководства в экипаже. Капитан НЕ обсуждает карьерное развитие, компенсации, повышения с участниками экипажа. В зависимости от контекста, официальное название должности этого человека может быть менеджер продукта, менеджер проекта, менеджер платформы. В любом случае, он является менеджером путешествия, а не участников экипажа!

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

Примечание: Так проще для капитанов, не обладающий навыками people management, чтобы говорить о зарплатах и повышениях. Я сам грешил тем, что повышал разработчиков до капитанов, и для них было ужасно сложно проводить оценку производительности с командами. Возможно, это не лучшее мое решение.

Все экипажи работают с одной базы в 10 - 150 человек. Такая база содержит некоторое количество экипажей всех четырех стандартных типов, организованных вокруг нескольких потоков создания ценности. База действует как зрелый, независимый бизнес. Она содержит все компетенции, необходимые для того, чтобы придумывать, реализовывать и поставлять продукты, от дизайн мышления до DevOps, от Lean Startup до Lean Manufacturing (если вы можете нанимать людей со всего света, то обеспечить это не составит труда).

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

В идеале, база покрывает пользовательский домен, а не технический. Она похожа на трайб в модели Spotify и Agile Release Train в SAFe. Однако, каденции и синхронизация работ опциональны. Модель Spotify не предписывает их, как и моя unFIX. Могут быть веские основания оставить работу всех экипажей асинхронной. Это ваша база и ваше решение.

Критически важная функция базы заключается в том, чтобы непрерывно реорганизовывать себя в зависимости от потребностей пользовательского опыта. Мы знаем, что оргструктура напрямую связана с архитектурой продукта. Когда архитектура должна измениться, организация должна измениться. Следовательно, база делает все возможное, чтобы помочь экипажам оставаться гибкими. Это включает заботу о минимальных стандартах и правилах для всех экипажей, чтобы переформирование команд было настолько безболезненным, насколько возможно.

Когда я писал свою последнюю книгу, "Startup Scaleup Screwup", я разговаривал со многими стартапами и компаниями в фазе интенсивного роста (в том числе неудачного) по всей европе, включая Spotify, Flixbus, Wise, Typeform, Zalando, Booking, Intercom и Futurice. Среди многих из этих молодых успешных бизнесов я выделил один паттерн, который не включил в книгу - команда шефов, ведущая свой бизнес.

Команда лидеров обычно состоит из Chief Product, Chief Technology и Chief Marketing. Иногда разделение ролей несколько отличается, иногда это команда из четырех или пяти человек, а не из трех. Вне зависимости от должностей и численности, в большинстве случаев шефы обеспечивают линейное руководство всеми в рамках базы. Они - буквально - команда менеджеров. В зависимости от того, как шефы разделяют роли, у каждого из них бывает от трех до двадцати непосредственных подчиненных. Обычно все бэкэнд разработчики подчиняются CTO, все UX-специалисты подчиняются CPO, и т.д. Но что имеет смысл делать, должен диктовать контекст базы.

Основная выгода такого подхода (и многие компании в фазе быстрого роста обнаружили ее гораздо раньше, чем я) в том, что структура подчинения менеджменту базы стабильная, что бы ни происходило с экипажами. Люди могут перепрыгивать из экипажа в экипаж хоть пять раз в год (если этого требует пользовательский опыт или Employee Experience), и при этом никто не сменит менеджера, у менеджмента нет территории, которую имеет смысл защищать! Только шефы ответственны за найм, компенсации, повышения и т.д. В то же время они могут делегировать потоки создания ценности капитанам экипажей, а функциональную согласованность - председателям форумов (см. ниже).

Примечание: включение линейного менеджмента в модель unFIX это разительный контраст "безменеджерского" подхода SAFe. Который намеренно умалчивает о линейных менеджерах, чтобы SAFe было проще внедрять в существующие бюрократические структуры. Тем не менее, перегрузка из-за матричной структуры, которая из-за этого получается, представляет собой потенциальный кошмар!

Как команда лидеров, шефы несут ответственность за продукт, маркетинг и технологию всей базы. Они устанавливают курс на видение, цели, процессы, признание и вознаграждение (хотя, по практике, они настолько заняты, что с радостью делегируют значительную часть этого экипажам и форумам). Тем не менее, как CEO выступает главным C-level менеджером, должен быть один шеф, лидирующий всю команду менеджеров базы. Организации, которая окружает базу, нужен один человек, представляющий базу.

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

Форум это опциональная конструкция, состоящая из 2 - 40 человек. В модели Spotify они называются чаптерами, но я предпочитаю название форумы, потому что оно отражает, что их главное предназначение - чтобы одинаково мыслящие сотрудники собирались, говорили и принимали решения вместе. Может быть форум DevOps, форум UX, форум "взломщиков роста" и т.д. В традиционных организациях проектный офис можно сделать форумом, в более гибких компаниях у менеджеров продукта тоже может быть свой форум. Так как у форумов есть формальная роль в оргструктуре, то какие нужны форумы решают шефы.

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

Теперь, прежде чем вы мне скажете, что это то же самое, что делают чаптеры в модели Spotify, позвольте мне настоять на одном критическом различии - в форуме НЕТ линейного менеджмента! Найм, компенсации, карьерное развитие и обзор производительности НЕ являются частью мандата форума. Предназначение форума - чтобы люди со сходными ролями договаривались о том, как делается их работа в рамках базы путем самоорганизации. Чтобы динамическая пересборка команд была настолько безболезненной, насколько это возможно.

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

Председатель это менеджер форума, а НЕ людей. Позвольте мне повторить это, чтобы убедиться что меня правильно поняли. Человек, который модерирует форум ответствен за все активности форума. Он не менеджер людей, принимающих участие в форуме. Роль председателя это работа по совместительству, обычно выполняемая кем-то синьорным из состава базы. Он управляет дискуссией и решениями, но никогда не говорит относительно компенсаций или повышений. Можно сказать, что председатель это "первый среди равных".

Еще раз, Главная причина отсутствия линейного менеджмента на форуме в том, чтобы поддерживать гибкость. Снова внедрить функциональные департаменты это последняя вещь, которую мы хотим! Когда лидеры форумов получают менеджерскую ответственность за людей, люди становятся частью их территории. Из-за этого сжимать, разделять или объединять форумы становится намного сложнее. Помимо этого вы получите матричную организацию. А это совсем не то, чего мы хотим.

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

unFIX - не модель матричной организации. Да, участники разных экипажей принимают участие в разных форумах, их менеджеры могут быть разными шефами. Но не важно, на какой экипаж вы смотрите - шефы всегда работают в одной команде лидеров. У менеджеров общие цели. Если в экипаже конфликт, его можно эскалировать одной команде менеджеров! Прощай, матрица.

Многие организации больше, чем 150 человек. В таких условиях сотрудникам приходится взаимодействовать с коллегами за пределами одной базы.

Формальный способом для этого - объединение нескольких баз в лигу или дивизион. Лига организована вокруг взаимозависимых потоков создания ценности или связанного клиентского опыта, у нее есть собственная команда менеджмента. Например, несколько B2C баз могут быть объединены в одну лигу, а несколько баз с продуктами B2B - в другую.

Эта конструкция сходна с уровнем большого решения в SAFe, который оборачивает несколько релизных поездов, доставляющих ценность одному или схожим потребителям (модель Spotify такой конструкции не описывает).

Наконец, стандартным неформальным решением для кросс-базовой коллаборации является то, что часто называют как сообществом практики (Community of Practice, CoP), сообществом по интересам (Community of Interest, CoI), центром экспертизы (Center of Excellence, CoE). Это неформальные клубы, добровольные структуры, позволяющие сотрудникам координировать способ работы за пределами одной базы (и даже между несколькими лигами).

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

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

Подход топологий команд дал нам язык, чтобы говорить о разных типах команд. Вы вольны сами нарисовать оргструктуру, состоящую из команд этих четырех типов приемлемым для вас способом. Так и с моделью unFIX. Я предлагаю концепцию экипажей, форумов, баз, клубов и лиг. Теперь это вам предстоит смахнуть пыль со своих навыков LEGO-моделирования и начать строить структуру, которая будет отвечать вашим потребностям. У вас могут быть форумы, состоящие из форумов, базы, обслуживающие другие базы, клубы, оборачивающие несколько лиг и т. д., и т. п.

А как unFIX по сравнению с указанными выше альтернативами?

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

Рамки SAFe значительно шире, чем модель unFIX. Его целевая аудитория - большие традиционные корпорации. Для меньших и более молодых компаний SAFe слишком большой и бюрократичный. Помимо этого, SAFe намеренно умалчивает о линейном менеджменте. Это значит, что любая имплементация SAFe поверх существующей управленческой структуры открывает приглашение к колоссальному количеству недомоганий в матрице.

Сайт LeSS предполагает колоцированные команды, которые должны "оставаться вместе навсегда", а также не оставляет места разблокирующим командам, платформенным командам и командам сложных подсистем. Гибридный формат работы, топологии команд и динамические команды не получили любви от фреймворка LeSS. Мне кажется, что этот фреймворк не готов к будущему.

Холакратия была на хайпе восемь лет назад, но сейчас лишь немногие говорят о ней. Она предложила некоторые инновационные идеи, но холакратия провалилась, потому что была слишком странной, слишком абстрактной, слишком технической. Модель unFIX ближе к текущей реальности, воспринимаемой многими сотрудниками по всему миру. Поэтому организационные изменения, которые помогут бизнесу приблизиться к идеализированной картине, должно быть проще оценить.

И наконец, что насчет Менеджмента 3.0? Что ж, в своей ранней работе я никогда не смел предлагать конкретную организационную модель. Кроме предложения, чтобы все команды стали центрами прибыли. Менеджмент 3.0 всегда был философией для менеджмента и набором полезных практик. Но описанная модель наконец предлагает структуру, которой
Менеджменту 3.0 всегда не хватало, и которая сможет связать весь инструментарий воедино.

Как я говорил ранее, картина новая; идеи - нет. Я знаю быстро растущие стартапы, а также компании в фазе интенсивного роста, которые уже следуют почти всему, что я описал. Они могут называть базы трайбами, экипажи командами, форумы - функциональными единицами. Терминология не важна. Я предлагаю другие слова, потому что они могут помочь людям различить старое и новое. В конце концов, оргструктура это не про названия. Это про намерение, ответственность и принятие решений.

Я верю, что модель unFIX, как она описана здесь, готова для будущего с динамическими командами, топологией команд и гибридным форматом работы. Она позволяет компании стать истинно гибкой организацией. Может быть, вы уже знаете большую часть этого, потому что видели схожие советы в других местах. Это здорово. Но я уверен, что мои картинки лучше :).

Я предлагаю эту модель командам и организациям, чтобы помочь с само-улучшением, Lean-Agile трансформации и усилиям по вовлечению клиентов. Скачать PDF с этой моделью может любой зарегистрированный пользователь Shiftup.