Leading change is rarely about having the best idea on the slide. It is about turning a decision into new behaviour, in the right order, with enough trust behind it to survive the awkward middle. This article shows how to make change happen in a practical way: how to frame the case, build support, communicate clearly, and keep the new way of working alive after the launch.
The change moves when people can see the problem, trust the leaders, and practise the new behaviour fast
- Start with a problem statement, not a solution you have already chosen.
- Keep the sponsor group small, visible, and consistent.
- Repeat the message in manager, team, and one-to-one layers.
- Remove friction before asking people to change habits.
- Track adoption with 3 to 5 real metrics, not attendance alone.
- In UK workplaces, consult early if contracts, roles, or redundancies may be affected.
Start with the problem you are actually solving
I start every change conversation by stripping away the solution and looking at the business problem underneath it. If the issue is unclear, the rollout becomes a bundle of assumptions, and people sense that immediately. A sharper starting point might be: customer complaints are rising, managers are spending too much time on manual work, or the current process creates delays that affect revenue and morale.
That matters because change fails when it tries to solve five things at once. A new system can improve reporting, but if the real pain is slow approval, training alone will not fix it. A strong change case does three things: it defines the pain, names the risk of doing nothing, and shows what better looks like in plain language.
When I help teams shape the case, I ask them to write down three answers before they announce anything: what is broken, why now, and what will be different if the change works. That discipline keeps the plan from drifting into vague ambition. Once the problem is specific, the next task is to build the people group that can carry it.
Build the internal coalition before the announcement
The most common mistake I see is this: one leader approves the change, then expects the rest of the organisation to absorb it automatically. In practice, change needs a coalition, not just a sponsor. At minimum, I want a senior sponsor, the line managers who translate the message into daily work, and a small number of practical sceptics who can tell you where the plan is weak.
That last group is important. If nobody is pushing back, you probably have not stress-tested the change enough. A sceptic who is respected by peers can surface the awkward questions early: Will this create more admin? Does it clash with current incentives? Can teams actually use it with the time they have?
| Role | What I expect from them | What goes wrong if they are missing |
|---|---|---|
| Senior sponsor | Visible backing, decisions, and momentum | The change looks optional |
| Line managers | Translate the change into team behaviour | People hear the message but do not know what to do next |
| Front-line experts | Reality check on the process and workload | The plan looks neat on paper and fails in practice |
| Practical sceptics | Challenge assumptions before launch | Problems are discovered after the rollout has begun |
I prefer a small coalition that meets regularly over a large committee that approves things slowly. Four to six active people is often enough for a medium change initiative. With that group in place, communication becomes precise rather than theatrical.
Communicate the change in repeatable layers
One announcement is not communication; it is a spark. People usually need to hear the same change in at least three layers before it feels real: the strategic reason, the practical impact, and the local action they need to take this week. If those layers are missing, employees fill the gap with their own assumptions, and those assumptions are often worse than the truth.
My rule of thumb is simple. The first layer answers why now. The second answers what changes and what stays the same. The third answers what I do next. If people cannot repeat those three things after the briefing, the message is still too abstract.
- Lead with the business problem, not the organisational jargon.
- Say what will change for teams, not just what will change for the company.
- Repeat the message through managers, not only through leadership emails.
- Give people one action to take in the next 7 days.
In 2026, most organisations are dealing with overlapping changes, so clarity matters more than ever. If the message sounds polished but does not answer basic questions, people will assume the plan is either incomplete or temporary. Even good communication fails if the new behaviour is too hard to adopt, and that is where resistance starts to matter.
Make resistance smaller by design
I do not treat resistance as sabotage. Most of the time it is information. People push back because they do not understand the purpose, they fear losing something valuable, they do not have the skill yet, or the new workflow adds friction without removing anything old.
That means the job is not to “overcome resistance” with slogans. The job is to reduce the cost of participation. If the new process saves time, show exactly how. If it introduces uncertainty, explain what support exists. If people are worried about status or control, say so directly instead of hiding behind upbeat language.
| What resistance often means | Better leader move |
|---|---|
| “I do not see the point.” | Explain the problem the change solves and the cost of doing nothing. |
| “This will create more work.” | Remove one old task, automate one manual step, or phase the rollout. |
| “I am not confident using it.” | Use short training, job aids, and manager coaching instead of a one-off workshop. |
| “We have seen this before.” | Show visible follow-through and publish early wins quickly. |
There is also a useful distinction between agreement and adoption. People can agree in principle and still not change how they work on Monday morning. If everyone nods but nothing moves, you do not have buy-in; you have politeness. That is why the rollout needs a rhythm, not a single launch date.
Use a 30-60-90 day rollout rhythm
For most team or function-level changes, I prefer a 30-60-90 day rhythm because it forces discipline without making the plan rigid. The first month is for alignment and readiness. The second month is for controlled testing. The third month is for scaling what works and removing what does not.
| Phase | Focus | What I would do | What success looks like |
|---|---|---|---|
| Days 1-30 | Prepare | Define the scope, assign owners, brief managers, build FAQs, set a baseline | People can explain the change in plain language |
| Days 31-60 | Pilot | Test with one or two teams, collect friction, revise training, fix workflow issues | The process works with real users, not just in meetings |
| Days 61-90 | Embed | Scale the change, publish wins, coach managers, and make the new steps part of normal routines | The change shows up in day-to-day behaviour without constant prompting |
If you cannot pilot, phase the rollout by site, team, customer group, or workflow. I would rather launch to 20 percent well than to 100 percent badly. The point is not speed for its own sake; the point is learning fast enough to avoid expensive mistakes. A rollout only matters if you can see whether people are actually using it, and that is the next layer.
Measure adoption, not just activity
Attendance at a workshop is an activity measure. Adoption is different. Adoption tells you whether the new behaviour is being used, whether it is creating the expected result, and whether the old habit is still quietly winning in the background.
My preference is to use one leading indicator and one outcome indicator for each change. For example, if the change is a new approval process, I might track the percentage of requests following the new path and the average time to approval. If the change is a new client workflow, I might track usage in the first week and the rework rate a month later.
- Usage rate: how often the new process is being used.
- Cycle time: whether the new way is faster or slower than before.
- Error or rework rate: whether quality improved or slipped.
- Manager coaching rate: whether leaders are reinforcing the new behaviour.
- Pulse feedback: whether people feel clearer, more capable, and less blocked.
I also look for one sign people often ignore: whether the change survives when the project team stops asking about it. If the behaviour drops as soon as the reminders stop, the change has not been embedded. In the UK, that measurement stage still sits inside a wider legal and cultural frame, especially when people’s roles are affected.
What UK leaders should handle before the first announcement
For a UK audience, this part is not optional. If the change affects contracts, working patterns, restructures, or redundancies, consultation should happen early and genuinely. Acas is clear that consultation should be a real two-way discussion before final decisions are made, not a box-ticking exercise after the plan is already fixed.
That point matters because trust is easier to preserve than to rebuild. If employees feel the decision was done to them rather than with them, even a sensible change can become emotionally expensive. If the change could lead to 20 or more redundancies at one establishment within 90 days, collective consultation duties may also apply, so timing and documentation matter as much as messaging.
- Check whether the change touches contracts, hours, pay, location, or role design.
- Consult before final decisions wherever consultation is required.
- Include affected employees who are absent or on leave, and make communication accessible.
- Prepare managers, because they will answer the hardest questions locally.
- Keep records of what was shared, what feedback was received, and what changed as a result.
I would rather delay a launch by a week than rush consultation and spend months repairing trust. Once the legal and human basics are right, the final job is to lock the change into everyday work.
The middle is where change becomes a habit
The first week creates attention; the next eight weeks create memory. If you want the new behaviour to stick, keep leaders visible, keep the workflow simple, and keep removing small points of friction before they become excuses.
My test is straightforward: if the change only survives when the project team is watching, it is not embedded yet. When line managers use it naturally, when the metrics move in the right direction, and when people no longer need the rules explained twice, the organisation has started to own the change rather than merely comply with it.
