Quick Navigation
- Start here — the escalation ladder is not a decision rights model
- Three failure modes of undefined authority
- Altitude — how far the consequence reaches
- Domain — which concern the decision belongs to
- The decision map, and the gaps it exposes
- Velocity — where the waiting actually lives
- Pre-authorisation and the three delay nodes
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Most organisations think they have a leadership problem. They usually have a decision rights problem. Engineering managers get held accountable for outcomes they have no authority to influence. Directors cannot make a call without three levels of approval. Both are symptoms of the same missing artefact.
Leadership is not about having all the answers. It is about making sure the right people have the authority to decide — and the accountability to own those decisions.
That one idea turns bottlenecks into clarity, and it turns delegation from a question about who you trust into a question about how the system is designed.
Keep it in mind.
1. Start here — the escalation ladder is not a decision rights model
Most organisations have a process for technology decisions. It usually looks like this. A team cannot agree. They escalate to the architecture board. The architecture board cannot agree. They escalate to the CTO. The CTO makes a call. Everyone returns to work.
That is an escalation ladder. It is not a decision rights model. It answers one question: who breaks the tie when things get stuck?
A decision rights model answers a different question: who should have decided this in the first place, and why was it escalated at all?
Most organisations have invested heavily in the first. Almost none have built the second.
A ladder is reactive by construction — it engages only once a decision has stalled, and it engages by moving the decision further from the people with the context. A rights model is preventive: it assigns authority before conflict requires it, so most decisions never touch the ladder at all.
Try it yourself — The escalation map
Look at your last five escalations.
| Escalation | What decision was stuck? | Who should have been able to make it? | Why couldn't they? |
|---|---|---|---|
If most of your third-column answers name someone below the person who actually decided, your escalations are not about complexity. They are about unclear authority.
2. Three failure modes of undefined authority
When decision rights are unclear, three patterns appear consistently.
Decision Vacuum. Nobody is certain who holds authority for a class of decision, so nobody decides. Teams wait. Delivery stalls. The work technically belongs to someone — but nobody wants to claim a decision they might later be accountable for. The vacuum looks like a process problem. It is an authority problem.
Decision Collision. Two parties make the same decision independently, neither knowing the other was deciding. A domain team selects a messaging platform; an enterprise architecture team has already standardised on a different one. Both decisions were made in good faith. Neither party had clear authority to make the call without informing the other. The collision surfaces weeks later, by which point one decision has been implemented — and unwinding it is no longer a governance conversation, it is a delivery crisis.
Decision Gravity. All decisions pull upward, regardless of their actual altitude. Library choice. Cloud provider. Platform build versus buy. API naming conventions. All travelling up the same chain. The architecture board reviews things it should never see. The CTO is asked to decide things a team lead should own. Leadership becomes a bottleneck — not because they are unwilling to delegate, but because nobody has defined what delegation actually means.
flowchart TD
UNDEF["❓ Authority Assumed,\nNot Assigned"] --> V["Decision Vacuum\nNobody decides\nDelivery stalls"]
UNDEF --> C["Decision Collision\nTwo parties decide\nthe same thing"]
UNDEF --> G["Decision Gravity\nEverything pulls\nupward"]
V --> COST["💸 Stalled delivery\nRework crises\nLeadership as bottleneck"]
C --> COST
G --> COST
Vacuum and Gravity look identical from outside — slow decisions — but their fixes are opposite. A vacuum needs authority assigned somewhere; gravity needs authority pushed back down. Treating one as the other is how organisations add committees and get slower.
3. Altitude — how far the consequence reaches
The structured answer is Technology Decision Domain Architecture (TDDA): a model that maps every class of technology decision to a defined altitude and domain, so that authority is assigned before conflict requires it.
It answers two questions at once. At what altitude should this decision be made? And within which domain does this decision belong? Once both are answered, the right decision authority is clear.
Start with altitude. Technology decisions exist at four.
| Altitude | Description | Examples |
|---|---|---|
| Enterprise | Decisions that set constraints for the entire organisation | Architecture principles, approved cloud providers, mandatory security standards |
| Domain | Decisions that govern a bounded business or technology domain | Domain platform choices, data ownership rules, integration contracts |
| Team | Decisions within a team's implementation boundary | Library selection within approved standards, internal service structure |
| Individual | Decisions a practitioner makes in the act of delivery | Variable naming, local refactoring, in-sprint implementation approach |
Altitude tells you how wide the consequence of a decision reaches. Enterprise-altitude decisions affect everyone. Individual-altitude decisions affect almost nobody beyond the person making them.
Most escalation failures happen because a team-altitude decision gets treated as enterprise-altitude — or an enterprise-altitude decision gets made with no governance at all. Both are altitude errors. One produces bottleneck, the other produces drift, and they are the two commonest structural failures in technology governance.
A decision can only sit at team altitude if the team's boundary is drawn widely enough to contain its consequences — which is why boundary design and decision rights belong together. That side of the problem is covered in Conway's Law & Team Boundaries.
4. Domain — which concern the decision belongs to
Altitude alone is not enough. A decision also belongs to a specific domain of concern.
| Domain | Covers | Typical Owner |
|---|---|---|
| Investment | Build vs. buy, vendor selection, budget allocation | Architecture board + CTO |
| Standards | Approved technologies, languages, protocols | Enterprise Architecture |
| Platform | Core infrastructure and shared service decisions | Platform Engineering + EA |
| Integration | APIs, events, contracts between systems | Domain Architecture |
| Implementation | How a team delivers within its boundary | Engineering Team |
| Security | Access, data classification, threat surface | Security Architecture |
A decision belongs to a specific altitude and a specific domain. Together, the two axes define the precise location of decision authority — precisely enough that nobody has to guess.
5. The decision map, and the gaps it exposes
Combining both axes produces a map.
| Investment | Standards | Platform | Integration | Implementation | Security | |
|---|---|---|---|---|---|---|
| Enterprise | CTO + Arch Board | Enterprise Arch | CTO + Platform Lead | Enterprise Arch | — | CISO |
| Domain | Domain Lead + Arch | Domain Arch | Platform Eng | Domain Arch | — | Security Arch |
| Team | — | Eng Lead (within standards) | — | Team Arch | Eng Lead | Security review |
| Individual | — | — | — | — | Engineer | — |
Every blank cell is intentional. Not every altitude applies to every domain. An individual engineer does not make investment decisions. An enterprise architecture team does not decide variable naming conventions.
The map makes authority visible — and it makes the blanks visible too. A blank where a cell should not be blank is a decision rights gap waiting to become a delivery failure.
Three gap types become visible once the map exists.
Altitude Mismatch. A decision is being made at the wrong altitude. A team is making a vendor selection that should sit at enterprise altitude; or an architecture board is reviewing implementation approaches that belong at team altitude. Altitude mismatch generates either ungoverned decisions or governance bottlenecks. Both are expensive.
Domain Vacancy. A decision domain has no assigned owner at any altitude. Integration contract standards. Data classification at domain level. Security review ownership for new services. These vacancies do not stay quiet — they generate conflict at the moment a decision becomes necessary.
Authority Overlap. Two owners share authority over the same cell. Both believe they have the right to decide. Neither is wrong — the map was never drawn. Overlap is what produces Decision Collisions, and the map makes it visible before it produces incidents.
Try it yourself — The decision inventory
Identify the ten most common technology decision classes in your organisation. Take three of them into this table.
| Decision class | Altitude it currently reaches | Who believes they hold authority | How long it takes to resolve |
|---|---|---|---|
Do not design anything yet — document what actually happens. You are looking for at least three decision classes where two different parties claim ownership. Those are the Decision Collisions waiting to happen.
6. Velocity — where the waiting actually lives
A map tells you who decides. It does not, by itself, tell you how long deciding takes. That is the second half of the problem.
When decision velocity is slow, organisations usually blame culture, risk aversion, leadership hesitation, or low accountability. Those are visible symptoms. They are not the mechanism.
The actual bottleneck is mechanical. Every strategic decision travels through a system — not metaphorically, mechanically.
flowchart LR
A["Strategic Insight"] --> B["Alignment Discussion"]
B --> C["Approval Layer"]
C --> D["Governance Checkpoint"]
D --> E["Funding Gate"]
E --> F["Backlog Prioritisation"]
F --> G["Delivery Execution"]
Each node adds delay, and not all delay is equal. Some is useful. Some is structural friction. Some is just inherited architecture.
The mechanical causes are specific. Approval layers create waiting because authority is unclear or duplicated — the direct consequence of a missing decision rights map. Governance checkpoints slow decisions because they operate in batches. Funding gates force intent to wait for budget rhythm. Backlog translation turns one decision into three interpretations.
Underneath sits an asymmetry. Organisations have spent years making strategy faster — quarterly planning, monthly pivots, continuous prioritisation. The governance layer often still runs on annual budgets, fixed review boards and manual sign-off chains. Strategy speeds up. Execution does not. The distance between them grows.
Three things break when that gap is left alone. Strategy outruns execution, and the backlog becomes a translation bottleneck. Shadow acceleration emerges — teams that cannot move inside the system begin moving around it, with untracked shortcuts and hidden dependencies; the business appears faster while the architecture becomes less governable. And governance becomes theatre — approvals still happen, but the real decisions were made before the meeting started. The meeting is no longer a decision point. It is a documentation ritual.
7. Pre-authorisation and the three delay nodes
Decision Velocity Architecture (DVA) is the structural response. Its premise is simple: if a decision is predictable, it should not need to wait for approval.
DVA does not eliminate governance. It changes how governance is applied — shifting the system from waiting states to pre-authorised states. Four changes carry it.
From approval to pre-authorisation. Instead of asking can we do this?, the organisation defines in advance under what conditions is this already allowed? That single change removes a large amount of waiting.
From batch review to continuous validation. The decision is validated when it is made, not when the board next meets.
From funding gates to funding envelopes. Instead of making teams wait for every individual decision to pass a budget approval, a decision class gets an envelope. Within it, execution proceeds.
From translation layers to direct flow. Strategy should not be rewritten three times before execution. The fewer translations, the fewer delays.
flowchart TB
A["Decision"] --> B{"Is the outcome predictable?"}
B -- Yes --> C["Pre-authorise"]
B -- No --> D{"Is the risk reversible?"}
D -- Yes --> E["Automate with validation"]
D -- No --> F["Manual approval"]
C --> G["Direct execution"]
E --> G
F --> H["Governance review"]
Not every decision needs the same path. Not every decision deserves the same delay.
If you want to start somewhere concrete, three delay nodes come out first.
- The duplicate approval node. When the same decision is approved twice by two different groups, the system is already over-governed. Remove one layer. Clarify authority.
- The batch governance node. If a decision is safe enough to be reviewed only once a month, it is usually safe enough to be pre-authorised. Move low-risk decisions out of batch review.
- The funding translation node. If strategy must wait for a separate budget interpretation before execution can start, the financial architecture is the bottleneck. Move to envelopes.
Two engagements show what this yields. In a healthcare organisation with too much governance, every technology decision — major platform selections and minor configuration changes alike — ran through the same three-level approval chain, and teams had stopped asking permission, building workarounds and hiding them. Recurring decision types were mapped to the appropriate altitude and the chain was replaced with a decision rights matrix that matched review depth to risk; the architecture board's agenda shrank by 60%. In a retail company whose strategic decisions required three layers of approval, the decision flow was mapped end to end and decisions classified into pre-authorisable, conditionally automatable and manual. Structural delay was cut by 60%, and strategy, governance and execution began moving on the same clock.
Putting it all together
flowchart TD
D["A Decision Arrives"] --> ALT["Altitude\nEnterprise · Domain\nTeam · Individual"]
D --> DOM["Domain\nInvestment · Standards · Platform\nIntegration · Implementation · Security"]
ALT --> MAP["🗺️ Decision Rights Map\nAuthority located precisely"]
DOM --> MAP
MAP --> CLASS["Classify for velocity\nPre-authorisable ·\nConditionally automatable ·\nManual"]
CLASS --> OUT["✅ Decided at the right altitude,\nwithout unnecessary waiting"]
The foundation:
An escalation ladder tells you who breaks ties; a decision rights model tells you who should have decided in the first place. Undefined authority produces vacuum, collision and gravity — and vacuum and gravity need opposite fixes. Altitude and domain together locate authority, and the map they produce exposes mismatches, vacancies and overlaps. Velocity is then a separate design pass: classify decisions in advance so predictable ones are pre-authorised, validated continuously and funded by envelope. Delegation, done this way, is not an act of trust. It is a structure you can draw.
Cheat Sheet — All the key terms
| Term | What it names | The fix it points to |
|---|---|---|
| Decision Vacuum | Nobody is certain who holds authority, so nobody decides | Assign the cell an owner |
| Decision Collision | Two parties decide the same thing independently | Resolve the authority overlap on the map |
| Decision Gravity | Every decision pulls upward regardless of altitude | Push authority back down to correct altitude |
| Decision altitude | How wide a decision's consequence reaches | Enterprise · Domain · Team · Individual |
| Decision domain | Which concern the decision belongs to | Investment · Standards · Platform · Integration · Implementation · Security |
| Altitude mismatch | A decision made at the wrong altitude | Ungoverned decisions, or governance bottlenecks |
| Domain vacancy | A domain with no owner at any altitude | Conflict the moment the decision becomes necessary |
| Pre-authorisation | Defining in advance what is already allowed | Removes waiting for predictable decisions |
| Continuous validation | Validating when the decision is made | Replaces batch governance review |
| Funding envelope | A budget boundary for a decision class | Replaces per-decision funding gates |
How to know if this landed
You will know this has landed when someone stops escalating a decision and starts asking "who owns this?" — and finds the answer on a map rather than in a meeting. When a new initiative begins by identifying the decision classes it will require and confirming the authority owner before work starts. And when the architecture board's agenda contains only enterprise-altitude decisions.
What changes when the mental model clicks
Leadership teams range from startups with flat structures to enterprises with seven management layers. The gap at the start is rarely intent — everyone wants clarity. It is not having a framework for deciding who decides.
Teams stop treating decision rights as implicit and start treating them as explicit. The mapping exercise is usually the moment things click: people realise they have been holding managers accountable for decisions they had no authority over. Decisions get faster. Escalations drop. And "slow management" stops being the diagnosis when the real problem was that nobody clarified authority.
Where this comes from
This module develops the arguments in Decision Rights for Technology — Who Decides What in a Modern Enterprise and Decision Velocity Is Not a Leadership Problem. It Is an Architecture Problem., and runs alongside the Organizational Leadership & Distributed Decision Rights Workshop.
Book a Workshop
Ready to replace your escalation ladder with a decision rights architecture?
or
1-day intensive workshop includes a current-state decision inventory, decision rights mapping by altitude and domain, gap and overlap identification, and decision classification for velocity.