Change Management

Failed changes are routinely explained by resistance, which locates the problem in the people being changed. It is more often a design failure.

Ask someone in a stalled change what they are meant to do differently on Monday, and the answer is frequently vague. They have heard the announcement, understood the direction, and cannot say which of their actual tasks changes.

That is not resistance. It is a change that was communicated at the level of intent and never translated into behaviour.

The corrective is specificity per role. Not that the organisation is becoming more data-driven, but that this team will now record the reason for each rejection in this field, and that the weekly review will use that data instead of the spreadsheet. People adopt things they can picture themselves doing.

A change is adopted or ignored in the daily conversations between people and their immediate managers, not in the all-hands or the intranet post.

A manager who visibly uses the new process, asks about it, and treats it as how things are done now will get adoption in their team. One who describes it as something head office wants, or who quietly permits the old way, will not, regardless of what has been communicated centrally.

• Brief managers first, and far enough ahead that they are not hearing it with their teams.
• Give them the answer to the questions they will be asked, including the uncomfortable ones about jobs and workload.
• Let them raise objections before launch, when the objections can still change something.
• Check adoption by team rather than in aggregate, since a good overall number usually conceals two teams doing it and four not.

The third is where most programmes go wrong. A manager who is briefed at the same time as their team, and who has not been persuaded, will pass on their own scepticism whatever the script says.

People accept difficult changes when the reason is comprehensible, and construct a reason when it is not.

The reason they construct is almost always cost-cutting, and often headcount reduction, because that is the most available explanation for an unexplained change. If the change genuinely is about cost, saying so is better than the alternative, since employees who suspect it and are told something else stop believing the rest of the communication too.

Where the reason is real and complicated, it survives being explained. Where the explanation is a slogan, it does not, and a change justified by a phrase about agility or customer centricity will be read as having no reason at all.

What works is concrete: this is what is going wrong now, this is what it costs us, this is what we expect to be different. That can be argued with, which is a feature rather than a problem, because a change nobody can argue with is one nobody has engaged with.

Organisations frequently run consultation on decisions that have been made, and employees identify this immediately.

The damage is not the decision but the pretence. A workforce told their input matters, who then see the original plan implemented unchanged, learns that consultation is theatre. The next genuine consultation gets no participation, which is a real loss.

The middle row is the most common real situation and the least often stated. Being explicit about which parts are settled costs nothing and preserves credibility for the parts that are not.

Where a change affects conditions of service, consultation may also carry statutory requirements, including the notice obligation under section 40 of the Industrial Relations Code for changes to matters specified in its Third Schedule, which is dealt with in conditions-of-employment-meaning.

The most common reason a change never completes is that both ways remain available.

The new system is launched and the old spreadsheet still works. The new process is announced and the old form is still accepted. People under pressure revert to what they know, which is entirely rational, and the change stalls at partial adoption indefinitely.

• Set a date after which the old way stops working, and hold it.
• Make the new way at least as easy as the old one before switching, because a change that makes work harder will not survive contact with a busy week.
• Support the transition heavily and briefly rather than lightly and forever.
• Measure actual usage rather than reported adoption, since these differ substantially.
• Fix the things people complain about in the first weeks, which is when the fixes are cheapest and most visible.

Partial adoption is the worst outcome available. It carries the full cost of the change, delivers a fraction of the benefit, and leaves the organisation maintaining two ways of working indefinitely.