"We've reorganised twice in the last four years and I honestly couldn't tell you what either one fixed."
That was a COO, about ten minutes into a conversation that was supposed to be about something else. I asked him what the second reorganisation had been trying to achieve. He thought about it and said, "Fix the first one."
Talk to the teams underneath and you hear the other half of it. They describe losing some muscle the organisation used to have — the person who knew who to ring, the standing conversation that unblocked things before they became escalations, the arrangement nobody had written down. They want it back and they can't quite name it, which makes it very hard to ask for. Meanwhile the people designing the new model hear "we want it back" as nostalgia, and treat anything carried over from the old organisation as contamination of a clean design. Both sides are half right, and neither half is getting into the design.
I've had some version of that conversation in many organisations. The details change. The shape doesn't. Someone senior commissions an organisation & operating model redesign. A design arrives. It is announced. Eighteen months later the organisation has quietly rebuilt the informal structure the design broke, and somebody is proposing the next redesign to fix the damage from the last one.
I call it Panta Rhei, after the fragment of Heraclitus that survives in everyday usage. Everything flows.
Why the second reorganisation happens
Here is the pattern I keep seeing, and I want to be specific about it because the generic version ("transformations fail") is useless to anybody.
One function sponsors the redesign. That function asks the questions it knows how to ask. The design that comes out is shaped by that function's tools, vocabulary and incentives. Then it gets handed to everyone else to absorb.
When the CFO sponsors it, you get headcount, cost lines, location strategy, vendor spend, shared services. The cost comes down in year one, measurably. It also removes capability nobody realised they were leaning on, breaks the informal coordination that was doing real work, and triggers attrition among exactly the people you needed to keep. Both effects are real. In my experience the second one is bigger, and it doesn't show up on the same page as the first.
When the COO sponsors it, you get process. Handoffs, queues, cycle times, automation candidates, value streams. Genuine improvement in the scoped areas. Decision rights, incentives, architecture and culture carry on down their previous track, and the improvements hold for exactly as long as the process owner stays in post.
When HR sponsors it, you get new org charts, refreshed job descriptions, revised grades and spans. All necessary. None of it touches the technology architecture, the decision rights, the incentives beyond grade-and-bonus, or the cultural reinforcement. The new structure goes live and the work carries on being coordinated through the same forums, with the same approval routes, on the same systems, measured by the same metrics. Within a year someone says the structure isn't working.
When the CTO or CIO sponsors it, you get platform architecture, team topologies, DevOps practice, cloud shape, vendor consolidation. Where AI is in scope it resolves into copilots, model choice and integration patterns. What doesn't get answered: how decision rights change when AI absorbs the analyst work, how rewards change when engineers are working alongside agents, how finance, risk and compliance need to reshape. The platform lands. The organisation keeps deciding the way it always did.
Layer an (X)MO (TMO, IMO, PMO,VMO etc.) with any of these, the redesign gets treated as a delivery problem. The work breakdown is thorough. The dependencies are tracked. The plan lands on time. Whether it delivered either the organisation design or operating model is a question nobody can answer, because the design decisions were never made coherently in one place — they were made in five places and assembled into a plan.
None of these people are doing anything wrong. They are doing the thing they are good at, on a problem that is bigger than the thing they are good at. That is the whole of the diagnosis.
THREE more traps worth naming
Fixation on "Boxes and lines" rejig.
Across all five patterns, the work collapses into the visible artefact. New boxes. New lines. New titles. The announcement gets treated as the change. Mintzberg made this argument in 1979 and it has aged extremely well: structure is one design choice among several, and on its own it determines very little about how an organisation actually performs.
Value streams as the whole answer.
This one is more recent and it comes from a good place. Value streams and product teams are powerful design inputs, and in the right context they are the right structural anchor. They are not sufficient for whole-enterprise design. The corporate centre doesn't align to a value stream. Neither do the regulatory and assurance functions, the people infrastructure, the data and AI infrastructure, or a good number of the support functions. Force them to and you get a misshapen hybrid that works for nobody. The discipline is to use value-stream logic where it fits and different logic where it doesn't. That takes more judgement than applying it everywhere, which is presumably why it happens less often.
And then there is the one that is live right now.
AI is not a tool you add to an operating model
I want to be careful here, because there is a lot of noise.
The argument isn't that AI is more important than steam engine or electricity or the internet were. The argument is that it is in the same category — a general-purpose technology that changes what the work is, who does it and how it gets coordinated. Steam engines produced the factory. The internal combustion engine and the railroad produced the multidivisional firm. The internet produced myriads of new businesses and associated business models. In each case the dominant organisational form had to change. Adding the technology to the old form produced very little.
So what do I actually do differently?
Nothing in Panta Rhei is a new theory of organisation design, and I'd be suspicious of anyone claiming one. Mintzberg gives me the anatomy. Galbraith gives me the design-policy spine and the role of rewards. Trist and Emery give me the design philosophy. Nadler and Tushman give me the fit test. O'Reilly and Tushman give me "explore and exploit". Beer gives me the cybernetic discipline. Stabell and Fjeldstad give me the value typology. None of that is mine. What's mine is what I do with it in a room with five executives who disagree.
Four things, and then the machinery.
Flow before structure. Most organisation design and operating model work opens with "what should the shape be?" I open with "what has to move through this organisation for value to be created & realised, and what is getting in the way?" Structure is a downstream choice in service of "flow". This is not an original idea — Mintzberg argued it decades ago, which is why the org chart still gets drawn first. In Panta Rhei it is not the first.
Lose the T in TOM. Target Operating Model thinking assumes the endpoint is knowable. By the time a two-year programme delivers the target, the assumptions that shaped it have moved underneath it, and you land with a brand-new design that already needs changing. So there is no target. There are transition states: fully functional operating configurations, each a better fit for current conditions than the one before. You can run on any of them indefinitely if the world stops moving. It won't.
Navigate the Adjacent Possible. The next transition state is the most ambitious configuration you can actually reach from where you are, given your real capacity to absorb change. Not the most desirable one. I've watched more transitions fail because the distance was too great than because the destination was wrong, and those two failures look identical in a steering committee.
Change and Run are two halves of one model. Most transformation value leaks at the boundary between the change portfolio and the running business. Capability gets delivered and can't be absorbed. Value tracking stops at handover. Operations inherit a configuration nobody asked them about. So the boundary itself is a design decision, made deliberately, not an inherited fact of the org chart. This is the hardest part of the work and it is the part that gets skipped most reliably.