The Change-Ready Organisation: Structuring Teams for Constant Evolution

October 13, 2026

Company Culture

Consider the implementation that went perfectly.

Here’s a composite most change leaders will recognise. The technology was chosen with care, the vendor was credible and the rollout plan was thorough. Training was tested and delivered on time. Nobody complained, and usage in the first few months looked reasonable. Eighteen months later the system was doing a fraction of what it was built for, while the informal processes it was meant to replace ran alongside it, quietly and efficiently, never switched off.

No one decided to resist. No one organised against the change. People found, in practice, that the new system added friction to the parts of their work it was supposed to simplify, and they dealt with that friction the way competent people always do. They worked around it.

The plan treated rolling out the system and changing the daily work as one job. They’re two jobs, and only one of them had a plan.

Put operational knowledge into the design

Ask of any transformation programme whether the people affected helped design how the change would work in their context. Their involvement matters because they know what the process has to handle when the documented flow meets the working day.

The people doing the work carry knowledge the design team usually doesn’t have in full: the edge cases the new system wasn’t built for, and the informal agreements that keep the current process running despite its documented flaws. They also know why a multi-step approval chain collapses on the afternoon a production system fails and somebody needs authority to decide on the spot.

A change programme designed without this knowledge is designed for a version of the organisation that doesn’t exist. Adoption fails in the gap between that version and the real one.

Ask them early, while the design can still move, and ask about the work rather than about opinions: what happens when this step fails on a busy day?

Involving people in design isn’t the same as asking whether they support the change. Asking about support gets you attitudes. It tells you nothing about how the work runs. Too many programmes confuse the two. They run extensive engagement sessions, then implement the design the team had before the sessions started, because engagement was run as a consent exercise and nobody asked it for information. Staff sit through the workshops, then watch the design from the original deck arrive intact.

What structure produces

“Change-ready organisation” usually points at culture: an attitude toward change that’s receptive rather than resistant. Culture matters. It’s also harder to design than structure.

Structure is the more tractable variable: the explicit arrangements that decide how the organisation runs day to day. Reporting lines, decision authorities, role definitions, information flows, review cadences. Structure shapes culture slowly, because whatever it makes easy or hard becomes, over time, what people expect.

Take a structure where piloting a new process needs a stack of sign-offs. No culture programme about psychological safety will make that organisation change-ready. Or take the person with the deepest operational knowledge of a function, sitting several reporting levels below whoever can change how that function works. The knowledge exists. It can’t climb the reporting line fast enough to change anything.

Compare an organisation where the team lead who spots a defect in the new process can pause its use that same day. People there learn quickly that raising problems is safe, whatever the values poster says.

The trust prerequisite

Structural design produces nothing useful in change contexts without one condition. The people asked to work differently have to believe the change is a real attempt at improvement rather than a management preference being exercised on them.

That’s different from believing the change is correct. People can be uncertain whether a proposed change will help and still work with it, if they believe the people deciding understand the problem. If they believe the decision had nothing to do with their operational reality, the same people won’t engage with the same change.

Trust is earned through the changes that came before. Suppose an organisation has delivered programmes that ignored how the work ran, that didn’t perform as described, or whose benefits were claimed at a level above where the costs landed. That organisation is asking for trust it hasn’t established. A team that was told the last system would save them time, then watched it add reporting, will read the next announcement through that memory. No engagement programme fixes that. Only the design of the next change, and how it turns out, starts to.

Give the difficult moments more design time

Look at the plan for a typical change programme and the effort is spread evenly across the lifecycle: needs analysis, design, technical implementation, training, communication, measurement. Each stage gets a comparable share of time and attention.

Success and failure don’t spread out like that. They get decided at a few critical junctures. One is the moment the first real edge case hits the new process and the workaround either exists or gets improvised. Another comes when performance under the new system is compared with the old. Numbers usually dip in the early weeks of any new process, and if someone senior reads the dip as failure, the programme is in trouble. A third is the point where the people most resistant to the change, who are frequently the most operationally expert, either find something that convinces them or don’t.

The organisations that handle change more reliably name those moments in advance and put their design time there. That might mean a named person on call for the first edge cases, or a senior leader who agrees beforehand not to judge the numbers until the dip has passed.

Give the new process a recovery route

Teams will meet cases the rollout plan missed. Decide in advance how they report one, who can authorise a temporary workaround and when it expires. A workaround with no expiry date quietly becomes the process. Ban workarounds outright and the same behaviour goes out of sight. Either way, the design needs a visible path for exceptional cases while the system gets corrected. The route can be modest. A shared channel and a named person who answers it will do, as long as people can see the answers.

Review those reports during the first weeks of use. Sort them into training questions, defects in the technical system and mismatches between the formal process and the work. Each category has a different owner. Publish the decisions and the reasons behind them so teams can see which feedback led to a change. That’s how participation becomes part of how the organisation runs, instead of a consultation that ends when the technology goes live.

The review needs a decision deadline too. If an edge case can wait indefinitely for a steering committee, staff will create their own answer. Name the person who can approve a temporary response and the date a permanent rule will be considered. A small, predictable route for correction gives the new process a better chance of surviving contact with the work.

The diagnostic before the structure

The most reliable diagnostic for change readiness is a single question, put to people at every level. Their answers hold the organisation’s real change history, the informal record of what worked and what didn’t, which lives nowhere in the official documentation. That history is what any structural design has to work with. Put the question to the leadership team and to the people doing the work, then compare. If the two versions don’t match, you’ve found your first design problem. So ask it before you design anything:

Name the last three things that changed here, and tell me what happened with each of them.