Why Communicating Change in Big Teams So Often Fails
And how to implement it, spread the word, and make it stick.
During my time in R&D and later in a platform team, I was responsible for introducing significant changes to the codebase. Sometimes, this involved deprecating a method, migrating the module to a separate package, or refactoring a widely used piece of code.
While my team and I always paid attention to properly communicating the changes, I was always amazed to learn that many people missed this information. As an initial thought, you might think that they ignored the communication and it’s their fault, but was the communication appropriately done to reach all the people?
Introducing changes to a codebase is usually straightforward and common if it’s not a bigger refactor or introducing a new complex mechanism. When shipping new features and improvements, it’s easy to forget how small changes can affect every developer working on the codebase. Even slight improvement can confuse and block work if not communicated properly. The main problem lies in assessing how important it is to communicate change and how to do it. Most developers would choose not to communicate change apart from their closest team or provide a simple message that disappears shortly.
In my experience, sometimes even using the written word and communicating the change verbally is not enough. The only solution is to communicate and then over-communicate by using different channels.
What Channels to Use to Communicate Changes
It’s important to use different channels to ensure that information reaches everyone. Some channels are short-form and might miss people who are not currently present. Some are long-lived and can be easily consulted when in doubt.
I would start with long-form, long-lived content such as documentation. When communicating changes, you will definitely have to answer a few questions. Creating documentation should prepare for that. It will serve as an explanation that gives the context of the change.
The next step is to make people aware that the change was introduced. Short-form content like a Slack message would be enough to reach most people. Depending on your organization, you might also use communication channels such as an email or a blog to inform people about a change.
If you are working in a big team divided into smaller squads, ask the leaders to communicate change again to ensure that it reaches everyone.
Using ADR to Introduce Change
One great way to introduce change in a team is using Architecture Decision Records documentation. In my opinion, it doesn’t need to be an architectural change; it can be any decision regarding the codebase.
ADR allows you to explain the change with a background. You use sections such as “context”, “decision”, and “consequences” to easily explain why the change was made and its impact.
It’s also stored in a single place with other decisions, making it easier to track significant changes.
“It’s easier to make people aware of something. It’s much harder to get them to actually do something”
When introducing change, it’s easier to make people aware of something. It’s much harder to get them to actually do something. Imagine asking all the teams to migrate their part of the app to a new package. It might take months until everyone has enough time to focus on this low-priority task. This might prevent you from removing the old package and cause issues.
When your change requires an action, you need your communication to be thoroughly planned.
To do that, you can use the ADKAR framework. It consists of five key stages: “Awareness”, “Desire”, “Knowledge”, “Ability”, and “Reinforcement”.
We already focused on awareness and over-communicating change to reach everyone on the team. If you want people to introduce changes, you need to focus on their desire. You have to convince them that the change is important and will affect them positively. Think about benefits, risks, and how it aligns with business goals.
You need to make sure that they have all the necessary knowledge to perform the change. This can be shared through documentation that everyone can easily consult when introducing those changes.
Ability - you also need to ensure that the teams are able to introduce the change. This might require you to talk to leaders and ensure that it won’t conflict with their other plans. Provide support if it’s required.
Reinforcement - this step uses rewards, feedback, and support to avoid returning to old habits. For introducing a change in a codebase, deprecation or automatic checks can be enough to avoid it. Celebrate milestones for completed actions to give a sense of progress.
Summary
Introducing complex changes is never easy. Even if you do it right, information might not reach everyone on the team. The key is to overcommunicate the changes and use different channels. It’s even more challenging if you want people to introduce the change. This requires some more preparation to ensure that the change is introduced properly and to avoid returning to the previous state.