The intervention itself needs a system

There is a seductive version of organisational change. You find the problem. You map the better system. You explain it clearly. Everybody agrees it is better. The organisation changes. I used to believe in more of that sequence than I do now. A good diagnosis is useful. A technically better system is useful. Neither implements itself.

Being right is not a change strategy

This is particularly easy to miss if your job rewards diagnosis. You notice a recurring problem. You can see why it happens. You design something that should work better. The logic is sound. Why would anybody resist it? Plenty of reasons. The problem is not painful to them. The current system rewards them. The change creates work before it creates benefit.

They do not trust the person proposing it. They agree with the destination but not the timing. They have a different view of what is actually causing the problem. They do not have authority. They do have authority and do not want the political cost. They have seen six previous transformations arrive with a deck and leave with a folder.

The quality of the technical answer matters. It is only half the work.

Organisations do not share one point of view

A system looks different depending on where you stand. Sales sees opportunity. Delivery sees commitment. Finance sees margin. Creative sees the brief. Leadership sees growth. The customer sees whether the thing arrived. All of them can describe the same project accurately and still disagree about what is happening. That matters when you try to change it.

If I present the delivery team's diagnosis as though it is objective truth, Sales may hear an accusation. If Finance presents cost control without understanding the production mechanism, the creative team may hear "do the same work with less". If leadership announces accountability without changing authority, managers hear responsibility for outcomes they still cannot control.

Before designing the future state, you need to understand the current set of viewpoints. Not because everybody needs to agree. Because the intervention has to survive contact with them.

Map interests as well as process

A workflow map tells you how work moves. A stakeholder map tells you how change moves. They are not the same thing. For each important stakeholder, I want to know: What do they think the problem is? What do they want? What are they measured on? What do they stand to lose? What authority do they actually have? What are they already tired of?

Which part of the proposed change makes their life better? Which part makes it worse? That is not cynical. It is basic operating reality. People do not become irrational merely because a transformation programme exists. They remain people with jobs, incentives, histories and finite attention.

Agreement on the diagnosis comes before agreement on the solution

One of the more useful changes in how I work is spending longer on the diagnosis as a shared object. Not merely: "Here is what I think is wrong." Instead: "Here is what several teams say is happening." "Here is what the work shows." "Here is what the commercial data suggests." "Here is where those accounts disagree." "Here is the mechanism I think connects them."

That gives people something to inspect. They can challenge the evidence. Correct the map. Add a dependency. Point out a political constraint. The diagnosis gets stronger, but something else happens too. Ownership begins before the solution is final. The change is less likely to arrive as somebody else's system.

Prototype the argument

Organisational ideas are hard to discuss in the abstract. A new operating model. Better accountability. A clearer workflow. A leadership layer. Everyone can agree with the words and imagine a different thing. So make it visible. A workflow. A small dashboard. A role map. A prototype. A decision log. A live pilot. A reconstructed current-state diagram.

Something people can point at. Visible things create better disagreement. "This arrow is wrong" is more useful than "I am not sure the model reflects our culture". The prototype is not merely a design aid. It is part of the change process.

Coalition is not a dirty word

There is a version of organisational politics where "political" means manipulative. There is another where it simply means understanding that authority and influence are distributed. Large changes rarely happen because one person made a compelling argument in the right meeting. They happen because enough people with different forms of authority begin pulling in roughly the same direction.

Executive sponsorship. Operational ownership. Functional expertise. Informal trust. The person who actually knows how the system works. The person whose team will absorb the change. The person who controls the budget. A coalition is what turns a recommendation into organisational capacity. Without it, even a correct diagnosis can sit beautifully in a document while the business continues around it.

Authority needs to match the mandate

A common failure in transformation work is giving someone responsibility for a system they cannot actually change. Improve client profitability, but Account Directors cannot see the P&L. Fix delivery, but commitments are made upstream without Delivery involved. Own the product, but the roadmap is still set elsewhere. Transform the function, but every structural decision requires approval from someone who does not have time to make it.

Accountability without instruments is vibes. Responsibility without authority is often theatre. The intervention needs enough mandate to alter the mechanism it is supposed to fix. If that mandate does not exist, that is not a minor implementation detail. It is part of the diagnosis.

Sequence matters

A future-state operating model can be entirely sensible and still fail because the organisation is not ready to absorb it. I learned some of this by getting the timing wrong. In a small founder-led studio, I could see future problems and sometimes wanted to build for them early. Some of those systems were directionally right. The organisation did not yet need all of them.

The cost of adoption arrived before the cost of the problem. That is a poor trade. Now I think more explicitly in horizons. What needs to change this month? What becomes important in ninety days? What should we deliberately not solve yet? What dependency has to exist before the next layer is useful? Change has an architecture. Sequence is part of it.

The intervention should create its own evidence

A transformation programme that cannot tell whether it is working is largely a narrative contest. We need some way to observe the change. Did the work become more visible? Did margin move? Did error reduce? Did decisions happen faster? Did fewer things require escalation? Did people actually use the new system? Did the same work simply move elsewhere?

The measure does not need to capture every benefit. It needs to be good enough to make the next decision. Evidence creates credibility. It also creates permission to adapt.

Embed before declaring victory

A system is not implemented because it exists. It is implemented when people use it under normal pressure. The new briefing process survives a rushed request. The commercial rule survives an important client. The role boundary survives somebody senior bypassing it. The shared tool remains current when the person who built it goes on holiday.

That is the difference between launch and embedding. Most change looks better during launch. The organisation reveals whether it has changed later.

The loop

The method I use now looks more like: Observe -> triangulate -> map -> diagnose -> simplify -> frame -> align -> build -> embed -> measure -> repeat The middle matters as much as the beginning. Frame. Align. Build shared ownership. The system you design is only half the work. You also have to design how the organisation gets from its current state into it.

That is not softer work around the "real" operating model. It is part of the operating model. A technically brilliant intervention that an organisation cannot adopt is not brilliant. It is unfinished.