Какое самоуправление нужно сотрудникам?

При внедрении механизмов самоуправления в компании на основе Agile-методов или социократии или других подходов часто сталкиваются с тем, что сотрудники не готовы брать на себя ответственность и очень слабо проявляют инициативу. Особенно явно это проявляется, когда сотрудников побуждают не просто проявлять инициативу, а делать это на уровне бизнеса, предлагая новые бизнес-идеи и вкладываясь в их реализацию, по сути, организуя внутренние стартапы. Часто приветствуют такие изменения лишь малая часть сотрудников, а остальные не спешат принять в этом деятельное участие, даже если в целом поддерживают изменения.

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

В этой статье я не буду рассказывать модель Спиральной динамики. Об этом у меня было большое количество статей, и если она вам не знакома, вы можете обратиться к статье «Спиральная динамика – модель изменения mindset с развитием общества» и последующим статьям серии «Менеджмент цифрового мира», или к краткому описанию уровней на моем сайте, или другим материалам. А в этой статье мы поговорим о том, как объясняются описанные выше проблемы.

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

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

Если говорить о представлениях об идеальной работе, то у многих людей оно включает достаточно сильную составляющую синего уровня – представление об организации с разумно устроенными правилами. Это вовсе не означает отсутствия инициативы у сотрудников, но инициатива должна проявляться на тех должностях и в тех направлениях, где это предусмотрено правилами организации, а вовсе не произвольно и повсеместно – ведь ее необузданное применение неизбежно приведет организации к хаосу и разрушению. Отметим, что таки люди естественным образом выбирают для работы компании, в которых правилам отводится важная роль. А именно чрезмерность правил и отсутствие гибкости, необходимой для успешного развития компаний в современном VUCA-мире, часто служит предпосылкой для трансформации.

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

Для разработчиков в IT или для инженеров областью ожидаемой инициативы служит техническое совершенствование продукта, для врачей – освоение и применение новых методов диагностики и лечения, и так далее. А вот область выявления потребностей потребителей – пользователей софта или другого устройства, или потенциальных пациентов, в их представлении, за пределами их профессиональных интересов, этим должны заниматься другие сотрудники, поставляя им результат, готовые запросы. Эти представления характерны не только синего уровня, но и оранжевого, различие лишь в источнике таких представлений: для синего уровня представления о потребностях должны выявляться научными исследованиями, а для оранжевого их формирует предприниматель из своего понимания устройства мира, делая предпринимательскую ставку.

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

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

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

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

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

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

Если рассматривать не только руководство, а все аспекты деятельности команд, то это же показывает ролевая модель Белбина. Там эмипирически выделено 9 ролей, дополняющих друг друга в деятельности, при этом у человека есть от одной до трех предпочтительных, а работа в других ролях требует большого напряжения по той же причине: сильные стороны одной роли являются слабостями другой, и находясь в несвойственной роли ты должен вести себя несвойственным образом. Например, одни роли Шейпера или Генератора предполагает харизматичное следование своему пути и своим идеям, а роли Координатора или Аналитика стратега – умение слушать людей и анализировать ситуацию, принимая взвешенные решения с учетом чужих мнений. Роль Педанта или Специалиста предполагает внимание к деталям, а Генератора или Исследователя ресурсов, наоборот, мысли на уровне общих концепций и идей. Подробнее о модели Белбина у меня есть доклад на TeamLeadConf и статья в журнале MyType.

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

Я наблюдал за этим процессом в IT: еще в конце прошлого века разработку вели просто программисты. Хотя уже тогда было деление на системных программистов и прикладных в разных областях, например, по вычислительным методам для расчета ракет или других физических объектов, или по искусственному интеллекту. Потом выделились специализации аналитиков, тестировщиков, дизайнеров интерфейсов, юзабилити, сама разработка поделилась на серверную часть, разработку баз данных, web и мобилки, тоже поделенные по платформам. И сейчас специализации все углубляются, хорошее владение всеми областями встречается редко, хотя такие специалисты, называемые full stack разработчиками, тоже встречаются.

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

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

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

При этом возможны два варианта. В одних компаниях есть люди, которые занимаются развитием продуктов, и они выступают в роли подразделений-заказчиков. Но как-то это развитие не слишком хорошо происходит: новое делают долго, первые версии оказываются совсем не похожими на то, что ожидали, и в целом эффект не впечатляет, скорее видны расходы без отдачи. При этом в провале каждый обвиняет другого, одни говорят: «сделали не то и дорого», а другие: «они сами не знают, чего хотят, все время меняют требования». В этом случае имеет смысл делать объединенные рабочие группы из тех, кто отвечает за развитие продуктов и их продвижение и тех, кто эти продукты реализует. В зависимости от характера бизнеса, эти группы могут иметь долговременный характер, превращаясь в команду развития продукта, или создаваться под каждую конкретную инициативу, под новый продукт или гипотезу о развитии.

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

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

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

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

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

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

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

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

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

Уже много лет в этом направлении идут банки, что связано с высокой цифровизацией их бизнеса. Отдельным драйвером послужило появление и успешное развитие Тинькофф-банка, который с самого начала организовывался как цифровой и успешно конкурировал и конкурирует на равных с топовыми банками в уже занятых другими банками нишах. Примеры тут всем известны – Райффайзен, который давно экспериментирует с самыми разными механизмами самоуправления, Альфа и Сбер, которые после попытки ограничить Agile только IT-проектами, вынесенными в отдельные компании, пришли к необходимости трансформации банка в целом, и другие. Интересен тут пример банка Агророс, в котором трансформации подверглась операционная деятельность банка, а целью было сделать работу в банке привлекательной для инициативной молодежи, решив кадровые проблемы. Об этом на AgileDays-2019 рассказывал председатель правления банка Дмитрий Кондрацков в докладе «550 дней Agile в операционном управлении!» (мой конспект), и они достигли успеха и в основной цели и в повышении эффективности. Подробнее банковские кейсы я разбирал в статье «Кейсы Agile-трансформации. Часть 1 — банки».

В этом случае возможны два пути: эволюционный и революционный. И революционный может оказаться предпочтительным, потому что на пути к самоуправлению и инициативе стоит очень жесткое препятствие в виде привычной системы управления. Руководители нижнего и среднего звена часто блокируют все инициативы по перестройке процессов. Но даже если они понимают необходимость изменений и в принципе готовы поддержать энтузиазм подчиненных, все очень часто упирается просто в привычную организацию ежедневной деятельности, при которой одни привыкли давать указания, а другие – их выполнять. И эту привычку необходимо преодолеть, и революционный путь помогает этому. В Scrum встроены предохранители против возврата к традиционным способам, например, там вообще нет места, в котором сотруднику можно дать конкретную задачу: закончив текущую, он берет с доски очередную по сформулированным правилам. Подробнее я разбирал Scrum в статье «Scrum — пять изменения организации команды, принесшие успех Agile» и последующих в этой серии, а про работу с культурой – в статье «Изменение культуры в успешной Agile-трансформации».

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

Если же представляется, что компания не слишком окостенела и имеет достаточный запас гибкости и энтузиазма, то может быть выбран эволюционный путь. Способ такой перестройки дает Kanban: мы стартуем от существующей структуры, делаем прозрачным поток работ, а затем запускаем мероприятия, в которых сотрудники локализуют и устраняют проблемы на этом потоке. Проблемы могут быть как на стыке между подразделениями, так и внутри подразделений, а средством решения являются постоянные или временные рабочие группы из заинтересованных сторон, которые ищут решения и осуществляют изменения. Подробнее я писал об этом в статьях «Kanban и Lean — эволюция вместо революции» и «Эволюционное изменение культуры при Kanban-трансформации». Изменение культуры очень важно. Открытость потока задач и прозрачность работы подразделений для всей компании является очень существенным изменением культуры, потому что всем, а не только руководителю, становится видно, кто из сотрудников какие задачи решает и в каком темпе разные сотрудники это делают. И надо обеспечить, чтобы эта открытость вела к взаимопомощи и здоровому соревнованию, а не к склокам, интригам и поиску виновных. Это – возможно, но это не происходит само.

Таким образом, в любом случае происходит параллельная перестройка организационных механизмов и изменения культуры. Одних организационных изменений недостаточно, об этом часто забывают. Но столь же недостаточно только работы с культурой, развитие духа сотрудничества и совместной работы – они должны быть поддержаны организацией. Собственно, это один из наиболее ценных результатов исследований Фредерика Лалу, описанных им в книге «Открывая организации будущего» явилось описание сложных организационных механизмов, лежащих в основе самоуправляемых организаций. Они – сложнее, чем в традиционных иерархиях и намного сложнее, чем думали футурологи.

Примером является подход к принятию решений. В традиционных компаниях решение преимущественно принимают единолично те, в чьей ответственности это находится, хотя для ряда вопросов это делает коллективный орган по процедурам. Достоинства и недостатки обоих способов известны. Футурологи полагали, что в самоуправляемых организациях решения будут принимать коллективно на основе консенсуса, чтобы учесть мнение каждого. Оказалось, что на практике это – очень дорогой способ, который приводит к длинным обсуждениям и борьбе мнений. А еще он сковывает инициативу не хуже коллективных обсуждений на комитетах в традиционных компаниях, потому что всегда есть идеи по улучшению или альтернативным способам. А эффективным является способ принятия решений на основе консента (consent), синтезирующий коллективное обсуждение с единоличным принятием решений инициатором, ограниченным лишь требованием предотвращения явно видимого вреда.

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

Эволюционный путь мягче с точки зрения потрясений для сотрудников и для компании в целом, но сложнее в реализации, трансформация более распределена во времени. И далеко не у всех компаний есть достаточно внутреннего потенциала для такого пути. Любая компания должна быть в равновесии с внешним миром, это обеспечивается ее процессами. Если условия функционирования меняются, то компания может либо попробовать справиться с ситуацией на существующих процессах, интенсифицировав работу людей, либо перестроиться. Если она идет по пути сохранения процессов, то на преодолении разрывов требуется все больше энергии людей, и в некоторый момент она берет настолько много ресурсов, что эволюционные изменения компании становятся невозможными, только революционная перестройка через кризис. Я приведу тут схему из книги Дона Бека и Криса Кована «Спиральная динамика», где вопросы равновесия и трансформации описаны подробнее. Я разбирал это в статье «Гибкость, целеустремленность и эффективность: спектр смыслов в компаниях разной культуры»

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

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

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

И стоит помнить, что самоуправление родилось не вчера, и наработано много методов и практик не только для организации процессов, но и для работы с культурой и ценностями компании: Agile-методы, принципы и практики социократии, OKR для оркестрации целей, консент для принятия решений и многое другое. Стоит их применять и вести трансформацию с учетом наработанного в мире опыта, а не изобретать велосипеды. В этой статье я попробовал часть этого опыта представить, и если у кого появились вопросы – пишите, я отвечу. Как я уже писал, эта статья является продолжением большой серии «Менеджмент цифрового мира», опубликованной на этом портале, оглавление которой есть на моем сайте http://mtsepkov.org/NewMngSeries и часть ответов можно найти там.