Изменения в управлении часто ассоциируются с громкими заявлениями, трансформациями, реструктуризациями и, конечно, внутренним сопротивлением. У нас всё случилось иначе.

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

Небольшое вступление

Если коротко, то в теории управления выделяют три уровня эволюции менеджмента:

• Менеджмент 1.0 — жесткая иерархия, приказы и наказания

• Менеджмент 2.0 — контроль, вертикаль и эффективность

• Менеджмент 3.0 — доверие, вовлечение и устойчивое развитие команд

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

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

С чего мы начинали

До относительно недавнего времени наша управленческая модель вполне соответствовала принципам менеджмента 2.0

• У нас были понятные роли и иерархия

• Мы активно использовали KPI, one-to-one встречи, оценку по целям

• Руководители выполняли роли коучей и координаторов, но ключевые решения всё ещё принимались наверху

• Подход был стабильным, отработанным, понятным всем участникам процесса

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

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

Как начался переход

Оглядываясь назад, можно уверено сказать, что изменения начались не с указа сверху, а с практических задач в проектах. Мы работали в agile-форматах, внедряли Scrum и Kanban, обучали сотрудников, а вместе с этим начались и изменения в подходе к управлению.

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

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

• Руководители отошли от роли проверяющих и перешли в роль помогающих. Раньше менеджеры регулярно устраивали статус‑встречи, на которых проверяли кто что сделал, где задержки, какие проблемы. Формат был скорее контрольным, чем развивающим. Постепенно мы начали заменять такие встречи на командные стендапы и регулярные sync‑сессии, где руководитель не спрашивал «почему не сделано», а помогал убирать блокеры и находил ресурсы для команды.

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

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

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

Появились практики, характерные уже для менеджмента 3.0, такие как Kudo‑карточки, регулярные ретроспективы, обсуждение мотиваторов, командная ответственность. Это происходило шаг за шагом, как логичное продолжение того, что уже работало.

Что помогло перейти на новый уровень

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

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

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

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

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

  Но вместе с тем стали заметны и те, кто раньше держался на плаву за счёт усилий коллег. В условиях прозрачности и самоорганизации такие сотрудники почувствовали себя некомфортно и стали просить перевести их в другие проекты, где ещё некоторое время сохранялись старые управленческие подходы. Со временем кто-то из них смог перестроиться и начать делать реальный вклад в результат, а кто-то принял решение уйти.

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

• Повышение вовлечённости помогло найти новые пути развития. Вместо того чтобы говорить, что сотрудники «не вовлечены», мы начали задаваться вопросом «а что мешает им быть вовлечёнными?» Часто это была не лень и не апатия, а отсутствие прозрачности, обратной связи или влияния на происходящее.

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

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

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

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

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

  Всё это стало возможным потому, что у команд появилась внутренняя ответственность, а не только внешние дедлайны.

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

  Сначала это были отдельные инициативы, в рамках которых кому‑то предложили попробовать себя в новой роли, кому‑то выделили время на обучение. Но со временем всё это сложилось в более осознанную и системную работу с развитием. Каждый сотрудник получил возможность составить для себя индивидуальный план роста, который можно менять. Кто‑то выбирал путь в сторону DevOps, кто‑то в тимлиды, и мы старались поддерживать такие инициативы, подключая наставников и менторов.

  Также мы начали говорить о карьерных ожиданиях не дожидаясь, пока подойдёт время пересмотра грейда или регулярного разговора о перформансе. Общение в формате «где ты сейчас и куда хочешь двигаться» стало постоянной частью рабочих процессов. Это помогало избежать ситуаций, когда человек уходил, просто потому что не видел, что может вырасти внутри. Разговоры о развитии перестали быть формальностью и стали настоящими, с доверием и желанием двигаться вперёд вместе.

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

Почему сотрудники не заметили переход

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

Зачем это все?

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

И нет, это не значит, что теперь всё можно и каждый сам себе начальник. Это значит, что менеджер больше не дирижёр оркестра, а саунд-инженер, который настраивает систему, чтобы она играла.

Что дальше?

Менеджмент 3.0 это не точка назначения, а способ мышления и постоянного улучшения. Мы продолжаем учиться, ошибаться, обсуждать и меняться. Главное, что теперь у нас есть команда, которая не ждёт изменений сверху, а сама их создаёт. А накопленный опыт поможет в переходе к модели управления 4.0, что скорее всего будет происходить в ближайшие 3-5 лет во многих компаниях.

А как у вас? Поделитесь в комментариях, вы уже перешли к новой модели управления или только начинаете этот интересный путь?