They have frameworks, templates, toolkits, playbooks, maturity models and SharePoint sites containing enough good practice to run several medium-sized countries.
And yet, when something difficult happens, people often revert to whatever they did before.
That is the problem with methodology.
Knowing that a good practice exists is not the same as having it available when you need it.
For change capability to become genuinely organisational, the methodology has to make a rather difficult journey.
It has to stop being something people remember to consult and become something they instinctively do.
The real test comes when nobody says "change management"
In the Change Management Hub I have been developing, I use a fairly simple sequence:
Map before diagnosing. Diagnose before acting.
Understand who is affected and how.
Separate evidence from assumption.
Then decide what might help.
There is nothing especially complicated about that.
The difficult bit is remembering to do it when a project is late, somebody wants an answer by Friday and a meeting has already concluded that the problem is "resistance".
At that point, nobody is likely to announce:
"Before we continue, shall we consult our change management methodology?"
What I would rather hear is:
"Hang on. Do we actually know that's the problem?"
That's the shift I'm interested in.
The methodology has disappeared from view, but the thinking has survived.
Perhaps that is what organisational capability looks like.
We often mistake distribution for adoption
There is a familiar pattern when organisations try to build capability.
Create the toolkit.
Publish the guidance.
Run the workshop.
Send the email.
Perhaps hold a launch event.
Then measure attendance, page views or completion rates and hope something has happened.
I've done versions of this myself.
Those activities matter. People cannot use something they have never encountered.
But distribution is only the beginning.
A hundred people attending change training tells me that a hundred people attended change training.
It does not tell me what happens six weeks later when one of them is sitting in a project meeting and someone says:
"Users just don't like the new system."
Do they accept that explanation?
Or do they ask:
What else could be true?
That second response interests me far more than the training statistics.
From explicit knowledge to tacit behaviour
There is an old distinction in organisational learning between what we can explicitly describe and what we simply know how to do.
Learning to drive is an obvious example.
At first, everything is conscious.
Mirror. Signal. Manoeuvre.
Clutch. Gear. Accelerator.
Eventually, if all goes well, you stop conducting a small committee meeting in your head every time you approach a roundabout.
The knowledge hasn't disappeared.
It has become embedded in behaviour.
Organisational capability needs something similar.
At first, someone may consciously use an impact assessment.
Later, they simply remember to ask whose work is changing.
At first, they may work through a diagnostic model.
Later, they instinctively distinguish between someone who doesn't understand a change, someone who cannot perform it, someone who disagrees with it and someone who simply has no capacity left.
The framework becomes scaffolding.
You need it while the structure is being built.
You probably don't want to live in it permanently.
This is why simplicity matters
Professional disciplines have a tendency to grow.
We discover nuance, so we add a category.
We encounter an exception, so we add guidance.
Someone asks for assurance, so we add a field.
Before long, the elegant three-page toolkit has become a 74-page operating manual and requires its own induction course.
There is good reason for depth. Specialists need it.
But if we want ideas to travel beyond specialists, they also need to be compressible.
That is one reason I like simple questions.
Who is actually affected?
What do we know and what are we assuming?
What else could be true?
Is this an issue of understanding, capability, commitment or capacity?
How will we know whether our intervention worked?
Those questions can travel.
Nobody needs to remember which page of the handbook they came from.
And that matters because organisational capability is partly about making useful thinking portable.
But habits don't form in a vacuum
This is where the argument gets slightly more difficult.
It is tempting to think that if we simply train people properly, good habits will follow.
They won't necessarily.
People behave within systems.
Imagine I train a project manager to think carefully about change impact, then put them into a governance process that asks exclusively about cost, schedule and deliverables.
What lesson will the organisation actually reinforce?
Imagine we encourage experimentation, but every unsuccessful experiment requires an explanation to three committees.
Imagine we ask managers to involve people early, while measuring them primarily on how quickly they implement the decision.
The formal methodology may say one thing.
The organisation may be teaching something completely different.
Culture is partly what gets reinforced when the methodology isn't looking.
That is why change capability cannot be created by the change function alone.
Governance, leadership behaviour, performance measures, project methods and everyday management practice all either reinforce the habit or slowly extinguish it.
Put the thinking where the work happens
If I were trying to build organisational change capability from scratch, I would therefore spend less time trying to persuade people to visit a change methodology and more time putting change thinking into places they already visit.
Project initiation.
Business cases.
Governance boards.
Risk discussions.
Service design.
Benefits reviews.
Team meetings.
Lessons learned.
The question isn't simply:
"How do we get people to use our change tools?"
It is:
"Where are decisions being made where this way of thinking would improve the decision?"
Then put it there.
If a project board routinely asks who is affected and how adoption will be measured, that question eventually stops feeling like "change management".
It becomes part of running a project properly.
If managers routinely ask about capacity before adding another priority, capacity becomes something the organisation sees.
If teams routinely distinguish evidence from assumption, they gradually become less comfortable making confident decisions from guesswork.
Small repeated questions can alter the operating system.
This also explains why cultural bridges matter
In my earlier MBA research into organisational absorptive capacity, I became interested in the way knowledge moves between different organisational groups.
Two departments can both be competent and still struggle to use each other's expertise.
They may use different language.
Value different evidence.
Work to different rhythms.
Even understand the same problem differently.
What helps is some kind of cultural bridge.
I think the same principle applies to change capability.
A central change team may develop excellent practice. That doesn't mean the rest of the organisation will absorb it.
Someone has to translate.
What does stakeholder impact mean to a project manager?
What does adoption mean to a service manager?
What does capacity mean to a finance director?
What does psychological safety mean in a governance meeting?
The underlying idea can remain the same while the language changes.
That isn't dilution.
It is how ideas travel.
Communities may matter more than classrooms
This is also why I increasingly think capability-building needs to continue after formal learning.
Training gives people a starting point.
Practice makes the knowledge usable.
Conversation helps it evolve.
People need somewhere to bring awkward examples:
"I tried this and it didn't work."
"I'm not sure whether this is resistance or something else."
"How would you handle this stakeholder?"
"We did everything the methodology said and adoption is still poor."
Those conversations are gold.
They turn static methodology into living practice.
They also allow people to learn horizontally rather than waiting for expertise to be dispensed from the centre.
That is where communities of practice, peer support, coaching and informal networks start to matter.
Capability spreads socially.
Humans have always learned rather well by watching what other humans get away with.
Leadership still matters, unfortunately
There is no getting around this bit.
Leaders shape habits through what they repeatedly ask about.
If the only questions are:
"Are we on time?"
"Are we on budget?"
"When does it go live?"
then people learn what matters.
If leaders also ask:
"Are people actually ready?"
"What are we assuming?"
"Who experiences this differently?"
"What have we learned?"
then those things start to matter too.
Leadership support for change capability doesn't necessarily mean sponsoring a Change Academy or appearing in a launch video.
Sometimes it is simply asking better questions, consistently enough that everyone starts preparing for them.
That is culture being made in real time.
The goal is not perfect compliance
There is a danger here too.
Once organisations decide something should become standard practice, they can become very good at turning it into compliance.
Then the helpful question becomes a mandatory field.
The mandatory field becomes a drop-down.
And eventually someone discovers that selecting "N/A" makes the form submit.
We have achieved process maturity.
Capability is different.
I don't particularly care whether somebody can name the model they are using.
I care whether they can see the situation more clearly because of it.
The measure of success isn't methodological purity.
It is better judgement.
Eventually, the methodology should become harder to see
This is the paradox.
When change capability is immature, you see the methodology everywhere.
Templates.
Models.
Training.
Workshops.
Guidance.
Specialists.
As capability matures, some of that may become less visible.
Not because it has been abandoned.
Because it has been absorbed.
People naturally consider impact.
Managers naturally think about capacity.
Projects naturally consider adoption.
Teams naturally challenge assumptions.
People experiment, learn and adjust without needing permission to describe the process as "change management".
The methodology hasn't disappeared.
It has become habit.
And perhaps that is the point at which change capability genuinely belongs to the organisation rather than to the people whose job titles contain the word change.
Which raises an obvious practical question.
If we wanted to deliberately build those habits, rather than simply hope they emerge, what would we actually teach?
That is where I think a Change Academy becomes interesting.
Comments
Post a Comment