The leadership team has made a decision. A new system, a restructure, a change in direction, a different way of operating. The case for it is clear. The plan is sound. And somewhere in the organisation, a group of people who were not part of that decision are about to be asked to change how they work.
How that moment is handled determines more about the outcome than almost anything else in the project.
Change management is one of the most consistently underfunded and underestimated parts of any transformation program. It is also one of the most consequential. Organisations that get it right get faster adoption, fewer workarounds, and better outcomes from the change itself. Organisations that get it wrong spend years managing the gap between how the new thing was supposed to work and how people are actually using it.
Here is what works.
Start earlier than feels necessary
The most common change management mistake is starting too late. The system is configured, the new process is designed, the go-live date is set, and then someone remembers that the team needs to be told.
By that point, the decisions have been made. The people who will be most affected have had no input. The change arrives as a fait accompli, which is the fastest way to generate resistance regardless of how good the change actually is.
People do not resist change as a rule. They resist being changed. The distinction matters. Involvement in the design of a change, even when the fundamental decision has already been made, significantly increases the likelihood of genuine adoption.
Start the change management process when the design process starts. Not when the design is finished.
Be honest about why
One of the most reliable ways to erode trust in a change program is to frame the change in a way that does not ring true to the people experiencing it.
Restructures that are primarily about cost reduction get announced as "aligning the organisation to the strategy." New systems that are partly about reducing headcount get described as "empowering the team." People are not naive, and when the official explanation does not match what they can see, confidence in leadership takes a hit that is hard to recover.
Be honest about why the change is happening. If it is partly about cost, say so. If it creates uncertainty about roles, acknowledge that. The honest version is almost always more palatable than the managed version, because it treats people as adults and because it does not require maintaining a narrative that the team does not believe.
What people need to hear is not a positive spin. It is a clear explanation of what is changing, why it is changing, what it means for them specifically, and what happens next.
Make the WIIFM explicit
Every person affected by a change is asking some version of the same question: what does this mean for me?
That question needs to be answered at the individual level, not just at the organisational level. The business case for the change might be compelling. That does not mean it is obvious to the person whose job is about to look different how they personally benefit, or whether they have a place in the new model at all.
Think through the change from the perspective of each affected group. What are they being asked to give up? What are they gaining? What concerns are they likely to have that have not been addressed? Then address those things directly, before people have to ask.
The concerns that go unaddressed do not go away. They become resistance, rumour and disengagement.
Create genuine two-way communication
Change communications are usually one-directional. Town halls where leadership presents the change. Emails that explain it. FAQ documents that answer the questions leadership anticipated.
What is missing is a structured way for the people experiencing the change to feed back what they are finding. What is not working. What was not anticipated in the design. What is creating friction that is not in the plan.
This feedback is not just good for morale. It is operationally valuable. The people closest to the work see things that the design team did not. The early issues that surface through a functioning feedback loop can be addressed before they become embedded. The ones that are not surfaced become permanent workarounds.
Build the feedback mechanism in from the start. Name who is responsible for receiving and acting on it. And when feedback leads to a change, say so, and say who raised it.
Sustain attention past go-live
Change programs that are funded and staffed for the delivery phase and then wound down at go-live consistently underperform. The period immediately after a change goes live is when the real work of adoption happens, and it is when the team most needs support.
Habits take time to change. The new way of working will feel slower and less natural than the old way for weeks, sometimes months. Without sustained support, people drift back to the familiar. The change technically happened but the behaviour did not follow.
Treat the period after go-live as a phase of the project, not as a sign-off. Keep dedicated resource in place for longer than feels necessary. Measure adoption, not just completion. And be prepared to intervene when the data shows that the change is not sticking in the way it was expected to.
The leader's role
None of this works if the leaders closest to the change are not genuinely behind it. Not publicly supportive in a managed way. Genuinely behind it, in the conversations they have in the corridor, in how they respond when someone raises a problem, in whether they are using the new system or the new process themselves.
People watch their managers more than they listen to their communications. If the manager is using a workaround, the team will use a workaround. If the manager is visibly engaged with the change and honest about its difficulties, the team will follow.
The most important investment in any change program is making sure the people leading it are equipped and genuinely committed. That is not a communication task. It is a leadership task.