Run/Serve/Change Recursion, not Hierarchy
Explaining the difference between recursion and hierarchy
Hierarchy stacks roles and people. Recursion nests systems.
A recurring source of confusion with Run / Serve / Change is that people treat them as fixed layers, rather than relative to the system in focus.
At any recursion, there is core operational work—that’s what Run means at that level.
When the enterprise is the system in focus, Run means delivering products or services to customers.
When Serve is the system in focus, Run means coordination, integration, and regulation as a service.
When Change is the system in focus, Run means strategy deployment and system evolution.
Each recursion still contains Run, Serve, and Change.
What shifts is what counts as the work, not who outranks whom.
In recursion, higher levels don’t supervise lower ones — they set constraints, provide platforms, and define boundaries within which the work below can operate.
In hierarchy, the relationship runs on permission: authority flows down, escalation flows up.
In recursion, the relationship runs on constraint: each level operates within the boundaries set by the level above, without requiring approval for routine variance.
Most organisational dysfunction comes from treating this as a hierarchy of power instead of a recursion of responsibilities.
If you see hierarchy here, check what’s flowing: authority or constraints — commands or conditions.
When intervening in any organisation, it’s essential to look at least one recursion up (the environment shaping the system) and one recursion down (the consequences being created).
With thanks to Dr. Richard Claydon for the Run / Serve / Change framing, this builds directly on that foundation.
I received some questions about how to think about Serve and how it applies constraints so figured a public reply might be best.
What sits above Serve isn’t just the resource bargain. At R+2 / Change you’re also setting system identity and legitimacy, what this system exists to do, for whom, and under what risk and value assumptions.
Serve (R+1) doesn’t agree outcomes or budgets in that sense. It designs and operates the enabling constraints, the conditions under which Run can act autonomously without escalation, at scale.
Run (R0) then designs how it delivers outcomes within those constraints.
So exploiting a constraint inside a factory is Run work.
Redesigning the factory’s operating systems is Serve work.
Deciding what the factory exists to do, what risks it can carry, and what trade-offs are acceptable is Change work.
Two concrete examples to make this real:
Expense management
• R+2 (Change): sets policy, who can claim, limits, conditions, risk posture.
• R+1 (Serve): designs and operates the expense system used by everyone (tools, workflows, controls).
• R0 (Run): uses that system as part of delivering day-to-day work.
Master Data Management
• R+2 (Change): sets data policy and principles.
• R+1 (Serve): selects platforms, defines taxonomy, governs data structures.
• R0 (Run): uses master data inside customer delivery and product work.
When identity and boundaries are unclear, Serve stops being enabling infrastructure and becomes a negotiation layer, and escalation becomes the default coordination mechanism.
Cool. If I’m more specific and say a team of 8 people that together produce takeaway meals for a delivery service (R0). They see that if they get a new oven, they can increase their output, and do the maths that tells them it will payback over 3 years. They are happy with that, and so go for it.
And let’s say this is the entire business.
Would you call this Serve work?