Новая модель внедрения изменений Джона Коттера. Часть 3: Устранение препятствий для изменений

Продолжаем подробно рассматривать Модель Коттера. И сегодня я развёрнуто расскажу про шаг №5 «Устранение препятствий для изменений» с примерами и лайфхаками, как поступить в той или иной ситуации.

Предыдущие статьи: про шаги 1 и 2, про шаги 3 и 4

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

Самые частые части системы, которые забывают поменять, внедряя новые процессы:

• Система целеполагания

• Сами цели

• Организационную структуру (хотя в последнее время про это вспоминаю, всё чаще)

• Система бюджетирования

• Система мотивации (материальной)

Давайте подробно остановимся на каждом пункте.

Часто изменения связаны с изменением структуры команд, проектов, продуктов, отделов и департаментов. Современный менеджмент часто предлагает нам создание новых кросс-функциональных структур. Об этом же Дж. Коттер пишет в той же книге, где описывает новую модель («Ускорение перемен»). Так вот если мы создаем кросс-функциональные структуры, например, из Product-ов, разработчиков, QA, админов и безопасников, мы должны поменять и систему целеполагание, чтобы у этой команды была общая цель. Иначе вы не получите никакого профита от кросс-функциональной команды: формально они будут единой группой, но по факту у каждого из них будет свой начальник со своими целями, часто противоречащими друг другу.

Ни для кого не секрет, что цели по стабильности и ИБ у DevOps-ов и безопасников лучше всего достигаются, если разработчики не будут ничего выпускать про Production. В то время как цели product-экспертов и разработчиков лучше всего будут достигаться, если QA, сопровожденцы и ИБ-шники не будут проверять вообще инкремент продукта.

Решить это можно с одной стороны достаточно просто с другой стороны сложно из-за перераспределения власти в компании. Цели для таких команд будут состоять из по большому счёту из двух частей:1. Достигнуть такой-то бизнес результат (MAU, CSI, прибыль и т.д.)2. Не уронить метрики качества, безопасности и надежности ниже определенного уровня (кстати, CSI для некоторых компаний может оказаться в этой группе)И все эти цели стоят у всех из кросс-функциональной команды с равным приоритетом.

Проблемы возникнут с тем, что начальники департаментов DevOps, ИБ, QA теряют власть над своими вчерашними подчинёнными. А с властью расставаться, ой как не просто.

Только не спешите увольнять этих начальников, как сгоряча делают некоторые компании. Часто это очень компетентные в своей области люди (правда, бывает по разному) и они могут остаться лидерами компетенции:• Обучать сотрудников• Инициировать и поддерживать создание и развитие стандартов в данной компетенции• Помогать разрешать сложные задачи сотрудников своей компетенции.

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

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

Отчасти затронул эту тему в системе целеполагания, но упомяну ошибки, которые встречал в нескольких компаниях:

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

2. В целом достаточно безнадежно ожидать эффекта, например, от Scrum, если у вас в Scrum-команде только разработчики, а аналитики, тестировщики, DevOps и Продакт в отдельных подразделениях или не дай боже отдельных Scrum-командах

Знаю, что трудовое законодательство многих стран не даёт тасовать орг. структуру достаточно часто, а на первых порах вам придется переделывать структуры несколько раз, т.к. очень маленькая вероятность что вы с первого раза учтёте все нюансы. И тут есть два решения:

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

2. Сделать новую структуру достаточно плоской: для малого и среднего бизнеса подойдёт, если все просто будут в одном подразделение подчинённым напрямую CEO. В крупных организациях обычно выделяют бизнес-юниты, которые способны достигать бизнес-результатов самостоятельно без других. Если говорить про продуктовые компании, то каждый продукт – просто отдельный юнит, включающий всё что нужно для создания продукта: Marketing, Sales, Product Management, Software Development, QA, DevOps, Cyber Security и т.д.И уже в этом пуле создаются виртуальные структуры, которые можно менять достаточно гибко.

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

Хочу вас уберечь также от того, чтобы заморозить все изменения до того, как бюджетирование поменяется. Во-первых, это может остановить вашу трансформацию на год, а то и больше, во-вторых, часто вы не будете заранее знать, как именно нужно поменять систему. Поэтому можно выбрать для пилотной части компании/продукта отдельных способ бюджетирования, который часто в компаниях существует для R&D, когда вы выделяете определённый бюджет на год, а внутри этого бюджета менеджер этого подразделения (либо подразделение коллективно), сами решают, как расходовать бюджет, какие цели ставить, а в конце года, или может раньше - в зависимости от того какой у вас пробный период для нового подхода, вы замеряете эффективность нового подхода, в первую очередь смотря, каких результатов они добились – выше или ниже ожидаемых, насколько они хороши относительно остальной части компании. Эти метрики эффективности, конечно, стоит установить до старта пилотных изменений.

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

• Безбюджетное управление (Beyond Budgeting)

• Свободное расходование средств подразделениям без планирования бюджета

Здесь я имею в виду именно материальную мотивацию, т.к. не материальная, как правило и так достаточно гибкая. А материально жутко инертная, в первую очередь именно потому, что связана с деньгами и всё боятся что-то поменять в ней.

Часто система премирования завязана на систему целеполагания, если вы изменили целеполагания, то должны в тот же момент (или хотя бы не сильно позже) поменять систему мотивации. Если это не сделать, то люди либо продолжат действовать по-старому, либо вообще свихнуться 😊, точнее начнут выгорать из-за когнитивного диссонанса.

Частые возражение против переделки системы мотивации и как их нивелировать

Самый простой способ этого избежать – заложить в новой системе ограничение сверху.

Тут уже сложнее. Получается, мы используем систему премирования не по назначению, а прикрываем с помощью неё проблемы в системе назначения зарплат. И как следствие, если нам нужно поменять теперь не только систему премирования, но систему назначения и повышения окладов.

Горькая правда большинства компаний в России, что руководители умеют управлять сотрудниками только с помощью страха. В целом схема достаточно рабочая и многие успешные компании во всём мире продолжают её использовать по крайней мере для части сотрудников. Но тут ключевая фраза «для части». Исследования Питера Друкера и других учёных показали, что для интеллектуальных профессий денежная мотивация должна использоваться совершенно по другому нежели многие привыкли. Если вы говорите, разработчикам, что они получат премию, если запилят фичу к такому-то сроку, фичу то они запилят, но вопрос с каким качеством они это сделают? А не дай бог вы Продакту поставите цель набрать столько-то пользователей к 1 января иначе не получишь премию равную Х окладам… Он будет на таком стрессе, что ничего креативного точно не придумает, и если цель очень амбициозная, то может стимулировать такого Продакта принять решения вредные для компании: например, пообещать бонусы каждому зарегистрировавшемуся, что приведёт к фроду от новых пользователей, зато Продакт достигнет краткосрочную цель.

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

Следующая статья про шаг 6