There is no Change Resistance, only Badly Designed Change

Whenever a transformation struggles, the diagnosis arrives remarkably quickly: “People are resisting the change.”

I have always found the word resistance quite exaggerated in this context. As a Frenchman, Resistance has a rather particular meaning for me. My grandfather wrote a book about the Resistance years: Capitaine Dollé, un jeune chef, 250 volontaires, leur résistance * — the cover picture of this post. He was among those 250 after returning from captivity in Colditz. That was resistance in the proper sense of the word: sabotaging an occupying force, disrupting its plans, refusing to let it establish itself, hiding and saving people from deportation, and preparing for the day when liberation would come.

Working in change, that is not the reaction I usually see in organisations — and, surely enough, I do not aim to design my interventions as an invading force. I never see employees actively trying to sabotage a transformation, although they may struggle with adoption. There is no underground movement hiding the Kanban cards, and nobody is waiting for a D-Day to restore everything to the way it used to be. Most people accept that their organisation needs to evolve, especially as technology increases the complexity and pace of business.

What we usually call resistance is much less dramatic: it is inertia.

And anything with mass has inertia, including organisations. The bigger the organisation, the more inertia there is.

Calling inertia “resistance” also reveals something about the bias of the change-maker, or of the programme initiating the change. It assumes people will make the change their focus. But organisations are not fully dedicated to change work. They still have a business to run. How well that tension is recognised and designed for largely determines the inertia that follows.

 When the answer is always more force

The instinct when change is difficult is often to increase the force: more communications, more training, more targets, more consultants, more dashboards, and eventually some mandates and, if necessary, threats. The assumption is that if the organisation is not moving quickly enough, we are simply not applying enough pressure.

The larger the organisation, the larger the transformation tends to become — and the greater the inertia. It may have taken years to convince everyone that change was needed and secure the budget, so once approval arrives, there is enormous pressure to get it done everywhere, at once, and with urgency.

The problem is that the change has already taken the path of maximum inertia, while expectations are set for maximum expediency.

 When the method becomes the goal

Pressure to create visible progress often turns the proposed method or practice into the objective: adopting Agile ways of working, deploying AI, implementing an operating model, achieving a maturity score.

The original conversation normally starts with a business problem. We need to respond faster, reduce cost, improve productivity or serve customers better. Then a method is introduced to help, and somewhere along the way the method takes over.

The means quietly becomes the end.

You can usually see this in the measures. Organisations start tracking adoption of practices instead of the business performance those practices were intended to improve.

When the method becomes the objective, the theatre of change starts to matter more than the value of change.

The way we resource transformation reinforces this tendency. Large change programmes naturally create demand for dedicated enabling teams, workstreams, consultants, coaches and delivery structures. Consultancies, quite understandably, are also designed around selling capacity, methods and teams of people. Procurement is generally set up to buy temporary headcount or full-time equivalents.

The result is that change becomes something that can be commissioned, staffed and delivered as a project.

And once someone is brought in full-time to “own” the transformation, it becomes remarkably easy for the existing leadership to hand over responsibility. The external or temporary expert becomes the authority, while the leaders responsible for the day-to-day continue running the business as before.

That may be convenient for delivering a programme. It is much less effective for establishing ownership.

This does not make consultants the problem. It means the prevailing model of consulting and procurement carries its own bias towards solution-led, method-led and project-led change, which in turn creates the conditions for leadership to abdicate responsibility for the change.

 Scale the scope, not just the coverage

A second problem is our instinct to scale by standardising practices across the organisation rather than recognising that practices need to fit their context.

Methods rarely work in isolation. Agile does not automatically create enterprise agility, just as deploying AI does not automatically create a more productive business. Practices have to connect with the broader system that produces the desired outcome.

When we chase coverage, we aim to roll out a practice universally and in isolation. Instead, we should accept that coverage will take time and focus on the systemic scope in which that practice needs to operate.

That means dealing with its implications across leadership, governance, incentives, decision-making, data, roles and surrounding ways of working.

Scope of change matters more than speed of coverage. Rush the latter and the former becomes incongruent. Inertia follows.

During many Agile transformations, technology teams changed how they worked while finance, governance, budgeting and project approval continued exactly as before. The teams had changed, but the system had not. The result was Agile ways of working with remarkably little gain in business agility.

It was never the people resisting the change. The system created the inertia. And, well, AI is being guided by much the same change-management approach. Say no more.

 Real change is compound

Introducing continuous improvement, for example, may require different meetings, new visual management, better performance data, different problem-solving practices, different conversations and different leadership behaviours.

None of these things matters much in isolation. A beautiful performance board without a meaningful conversation around it is about as useful as a chocolate teapot.**

This is why asymmetric change behaves a little like an elastic band. Change one element while leaving everything else untouched, and the surrounding system pulls it back towards its previous state. The larger the asymmetry, the harder it snaps back.

Yet much of what organisations call “scaling” is exactly that: changing one practice widely while leaving the rest of the operating system untouched.

Change one part of the system and leave everything else alone, and the system will pull it back into place.

When adoption disappoints, the response is often to push harder through mandates, communications, incentives or escalation. But people are not resisting because they are Capitaine Dollé or his volunteers. They can only do so much while still running the business.

Customers still call. Reporting deadlines still exist. Regulatory obligations remain. Leaders still expect the old reports, and governance still operates according to the old rhythm. Most people's bandwidth was already largely consumed before the transformation arrived.

Change therefore needs to be systemically coherent, which is almost impossible to achieve in one move. This is where traditional approaches to scaling change start to break down. The answer is not to force a complete future model through the organisation. It is to progress the change and its implications through coherent, scoped increments.

Change should be less of a big overhaul project and more of a sequence of small, connected steps that learn, adjust and embed as they progress.

 Design change around the work

So what would better-designed change look like?

First, start with the work rather than the training. I recently worked with the operations function of a fund to develop a continuous-improvement culture, and we did remarkably little formal training. That was deliberate.

Training could easily have become a reason not to start, especially with very busy professionals: “I haven't done the course yet.”

Instead, we began with real problems. Most teams already know where many of their problems are, and with some structured problem-solving they can usually begin making useful progress immediately. It also had the side benefit of building confidence, as people saw the value of their own agency in solving problems and improving the work.

Then, train at the point of need. People forget much of the training they attend, particularly when they cannot apply it straight away. Capability is better developed as the change becomes more sophisticated: introduce a tool when the team has a problem that requires it, teach a technique when someone can use it tomorrow, and make the learning relevant to the situation people are actually facing.

That means replacing mass training programmes with practical journeys that teams can progress through at a pace their circumstances allow. Make one step of progress, stabilise it, and build from that new foundation.

Last but not least, guide progress through value rather than maturity. The guiding beacon should always remain better business performance; the change happens by stealth. During the Agile wave, many organisations measured adoption through practice assessments. Some were never particularly clear about what they wanted agility for in the first place; in some cases, they simply wanted cheaper technology. I am not sure they got either.

Once the method becomes the objective, transformation creates its own parallel organisation. Consultants, coaches and transformation leaders govern the work differently from the leaders who still have to run the business day-to-day.

Eventually something important needs to get done, or a crisis happens, and the real governance of the business almost always trumps the transformation governance. The change and the business start working against each other when the original intention was to bring them together.

“Resistance” often appears because the design of the change is dissonant with the way the business actually runs.

 There is more than one way to scale

Scaling is also part of the problem. Most organisations have only one mental model of scale: make everybody do the same thing through one coordinated intervention.

But teams have different problems, skills, customers, constraints and positions in the value chain. Even where a common direction makes sense, the route towards it may be different.

The regimented approach is often designed for the convenience of the change organisation more than for the convenience of the people adopting the change. And then we have the cheek to blame resistance…

There are other ways to create scale.

One is through leadership. Leaders are already responsible for organising teams, making work flow, realising strategic ambitions and assuring execution. Instead of bypassing that system with a transformation programme, change can be driven through it.

Leaders remain responsible for the last mile: helping teams interpret the change, stretching the boundaries of the day-to-day, removing contradictions and improving the work incrementally.

Another approach is to scale through experimentation and repetition. Start with a few “lighthouse” teams, learn what works, stabilise the approach and bring the next teams on at a cadence. The first teams progress to the next stage while new teams follow a path that has already been tested.

This also works with the real constraint in most organisations: time. Start where there is enough headroom to pay attention to the change, and plan ahead for the teams that will come next.

Both approaches create contextual learning that can be passed from leader to leader, or from pioneering teams to those following them. If part of the ambition is to create a learning organisation, then the way the change is introduced should model that behaviour from day one.

Start as you mean to go on.

 “Resistance” is a signal

Perhaps the most useful shift is to stop treating resistance as a behaviour to eliminate. Good change will never come from blind obedience.

Treat “resistance” instead as a signal that the change is incongruent with the conditions in which people are being asked to adopt it.

• Maybe the timing is wrong. The team is already at capacity and adding more work will simply overload it. Change does not have to move linearly or synchronously across every team. Adapt to the team's conditions.

• Maybe the team is drowning in disruptive demand: incidents, dependencies, late requests and operational firefighting. Before it can absorb transformation, it may need to regain some headroom. In that case, the first step of change is to improve the day-to-day and create capacity. Better still, solving that disruptive demand may itself begin implementing the change. Real problems can become the vehicle for adoption.

• Maybe the proposed change feels meaningless because the team cannot see how it connects to its work. More town halls, posters and communications will not solve that. Contextualisation might. Engage the team in the outcome and help people understand their role in producing it.

• Or maybe the organisation says one thing while direct authority demands another. Enterprises are full of these paradoxes. Resolving them is part of the change, not an inconvenience surrounding it.

If people are not adopting the change, ask what the resistance is telling you about the system — and start solving it.

Does the change make their work better? Does the surrounding governance support it? Have the interdependent practices changed? Do people have enough headroom to think about it? Can they see the value? Is the increment simply too large or too vague?

Quite often, what gets described as resistance is simply people rejecting the scope or pace of change while trying to keep the business functioning.

Bulldozing harder usually makes things worse. You end up with a Frankenstein operating model: some new practices, some old governance, some mandatory artefacts and, most visibly of all, more bureaucracy and more meetings.

 Start from today, not from the imagined future

Better change starts with extreme clarity about the present and directional clarity about what needs to shift strategically. Progress is then made iteratively, pushing the boundary a little further each time — very much in the spirit of Toyota Kata.

The destination can remain emergent. What matters is that teams progressively build both the capability and the space to change while improving their day-to-day work.

This is very different from the classical approach to transformation, which tends to start with a future state and then construct a deployment plan to reach it. Once change is framed as a project, the method tends to take over, and the transformation has already stepped off on the wrong foot.

Bring teams, practices, artefacts and leadership forward together. Do not begin with a perfectly specified future state and organise a grand march towards it. Begin with today's work, improve it, learn, and then take the next step.

When people are involved in designing meaningful improvements to their own work, there is remarkably little “resistance”. People tend to lean in when they can see the value and have some ownership of the solution.

This also means rethinking the support model. If change is continuous, it makes little economic sense to sustain it through full-time external support. The capability has to embed in the organisation itself.

In the approach I promote, the aim is to reduce external effort over successive cycles as the existing leadership takes more of the space that external support was initially helping to create. The leadership leans in when the support leans out. The change embeds as it progresses.

Over time, the external role should become lighter: less about driving the change, more about providing challenge, perspective and a critical eye. That is a better sign of progress than maintaining a permanent transformation structure.

Good external support should, by design, progressively make itself less necessary.

 

Conclusion

Wherever the inertia of progress is being blamed on resistance, how about exploring what sits behind it? Is it really resistance — or is the system telling you something about the way the change has been designed?

The change approach itself may need to change. Time for change management to change.

If you want to challenge your current approach to change, or design change in more effective increments, please get in touch.

Philippe Guenet

Henko - Performance through Leadership.

www.henko.co.uk

 * Capitaine Dollé, un jeune chef, 250 volontaires, leur résistance: “Captain Dollé, a young leader, 250 volunteers, their resistance.”

** As a French person, it took me some time to understand this expression, so I thought I would explain it here. A “chocolate teapot” is a British expression for something that may technically exist but is useless for its intended purpose: pour hot tea into a teapot made of chocolate, and the problem quickly becomes obvious.