Three Axes — Now What?
Why Most Organisations Can’t Absorb the Changes We Keep Throwing at Them
Most organisational change fails for a banal reason:
people act before they understand what they are acting on.
New methods are introduced, structures are rearranged, values are refreshed, governance is “simplified”. Only later does it become clear that the organisation was never capable of absorbing the intervention. The failure is then explained away as resistance, execution issues, leadership gaps, or culture.
This essay takes a different stance.
It assumes that many of these failures are structural and predictable, and that the most valuable next step is not better change management, but better diagnosis.
In many organisations, particularly regulated, public-sector, or safety-critical contexts, this cost is not a sign of dysfunction. It is the price paid for legitimacy, auditability, and risk containment. Axion does not judge that choice; it makes its structural consequences visible.
The single-axis intervention trap
Most organisational change fails for the same structural reason:
interventions are designed to move one axis while assuming the other two will accommodate the change.
They almost never do.
This is not because organisations are resistant or conservative. It is because each axis places hard constraints on the others. When one is altered in isolation, the system restores coherence the only way it can, by nullifying the intervention.
The pattern repeats across methods and sectors.
Agile transformations
Agile primarily changes regulatory grammar: how decisions are meant to be made, how variance is corrected, how fast feedback loops should operate. Teams are encouraged to act locally, experiment, and adapt.
But in many organisations, responsibility boundaries remain fragmented and authority over risk, funding, architecture, or compliance sits elsewhere. When work crosses those boundaries, which it inevitably does, escalation reasserts itself. Teams remain accountable without being structurally complete. The result is coordination overload, decision latency, and the re-emergence of hierarchy through informal channels.
The grammar changes. The physics does not.
Agile becomes theatre. Not because the method is flawed, but because it is introduced into a structure that cannot carry it.
Business Process Management (BPM)
BPM initiatives often end up focusing on optimising local flows: reducing handoffs, standardising work, and increasing efficiency. On the surface, this looks like Axis 1 work.
In practice, BPM systems almost always encode the existing regulatory grammar into software. Approval chains, escalation paths, and risk controls are hard-wired into workflows that cross functional boundaries and compete across multiple, often conflicting, prioritisation mechanisms.
When real-world variance appears, people cannot correct locally; they wait, workaround, or bypass.
The process becomes technically correct and operationally unusable. Shadow processes proliferate, not because people reject discipline, but because the system cannot absorb reality.
The local flow improves. The flow across the whole value stream either stays the same or gets worse.
Enterprise Architecture (EA)
Enterprise Architecture initiatives typically operate at the level of structural representation: capabilities, platforms, reference architectures, and target states. Their intent is to improve coherence at enterprise scale, and that intent is often legitimate.
Fracture appears when architectural authority is located far from where delivery risk, operational judgment, and situational trade-offs are actually carried, and when that authority arrives late, after commitments have already been made.
Teams are then asked to comply with architectures they did not shape, through governance regimes that specify standards but arrive without the authority or discretion to resolve local variance.
When architectural compliance conflicts with operational legitimacy, speed, safety, customer impact, professional judgment, teams do not rebel. They prioritise outcomes and compensate structurally: workarounds emerge, exceptions normalise, and architecture becomes advisory rather than operative.
Governance tightens, as it must in an escalation-based system. The gap widens.
The architecture remains coherent as a representation.
The work stabilises locally, at the cost of growing incoherence and debt at the enterprise level.
Culture change programmes
Culture change targets meaning and behaviour: mindsets, values, ways of relating. It assumes that if people think differently, the organisation will act differently.
But when authority, incentives, and escalation paths remain unchanged, culture programmes place people in double binds. They are told to act with courage, ownership, or customer focus, while being punished for doing so when risk materialises.
People adapt rationally. They say the right things, attend the workshops, and revert to safe behaviour when it matters.
Meaning shifts. Power does not.
The same structural pattern holds even in the most expensive organisational changes.
Post-merger integrations
Post-merger integration is the most expensive version of the same mistake.
Structures are collapsed, reporting lines harmonised, systems standardised, Axis 1 is forcibly realigned. At the same time, the acquiring organisation imposes its regulatory grammar, often escalation-heavy and risk-averse. What is rarely examined is legitimacy: what counts as competent, trustworthy, or responsible behaviour in each organisation.
Practices that previously signalled professionalism become framed as non-compliance. Authority moves upward. Local judgment is delegitimised. Key people leave. Performance drops.
The acquisition destroys the coherence that made the target valuable in the first place.
Why this matter
These failures are not method failures.
They are diagnostic failures.
Each intervention assumes that unexamined axes will flex to accommodate the change. They do not. They push back, quietly, structurally, and predictably.
Axion exists to make those constraints visible before you act.
The organisation tolerates an intervention until its coherence is threatened. Then it corrects.
Not politically. Not emotionally. Structurally.
This is why diagnosis does not imply redesign. In many systems it clarifies that the degrees of freedom are limited, and that the only available choices concern where the cost is carried, not whether it exists.
To see how this correction actually operates in practice, we need to stop talking in generalities and examine a real case at operating resolution, one that shows all three axes interacting at once.
One of the most common structural correction mechanisms is governance masquerading as integration.
Governance is not integration
Most organisations respond to cross-cutting complexity by adding governance forums: steering committees, portfolio boards, architecture councils, assurance gates.
This is not accidental. Governance becomes the structural substitute for integration when no responsibility domain is authorised to carry integration work continuously.
Decisions are made episodically, in rooms detached from execution, and then released into the organisation to “flow” through functions and end-to-end processes. What follows is predictable: intent is reinterpreted, trade-offs are softened, approvals multiply, and meaning decays as decisions travel.
By the time outcomes return, they are late, partial, and no longer traceable to the original choice, prompting yet another forum.
This is not a failure of governance discipline. It is a structural error.
Integration is continuous work, not an event. Without a permanently staffed responsibility domain at the appropriate decision horizon, organisations substitute motion for coherence and meetings for accountability and then wonder why nothing ever quite changes.
The question, then, is not how to improve governance, but where integration work legitimately belongs.
Agile transformations, particularly in highly regulated environments like banking, are a textbook example of this substitution.
A forensic case: Agile in banking
Large-scale Agile transformations in banking are unusually well documented. The intent was serious, the investment substantial, and the outcomes are now openly discussed.
Banko is a representative case, not because it was uniquely flawed, but because it was typical of what happens when Agile meets a highly regulated institution.
Declared intent
The goals were explicit and familiar:
faster time to market
empowered, cross-functional teams
stronger customer focus
reduced bureaucracy
greater adaptability
This was not cosmetic Agile. Tribes and squads were introduced, coaching was extensive, and parts of the traditional hierarchy were dismantled.
At the level of intent and effort, this was real.
The failure was not moral.
It was architectural.
The tracer bullet
Take a single, unremarkable unit of work:
A regulator-mandated change to a customer-facing product.
Minor in scope. Non-negotiable in compliance terms. Time-bound externally.
On paper, this is exactly the kind of work Agile should handle well.
In practice, the work stalled.
Weeks were spent aligning priorities across tribes. Risk interpretations diverged. Architecture constraints surfaced late. Approval pathways were unclear until they suddenly weren’t, at which point escalation kicked in, timelines slipped, and informal pre-alignment became necessary just to keep things moving.
No one was incompetent.
Nothing unusual happened.
This was the system doing what it does.
Now we diagnose it.
Axis 1 — Responsibility domain coherence
Test:
If the team executed perfectly, full competence, zero defects, could it deliver the outcome end-to-end without relying on external authority?
In practice, the answer was no.
Despite “end-to-end” squads:
funding authority sat elsewhere
architectural decisions sat in central forums
risk and compliance approval sat outside the team
technology dependencies crossed multiple domains
Accountability for outcomes was local.
Structural capacity to deliver them was not.
What followed was inevitable:
coordination load increased
alignment meetings multiplied, the Confusion Tax in action
integration work surfaced late
Diagnosis: Axis 1 fracture.
Responsibility was rhetorically devolved but structurally fragmented.
Axis 2 — Regulatory grammar
Agile assumes a grammar of local correction: short feedback loops, fast decisions, authority close to the work.
Banking operates, necessarily, under a grammar of escalation when variance matters.
When regulatory interpretation, risk exposure, or reputational harm appeared:
decisions escalated
approvals slowed
committees reasserted control
Not because leaders lacked courage, but because the institution’s licence depends on it.
The result was a dual grammar:
local autonomy until it mattered
escalation when it did
Diagnosis: Axis 2 collision.
Agile grammar was layered onto an escalation-based system without reauthoring how variance is legitimately corrected.
Axis 3 — Legitimacy boundaries
Agile reframes legitimacy around:
team ownership
experimentation
customer outcomes
Banking legitimacy is anchored in:
regulatory defensibility
auditability
personal accountability under law
People learned quickly that:
acting “agile” could be career-limiting, professionally compromising, or reputationally unsafe
accountability was personal, authority collective
safety lay in informal pre-alignment
Shadow work emerged, not as resistance, but as adaptation.
Diagnosis: Axis 3 fracture.
The moral logic of Agile teams was never reconciled with the moral logic of a regulated institution.
What followed (inevitable, not unfortunate)
These outcomes weren’t failures of commitment or capability. They were structural corrections.
When responsibility domains are fragmented (Axis 1), coordination load must be absorbed somewhere, it went into alignment meetings and integration forums.
When regulatory grammar contradicts operational grammar (Axis 2), people choose the grammar that keeps them safe, they chose escalation.
When legitimacy is fractured (Axis 3), informal structures emerge to restore local viability - they emerged as pre-clearance and shadow approvals.
What followed was inevitable:
coordination layers re-emerged
ceremonies expanded
decision latency increased
structural controls returned
This was widely framed as “Agile doesn’t suit banking”.
That conclusion misses the point.
Agile did not fail because it was poorly implemented.
It failed because the organisation preserved a legitimate escalation-based coherence while attempting to introduce local-correction practices without relocating where coordination and risk were carried
This failure pattern is often misread as a problem with Agile itself. In practice, it is usually a problem of placement.
A recurring pattern in large transformations is the pursuit of “Agile everywhere”. This is usually framed as ambition, but structurally it is the opposite of discipline. Agility is not a cultural attribute to be diffused uniformly; it is a variety-absorption capability that must be deliberately placed where environmental uncertainty actually enters the system.
This becomes most visible in heavily regulated organisations, where the cost of misplacing authority is high, but the pattern is not unique to them. In most enterprises, only a small number of domains genuinely require high-frequency local correction. Those domains must be structurally safeguarded, with clear authority, compatible grammar, and legitimacy protection, precisely because the rest of the organisation operates under slower, more constrained regimes.
When agility is pursued indiscriminately, it is neither achieved where it matters nor contained where it doesn’t. The result is not adaptability, but systemic incoherence. This does not mean escalation-based organisations are broken. It means they pay for coherence differently.
How to run this diagnosis yourself
The analysis above is not special. It follows a simple protocol.
1. Pick a tracer
Choose a recent, ordinary unit of value, not a flagship initiative.
Something routine. Unremarkable.
If the system cannot handle the ordinary, it will not handle the exceptional.
2. Trace the path
Follow the work from first signal to live outcome.
Document:
where it waited
where approvals were required
where hand-offs occurred
where progress depended on informal alignment
Do not interpret yet. Just trace.
3. Ask three diagnostic questions
a. Structural containment
If the work had gone perfectly, full competence, no errors, was there any identifiable locus of accountability (a Responsibility Domain in Axion terms) that could have delivered the outcome end-to-end without relying on external permission or coordination?
b. Variance correction
When something non-routine occurred, how was it actually resolved?
locally, through judgment?
upward, through escalation?
externally, through rules, contracts, or platforms?
c. Legitimacy gaps
Where did people bypass the formal system to keep the work moving?
4. Document the fractures
Do not fix them. Do not rationalise them. Just name them.
If you cannot answer these questions concretely, you are not ready to redesign anything.
These lenses are not frameworks to be “applied”.
They are ways of interrogating a real piece of work to surface where coherence breaks.
Each lens answers a different question:
Is there anywhere this work could have been carried coherently?
How does the system really correct variance?
Where does legitimacy fail in practice?
They are meant to be used together.
Using only one will give you a partial, and often misleading, picture.
1. Structural Containment Scan
(Axis 1 — Structural Load Coherence)
This lens tests whether accountability and authority coincide anywhere in the system.
The question is not whether teams collaborate well.
At this stage, the Responsibility Domain is a diagnostic construct, not a design prescription, a way of testing whether the organisation has chosen to locate the full load of an outcome anywhere at all.
The core diagnostic question is:
If this Responsibility Domain executed perfectly, full competence, no errors, but never interacted with any other part of the organisation, would the outcome still be delivered?
If the answer is no, structural load is fragmented.
At this stage, you are not assuming a well-designed Responsibility Domain exists.
You are testing whether one exists at all.
To make this concrete, do not ask for org charts or role descriptions.
Trace the tracer and document:
which decisions were made autonomously
which decisions required external permission
which dependencies were hard (work could not proceed)
which dependencies were soft (work slowed, but continued)
What you are looking for is load leakage:
coordination load pushed upward
integrative load deferred, hidden, or manufactured through meetings
environmental constraints resolved elsewhere
When accountability for outcomes is separated from authority to resolve dependencies, coordination work is guaranteed.
This is not a collaboration failure.
It is not a skills gap.
It is a structural condition.
No amount of tooling, ceremony, or behavioural exhortation fixes this, because the problem is architectural, not relational.
Common misreads
Interpreting frequent cross-team communication as healthy collaboration rather than evidence of fragmentation.
Treating dependency management as a capability problem rather than a design signal.
This lens does not tell you how responsibility should be structured.
It tells you whether the current structure is capable of carrying the work it produces.
2. Regulatory Grammar Audit
(How Variance Is Corrected — Axis 2)
This lens identifies the organisation’s actual governing grammar, regardless of what governance documents claim.
Every organisation must correct variance: things that don’t go to plan, don’t fit policy, or introduce risk. The only real question is how.
To run this lens, you observe what happens when something unexpected occurs and ask:
Who is authorised to decide?
How far does the decision travel?
How long does correction take?
What happens if no decision is made?
You are not interested in the “designed” process. You are interested in the path the decision actually took.
Across organisations, three grammars recur:
Local correction (judgment-based authority located within the Responsibility Domain)
Escalation (permission-based authority, displaced to a higher or external locus)
Market / contract (constraint-based authority enacted through contracts, agreements or platforms)
All three grammars are rule-bound. What differs is whether rules enable judgment (at the local level), trigger permission, or replace decision-making entirely.
Problems arise not because one grammar is “bad”, but because multiple grammars coexist without being reconciled.
In many failed transformations, local-correction practices are encouraged rhetorically, while escalation remains the only legitimate way to resolve non-routine issues. This produces latency, risk-aversion, and informal workarounds, all rational responses.
Common misreads:
Confusing autonomy in routine work with authority under risk.
Assuming faster ceremonies imply faster decisions.
This lens does not tell you which grammar you should use.
It tells you which grammar the system actually enforces.
3. Legitimacy Boundary Scan
(What Is Safe to Do — Axis 3)
This lens surfaces where formal authority and local legitimacy diverge.
Every organisation permits actions that different groups experience very differently. Some decisions are technically allowed but feel unfair, disrespectful, professionally compromising, or reputationally dangerous. Others are formally constrained but widely regarded as legitimate to bypass.
Legitimacy is not a single value. It is a plurality of moral logics through which people interpret whether action is acceptable, justifiable, and worth standing behind.
You run this lens by observing behaviour rather than values statements, and by asking questions people usually answer off the record:
“What would actually happen if you followed the process exactly?”
“Where do things slow down unless you know the right person?”
“Which decisions are technically allowed but feel unsafe, unfair, or dishonest to take?”
“Where do people feel forced to perform compliance rather than exercise judgment?”
The most reliable signal is shadow work:
informal approvals
pre-alignment conversations
selective compliance
quiet workarounds
parallel decision-making
Shadow work is not a cultural flaw. It is a structural compensation mechanism. It appears wherever legitimacy is fractured and disappears only when legitimacy is re-authored structurally.
When legitimacy is unclear or contested, people do not become reckless. They become cautious, procedural, indirect, or performatively compliant. These are rational responses to a system that makes legitimate action costly.
Common misreads:
Labelling this behaviour as “resistance” or “culture”
Treating trust as a substitute for legitimacy rather than a temporary bridge
This lens does not moralise behaviour.
It explains why intelligent people act defensively, cynically, or indirectly in systems they do not recognise as legitimate.
After diagnosis: four honest paths
Diagnosis does not obligate intervention. It clarifies choice.
After diagnosis, four honest paths exist:
Local repair, fixing contained fractures, knowing that unresolved integration and legitimacy load will be carried by people rather than structure, often at significant personal cost to leaders.
Selective agility, placing local correction only where environmental variety actually hits, while keeping other domains stable and governed differently.
Architectural redesign for coherence, re-authoring responsibility domains, regulatory grammar, and legitimacy across recursions. Hard, slow, and political, but possible.
Do not intervene, when the system cannot absorb change and you are unwilling or unable to alter the conditions that would make it absorbable.
Most transformation failures occur because organisations default to local repair while underestimating how much Confusion Tax that choice entails.
Seeing before acting
Axion is not a solution.
It is a discipline for removing excuses for not seeing.
Before introducing a method, changing a structure, or launching a transformation, pause and do something far more basic:
pick one real piece of work and trace it.
Trace whether there was any outcome-based Responsibility Domain that could have been viable, given the configuration of business capabilities and authorities it depended on, including those provided by, or constrained through, shared platforms, policies, and services, without relying on ongoing permission, coordination, or workaround.
Trace how non-routine variance was really corrected, locally, through escalation, or via pre-defined rules and mechanisms.
Trace where people quietly compensated for structural gaps just to keep things moving.
If you cannot describe those three things concretely, you are not facing a change problem, you are facing a visibility problem.
Until structural incoherence is made visible at operating resolution, action is just guesswork, and the system will structurally correct it, returning to its prior coherence regardless of your intent.
In some systems, escalation is not a flaw but the primary coherence mechanism; making that explicit, and understanding its cost, is often the most responsible outcome of diagnosis.
Diagnosis restores your choice.
I work with senior leaders facing large-scale change where the cost of structural blindness is high, transformation programs, post-merger integration, operating model redesign.
If you recognised your organisation in these patterns and need to see structural reality before committing resources, that is what Synexia exists for. Diagnosis at operating resolution, followed by design options that address the fractures we uncover.
Axion is documented as a formal model with an archived DOI for reference and citation purposes. This essay focuses on application rather than theory. https://zenodo.org/records/18073324