Across this series, three authority failure modes have appeared repeatedly.
The first: ownership exists but authority does not. People are named as accountable for outcomes they cannot influence. They hold responsibility without the structural conditions to exercise it.
The second: authority exists but responsibility is deflected. When a trade-off requires a binding call, the authority holder retreats to facilitation. Workshops are convened. Collaboration is invoked. The decision returns to the team that escalated it.
The third: authority exists and is exercised — but in the wrong direction. Leaders push forward when the system is signalling stop. Delivery absorbs the cost. Architecture becomes theatre.
Each failure mode was examined individually in the preceding posts. What this article addresses is the design question those posts left open: not what goes wrong with authority, but how to build authority structures that do not produce these failure modes under pressure.
What Authority Design Actually Is
Authority design is the deliberate specification of who can make which decisions, under what conditions, with what consequences for deviation.
It is not an org chart. Org charts show reporting lines. Authority design shows decision rights — which are not the same thing.
It is not a RACI. RACI models show who is Responsible, Accountable, Consulted, and Informed. Authority design is more specific: it shows who can commit the organisation to a direction, who can override a constraint, who can pause work, and what the conditions are for each. RACI tells you who to involve. Authority design tells you who decides when involvement produces disagreement.
It is not consensus. Consensus is the absence of authority design — the default state when no one has been given the explicit right to make a binding call. Consensus feels inclusive. Under delivery pressure, it produces the second failure mode: authority deflected into facilitation.
Authority that cannot be exercised under pressure is not authority. It is a title with conditions attached that make it unusable precisely when it is needed.
A pilot owns the flight. The ground mechanic owns the airworthiness. When the mechanic says the engine is failing, the pilot does not negotiate based on the arrival time. The passengers do not vote. The schedule does not override the structural assessment. The mechanic is not senior to the pilot in the hierarchy. But on the question of whether the aircraft is safe to fly, the mechanic's judgement is binding — because the consequence of overriding it is not a delayed arrival. It is a different kind of failure entirely.
Architecture authority is the ground mechanic function of the enterprise. The business owner owns the delivery. The architect owns the structural integrity of what delivery builds on. Those are not competing authorities. They are complementary ones.
The Four Levels of Architectural Authority
Level 1 — Team-Level Decisions
Decisions that are reversible within a sprint, affect a single team or service, and do not cross domain boundaries. Authority sits entirely with the delivery team. The team records the decision in its ADL and proceeds. When a decision crosses a boundary it escalates to Level 2.
Level 2 — Domain-Level Decisions
Decisions that cross service boundaries within a domain, adopt new patterns within established constraints, or have implications for other teams within the same capability area. Authority sits with the domain architect — a named individual, not a committee. The domain architect can approve, modify, or escalate. They cannot defer. Bounded answer required within 48 hours.
Level 3 — Enterprise-Level Decisions
Decisions that cross domain boundaries, establish new patterns for the estate, conflict with existing constraints, or carry regulatory or security implications. Authority sits with the EA function — a named individual or named small group with explicit decision rights, not a review board that produces recommendations. Enterprise-level decisions require documented rationale, explicit constraint reference, and a recorded outcome.
Level 4 — Executive Trade-Off Decisions
Decisions where a binding architectural constraint conflicts directly with a business priority — revenue, regulation, strategic commitment, or contractual obligation. These decisions cannot be resolved within the architecture function. They require an executive to make an explicit trade-off and own the consequence. The escalation path must be named in advance — a specific role, a specific process, a specific time boundary.
Making Authority Legible
Named Roles, Not Functions
Authority must attach to a named individual, not a function or a team. A collective can inform a decision. Multiple perspectives, multiple domains, multiple risk lenses — all legitimate and often essential. The point is not that one person holds all the knowledge. The point is that when the consultation is complete, one named person makes the call binding.
A panel is a legitimate authority structure for multi-domain decisions. It still needs a named tie-breaker — one person whose call is final when the panel cannot reach a bounded answer within the time limit. Without that, the panel produces the same deferral as a committee.
Explicit Scope Boundaries
Scope boundaries should be defined in terms of decision characteristics — reversibility, domain crossing, constraint conflict, regulatory implication — not in terms of project size or seniority of stakeholders. When scope is defined by stakeholder seniority, the decision system breaks under political pressure.
Visible Escalation Paths
Every authority level needs a named escalation path. Escalation paths that are not named in advance get improvised under pressure. Improvised escalation paths default to whoever is most senior in the room, which is not reliably the person with the best view of the consequence.
The Conditions for Authority to Be Exercised
Air Cover
Authority holders need explicit protection from the political consequences of unpopular decisions. This is not a cultural aspiration. It is a structural requirement.
There is a pattern that every architect recognises. A decision escalates. The authority holder consults. Pressure arrives to proceed. The message — spoken or unspoken — is clear: find a way to make this work. And if the architect holds the line and the project stalls, the delay is architectural. If the architect yields and the system fails six months later, the decision is architectural. The architect's name is on the recommendation either way. The people who applied the pressure are nowhere in the record.
This is not authority design. It is liability transfer. The architect is handed the appearance of a decision right and the reality of sole accountability for every outcome — positive or negative — that follows.
Earlier in this series two patterns were named that sit underneath everything this article has argued. The first: people will not document rationale because they fear being wrong on the record. The second: plausible deniability often wins over clarity. The domain architect who will not put their name on a Level 2 decision. The practice lead who agrees in the room and disappears from the record. The executive who shapes a Level 4 trade-off verbally and leaves no trace. They are not violating the framework. They are responding rationally to a system that has taught them that visibility is liability and invisibility is safety.
The framework described in this article cannot survive that calculation unchanged. It requires a different system. One where the record reflects everyone who shaped a decision. Not just the person willing to own it.
This is not a human problem. It is a design problem. And it is the design problem that everything else in this series depends on solving.
Consequence Visibility
Authority is more easily exercised when the consequence of not exercising it is visible. An architect who can show — with data — that the last three times this pattern was approved as an exception it produced significant rework and integration failures, has a structurally stronger position than an architect who can only assert that the pattern is architecturally unsound.
Time Bounds
Decisions that are not time-bounded do not get made. Every level of the authority model needs a maximum resolution time. Level 1: within the sprint. Level 2: 48 hours. Level 3: five business days. Level 4: named executive response within ten business days. Authority without time bounds is advisory.
A Level 4 escalation path that is named but not honoured is not an authority design failure. It is a measurement failure. Making the override visible is what converts political pressure from a governance bypass into a traceable executive decision.
The Architect's Position in the Authority Structure
If the architecture function is accountable for constraint integrity — for the coherence of architectural decisions across the enterprise — it needs binding authority over Level 3 decisions and a named seat in the Level 4 escalation path. The accountability and the authority must be designed together. One without the other produces either impotence or arbitrariness.
You cannot delegate accountability without delegating authority. If the architecture function is expected to own enterprise coherence, it must be able to enforce it.
The Measurement Problem
Most architecture functions are measured on output. Principles produced. Reviews completed. Frameworks published. Workshops attended. The annual report records activity not outcomes. Decision latency is not measured. Rework cost is not measured. The cost of decisions made without complete architectural context is never calculated because it is distributed invisibly across project budgets.
The result is a measurement system that cannot surface the structural failure. Leadership holds its position. The annual report is filed. Nothing changes. Not because the people involved are indifferent but because the system they operate inside was never designed to make the failure visible.
The architecture function that wants binding authority needs to change what it measures. Decision latency at each authority level. Override rates by domain. Escalation resolution times. Reduction in repeated architectural debate. These are the metrics that make architectural leverage visible — and visible leverage is the only leverage that survives budget cycles and leadership transitions.
Addressing the Objections
On compliance and audit
This model does not remove formal artefacts. It changes where they come from. A gate deliverable built from structured decision records, deviation logs, and named constraints is more defensible under scrutiny than a static document reconstructed after the fact. The auditor's question is not how thick the document is. It is whether the document reflects what was actually built. Currency is not a compliance risk. A dead artefact is.
On resourcing and bandwidth
The current system already consumes the bandwidth. It consumes it invisibly — in reconstruction meetings, repeated architectural debates, onboarding delays, and post-incident reviews that cannot trace who decided what. That cost never appears on a single line. Measuring decision latency in one domain almost always reveals that the rework tax already exceeds the cost of maintaining a structured record. The data makes the case. Start with one domain and let it.
On political reality and air cover
Air cover is a structural precondition not a cultural aspiration. The transition is incremental precisely because air cover has to be built not assumed. Waiting for perfect air cover before starting is the same pattern as waiting for consensus before deciding. It is deferral with better vocabulary.
Starting the Transition
Pick one domain where authority is currently unclear. Name the authority holder for each decision type. Define the escalation path. Communicate it to the delivery teams working in that domain.
Then measure one thing: how long does a Level 2 or Level 3 decision take from the moment it is raised to the moment a bounded answer is produced?
Authority design without constraint clarity produces decisions that cannot be checked. Authority design without deviation visibility produces decisions that cannot be learned from. The three elements are interdependent by design — which is why the transition starts with one domain where all three can be introduced together rather than in isolation.