Panta Rhei - Accelerating the flow of value

Introduction 

"We've reorganised twice in four years," said the COO.

"What was the second one for?" I asked.

"To fix the first one."

He said it without much of a smile. We were ten minutes into a conversation that was supposed to be about something else entirely.

Later that week I spoke to some of the teams working for him. They talked about a kind of muscle the organisation used to have: the person who knew who to ring, the standing Thursday call that unblocked things before they became escalations, the arrangement between two teams that nobody had ever written down. It had gone in one of the reorganisations, though nobody could say which one. They wanted it back, but they couldn't quite name it, which made it hard to ask for. The people designing the next structure heard "we want it back" as nostalgia, and were wary of carrying anything from the old organisation into what they saw as a clean design. Each side had a point, and neither point made it 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.

By "organisation and operating model" I mean the design of a business that makes it possible to deliver on its strategy and propositions. It translates strategic intent into operational capabilities and is the foundation for execution. The organisation half (structure, roles, people, rewards, culture) and the operating model half (processes, governance, decision rights, technology, locations) are usually designed by different teams, at different times, with different tools. That separation is a large part of the problem this framework tries to address, so throughout this article I treat them as one design problem.

I call the framework Panta Rhei. Heraclitus wrote in the fifth century BC and very little of his work survives intact; what we have are short quotations preserved by later writers, which scholars call fragments. Panta rhei, "everything flows", is the two-word summary of his thinking that stuck, even though it reaches us through those later writers and we can't show he wrote it himself. It suits the purpose well enough.

From symptoms to root causes

Symptoms

Let's start with the symptoms, in the words people actually use. These come up again and again in my conversations (you'll also find them on my website under "What we solve"):

1. "We've restructured again, and nothing has improved." The boxes moved, but the way work moves through the organisation stayed the same.
2. "Our governance slows decisions and stifles delivery." Legacy roles, unclear decision rights, siloed teams. Everything needs three forums, and none of them can say yes.
3. "We tried product structures and value streams, and nothing seems to improve." A blueprint that worked somewhere else was imported wholesale, including into the corporate centre, the regulated functions and support functions it was never designed for.*
4. "We've merged two teams and they still work like two teams." One function on the org chart; two in daily life, with different intake routes, different tooling, different definitions of done and a quiet competition over who owns what.
5. "We're separating a shared estate and nobody can tell us what breaks." Carve-outs expose every undocumented dependency at once: shared systems, data, contracts and people, none of it drawn.
6. "Nobody who is accountable for delivery actually controls the resources." The matrix split accountability from capacity. Portfolio leads own the outcome, capability leads own the people, and the arbitration happens in a corridor.
7. "Nobody is sure where one role ends and the next begins." Project managers and producers, delivery leads and product owners, PMO and programme teams. Duplicated effort in the good weeks, unclaimed work in the bad ones.
8. "Every region does it differently and we cannot compare anything." Consolidation turns into translation, and the group view is always three weeks old and slightly wrong.

Root causes

The usual responses are just as familiar. There is boxes-and-lines thinking, where attention stays on hierarchy, roles and rewards. There are fragmented frameworks: SAFe-like delivery on one side, roles and rewards from HR practice on another, governance set by the General Counsel on a third, and a capability model or "operating model canvas" from business architecture layered over the top, none of them designed with the others in mind. And there is disconnected tooling, which quietly creates a cottage industry of data extractors and report creators.

Who sponsors the redesign shapes it too.

• HR-led work tends to converge on grades, spans and job descriptions.
• Technology-led work converges on platforms and team topologies.
• Finance-led work takes cost out in year one and, along the way, removes capability nobody realised they relied on. Operations-led work improves the processes in scope and leaves incentives and culture where they were.

Layer an XMO (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.

Look at the symptoms again. Each one describes information not reaching the person who has to decide, work stalling at a handoff, power sitting away from the information, decisions travelling too far up, or controls costing more than they protect. These are problems of flow. The org chart gets the attention because it is often the only picture of the organisation anyone has. 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.

A word on AI

AI belongs in the same category as steam, electricity and the internet: general-purpose technologies that change what the work is, who does it and how it gets coordinated. Each of those eventually changed the dominant organisational form. Steam gave us the factory, the railways and the internal combustion engine gave us the multidivisional firm, and the internet gave us the product-led organisation. In each case, adding the technology to the old form achieved very little.

In my client work and public research I see three emerging patterns.

• Bolt-on, where AI is added without redesigning the work around it.
• Shadow substitution, where individuals use AI privately and the organisation captures neither the value nor the risk.
• Wholesale automation, (long way off, but ambition is there) where AI absorbs all the routine work and, with it, the ground on which expert judgement is built.

The part of the organisation most exposed is the technostructure (read: Henry Mintzberg): the analysts, planners, schedulers, controllers and quality engineers who design, regulate and standardise work. That is very close to a description of what current AI does well. The middle line is next.

The Framework

First principles

Everything in Panta Rhei rests on six propositions about what organisations are. I have tried to keep this list to statements about the nature of organisations, the things I would defend from first principles. Preferences about method come later, and the rest of the framework follows from them.

1. Everything flows. An organisation is a system of flows: information, work, power, decisions and control. It creates value by moving things, and when the movement stops, nothing is created however good the structure looks on paper. An org chart is a snapshot of how those flows were arranged at some point in the past. So design has to start with the flows, and structure comes after them.
2. The environment never stops changing, so no design is ever finished. Markets, regulation, technology and workforce expectations all move continuously, and a design fitted to today's conditions starts drifting out of fit on the day it goes live. For that reason I have dropped the "T" from TOM. There is no target operating model; there is a sequence of transition states, each one fully workable, each a better fit for current conditions than the one before. I call the result a fluid operating model (FOM).
3. An organisation can only absorb so much change at a time. People, systems and routines have a finite capacity to take on new ways of working while still running the business. Exceed it and the change fails, even when the destination was right. So each next step is chosen from what Stuart Kauffman called the Adjacent Possible: the most ambitious configuration that is actually reachable from where the organisation stands today.
4. The organisation that runs the business and the organisation that changes it are one organisation. Change the Business and Run the Business share people, budgets, systems and customers. When they are treated as two organisations with a handover in between, much of the value leaks away at the handover: capability arrives and can't be absorbed, value tracking stops, and operations inherit a configuration nobody asked them about. So the two halves are designed together, and the boundary between them is itself a design decision.
5. People and technology make up one system. Eric Trist and Ken Bamforth showed this in the Durham coalfields in 1951. Superior machinery, introduced without redesigning the work around it, broke the small-team arrangements that had made the pits work, and both morale and output fell. The social and technical parts of an organisation have to be designed together, which Trist and his colleagues called joint optimisation. With AI changing the technical side as fast as it is, this matters more now than at any point since.
6. There is always more than one workable design. The same coalfield studies found that at the Haighmoor seam, miners and managers facing the same technology had organised themselves quite differently, with better economic and human results. Trist called this "organizational choice": technology constrains the organisation but does not determine it. For any set of impediments there are several credible designs, each with different trade-offs, and choosing between them is a decision for the executives who will have to live with it.

The organisational anatomy

To see the flows, you need a picture of what they move through. The anatomy has three layers:

1. five parts,
2. seven flows and
3. ten lenses.

Five parts. I use Henry Mintzberg's anatomy from The Structuring of Organizations (1979), because it is well understood and it still works:

1. Strategic Apex: the top-level executives responsible for overall direction, strategic decisions and external legitimacy.
2. Middle Line: the chain of managers linking the apex to the operating core, translating strategy into operational plans.
3. Operating Core: the people who do the essential work of producing the organisation's goods or services.
4. Technostructure: the analysts, planners and specialists who design, regulate and standardise the work of others.
5. Support Staff: legal, finance, HR, facilities and similar services to the rest of the organisation.

AI agents raise a fair question here: are they a sixth part? They cut across all five and perform work that humans would otherwise do. Making them a sixth part costs clarity, and the questions agents raise (what they do, what authority they hold, who oversees them, how they are retired) are better handled through the design parameters. I may revisit this once the patterns settle.

Seven flows. Across these five parts, there are five flows that determine an organisation's ability to survive and thrive:

1. Information flow: up, down and across the organisation, formal (reports, meetings) and informal (the grapevine, the conversation by the coffee machine).
2. Work (material) flow: the tasks, activities and processes that produce the organisation's products and services.Material, in the case of manufacturing and logistics
3. Power flow: the ability to influence decisions and actions, whether it comes from position or from expertise and personality.
4. Decision-making flow: how problems are identified, alternatives generated and evaluated, and choices made.
5. Control flow: how the organisation sets standards, monitors performance and takes corrective action.
6. Value flow, typed as Chain, Shop or Network, since how work gets done and how value gets created are different questions; and
7. Learning flow, the rate at which experience turns into capability, which matters more now that AI speeds up novice learning while putting expert skill at risk.

Ten lenses. Mintzberg describes the organisation through five overlaid views: formal authority, regulated flows, informal communication, work constellations and ad hoc decision processes. I use these with one adjustment. Regulated flows split into two lenses, regulated operational activity (closest to customer journeys and value stream maps) and regulated control activity (committees, boards, forums and the packs that feed them), and ad hoc decisions are handled through the decision-making flow. That gives five lenses:

1. Organisation as a flow of formal authority
2. Organisation as a flow of regulated operational activity
3. Organisation as a flow of regulated control activity
4. Organisation as a flow of work constellations
5. Organisation as a flow of informal communication

To these I have added five more:

1. an Ecosystem View (where the firm boundary sits and what crosses it),
2. a Capability Heat Map (what the organisation has, lacks, no longer needed, or is building, against strategic priority),
3. an AI Augmentation Overlay (which work is human, augmented, substituted or hybrid),
4. a Value Configuration Lens (Chain, Shop or Network, activity by activity) and
5. a Variety and Regulation Lens (where complexity is generated and where it gets absorbed).

The work constellation and informal communication lenses are where the missing muscle from my opening story tends to show up. Trist's 1963 book on the coalfield studies was subtitled The Loss, Rediscovery and Transformation of a Work Tradition. Most organisations I work with have lost something of that kind without noticing, and these two lenses are how you find it again.

Though not all ten lenses are always needed, a design decision taken from a single lens usually looks wrong from another. So all ten are produced before any design choices are made.

Diagnostic tools

In the first version of Panta Rhei there were three tools: a mapping tool (the anatomy above), a diagnostic tool and a design tool. The diagnostic side now has three parts.

The problem-type triage. Before mapping anything, ask what kind of problem you are dealing with. I distinguish three:

1. Structural-flow problems, where the impediment lies in how the organisation is configured, how decisions are routed and how work moves. Flow mapping and the design parameters are the right toolset here.
2. Relational-meaning problems, aka "taxonomy & translation problems"; where the impediment lies in how people make sense of what the organisation is doing, the stories it tells about itself and the language it uses. Here the right toolset is dialogic organisation development: narrative work, generative dialogue and sense-making conversations.
3. Political-contestation problems, where the impediment lies in competing interests, coalitions and sponsorship agendas. Interest-group analysis, coalition mapping and negotiated change are the tools for this.

Most of my engagements involve all three. The triage establishes the proportions and directs the work accordingly. Without it, every problem gets treated as structural, and a flow map is applied to a problem it cannot reach. I have learned to tell clients when their problem is mostly political, even though it is a harder conversation.

The Transformation Canvas. This is the main structural diagnostic (more about it here). Part A maps the current state along the product or service lifecycle, from concept to cash: key activities, key outputs, processes and methods, systems and technology, forums and team organisation, with material and information flows made explicit. Part B states the outcomes sought, names the impediments standing in the way, and defines how each impediment will be measured across time, cost, resource, agility and quality. It works best as a workshop with the CEO, COO, CFO, CHRO and CIO perspectives all in the room. Whichever dimension generates the most heat in that room is usually where the trouble lies.

The Agility Abacus. Where the impediment is specifically about agility, I use the Abacus, which I developed within TDF and share with Panta Rhei. It uses thirteen dichotomies to surface tensions the design has to resolve, among them standardisation versus mutual adjustment, central versus distributed authority, exploit versus explore, and formal versus informal coordination.

The output of all three is an impediment register: the specific impediments to flow, each with an agreed measure, from which design priorities are set.

Design principles

The first version of Panta Rhei had five design principles and the second had eight. Some of the eight overlapped, and one (joint optimisation) is really a statement about what organisations are, so it now sits with the first principles. That leaves six.

1. Establish and articulate the purpose, and how you will know it is served. It may sound like a cliché, but figure out why the organisation and operating model are changing, and say so in a way people share. I state it as a testable proposition: IF we change the organisation and operating model in these ways, THEN we expect these outcomes, BECAUSE of these assumptions. The KPIs come from this statement and answer one question: how do we know we are succeeding? Where the mental model is genuinely shared, teams need much less "alignment" and can pursue different objectives without pulling apart.
2. Organise around the flow of value. Whatever the team structure, understand the value flow first. Value tends to move in several directions at once, which is why I am wary of the "stream" metaphor. Every way of organising limits some form of value; the right structure is whichever serves the intended value best, for as long as that purpose holds. Functionally organised teams are usually efficient and slower to respond to change. Cross-functional teams respond better and usually cost more. Where flow and resource utilisation conflict, flow should win.
3. Bring decision-making to where value is created and captured. Those closest to the work are usually best placed to decide. It has some unintended consequences, and the benefits generally outweigh them. It becomes much easier to move decisions away from forums and towards teams when operations are supported by good data, and it needs a good deal of psychological safety for teams to actually use the authority they are given.
4. Build frequent feedback loops across the whole system. I don't mean sprint demos. Each process, system and team can perform well in isolation; it is their interactions that need attention. Loops across boundaries (between teams, between Change and Run, between the operating core and the technostructure, between the firm and its ecosystem) act as a safety net, limiting the damage when a decision made close to the work affects an area the team knows little about.
5. Design for fit. From Nadler and Tushman's congruence model: the components of a design (work, people, formal organisation and informal organisation) have to reinforce each other. A new structure that sits badly with the existing incentive system is an incomplete design, and so is a new platform that sits badly with the existing decision rights.
6. Decide explore, exploit or both, for every unit. From O'Reilly and Tushman's work on ambidexterity. Running the current business and exploring the next one call for different structures, processes, metrics, rewards and cultures. For each unit, state which it is doing and, if both, how the two are kept apart and brought back together.

Design parameters

The design parameters are the building blocks you manipulate to shape the organisation and its operating model.

Mintzberg set out nine design parameters in four groups: design of positions (job specialisation, behaviour formalisation, training and indoctrination); design of superstructure (unit grouping and unit size); design of lateral linkages (planning and control systems, and liaison devices); and design of the decision-making system (vertical and horizontal decentralisation).

Panta Rhei recasts these four groups as five, because planning and control (particularly governance cadence) carries enough weight in most organisations today to need a conversation of its own. It then adds seven more, drawn from the other frameworks listed at the end of this article.

Two of these deserve a comment. Rewards (6) are where I see redesigns fail most often: the structure changes, the incentives don't, and behaviour follows the incentives. And the last clause of human-AI work allocation (12) is the one most often skipped. Let AI take all the routine work and you remove the ground on which expert judgement grows.

Transition design method

If there is no target, the method has to be about how the organisation moves. Panta Rhei works in five steps:

1. Visualise the organisation as a system of multiple flows, using the anatomy and the ten lenses.
2. Understand the impediments to flow, using the triage, the Transformation Canvas and, where relevant, the Agility Abacus.
3. Establish the design parameters and measurable outcomes. Working through each impediment against the design parameters gives you the change interventions.
4. Design transition states. Change interventions, layered over a timeline against specific outcomes, give you the transition states. This is what I mean by a fluid operating model.
5. Implement through integrated feedback loops across people, process and tools, and reassess before designing the next state.

Six things make a transition state properly designed.

• It is fully workable. The organisation must be able to run on each state for as long as the next one takes to design, whether that is a quarter or a year. It is never a half-built version of something else.
• It is chosen from the Adjacent Possible. After each state, reassess what is reachable now. New constraints and new opportunities feed the next design.
• It is designed with Run from the start. Absorption criteria are explicit (what has to be true for operations to take this on without losing value), capability transfer is sequenced into the plan, and value tracking continues across the boundary.
• It sequences capability. Roles retire, change or appear (trainers, explainers and sustainers of AI systems, AI governance, model risk). Without explicit sequencing, you end up needing capabilities you haven't built and paying for ones you no longer need.
• It leaves the organisation able to change again. The design includes a standing capability to sense impediments, diagnose them and respond without commissioning a new programme each time. An organisation that can change once, but not repeatedly, is brittle.
• It is measured by flow. Progress is measured by improvement in flow, since a milestone that records a structural change without the matching flow improvement tells you very little.

Two more ideas guide the method. The first is Philip Herbst's principle of minimum critical specification: decide only what has to be decided now, and leave as much as possible to be settled later by the people who will work in the design. The second is from my own experience: communicate the impact to the middle line and operating core humanely and early. Uncertainty, perceived demotion and role ambiguity are part of the design problem.

Two more ideas guide the method.

1. The first is Philip Herbst's principle of minimum critical specification: decide only what has to be decided now, and leave as much as possible to be settled later by the people who will work in the design.
2. The second is from my own experience: communicate the impact to the middle line and operating core humanely and early. Uncertainty, perceived demotion, and role ambiguity are part of the design problem.

Keeping the design whole

Because each sponsoring function sees the problem through its own levers, the framework includes a few habits to keep the design whole.

The CEO, COO, CFO, CHRO and CIO etc. perspectives are brought into the design from the start, as co-designers who own the choices. If one of them won't engage, that is recorded as a finding in its own right, because it usually is one. Each supplementary lens has a natural owner: the Capability Heat Map sits with the CHRO, the Value Configuration Lens with the CFO and strategy, the AI Augmentation Overlay with the CIO, the Ecosystem View with the CEO, and the Variety and Regulation Lens with the COO. At every design review we ask which of the twelve parameters the design has touched and which it has missed. A design that touches three or four of the twelve is usually reflecting one function's view. Finally, rewards and culture (parameters 6 and 7) are always in scope, however the work was sponsored.

For the practically minded

Behind the framework sits a pattern library of patterns in five clusters. Four follow the arc of the work:

1. Flow Mapping,
2. Impediment Diagnosis,
3. Organisation and Operating Model Design and
4. Transition Management.

The fifth, AI-Augmented Organisation and Ecosystem Design, cuts across the other four and is where an engagement starts when AI or ecosystem design is the main driver.

If you want to try the approach yourself, here are the steps in order:

1. Triage the problem. Structural, relational or political, and in what proportion. Do this before mapping anything.
2. Bring multiple perspectives together and run the Transformation Canvas, Part A and Part B.
3. Produce all relevant lenses, including the ones your sponsor finds least comfortable.
4. Check the design against all twelve parameters. Note what you have left out, and be honest about why.
5. Design one transition state. Test it against the Adjacent Possible. Ask operations what they would need to absorb it, and take the answer seriously.
6. Define transition KPIs as improvements in flow.
7. Reassess, then design the next state.

Back to the COO. When we did eventually get round to the conversation we had meant to have, the useful question for him was what was stopping value moving through the organisation he already had, and which of his peers had not yet been part of the conversation. The shape of the next structure came much later.

If you are an executive facing your second reorganisation in as many years, connect with me. I can help.