Chapter 23 — Designing the Decision Surface

Chapter 23 — Designing the Decision Surface

The Question Chapter 22 Left Open

Chapter 22 established the minimal structural unit of a decisive organisation: one owner, one window, one binding outcome. Every question that enters the governance architecture must have a holder with genuine operational ownership — decision rights, trade-off authority, and concentrated accountability — before the consultation begins.

This raises a question that the minimal structural unit does not itself answer.

Which questions enter the governance architecture?

The answer is not all of them. It cannot be. An organisation that routes every question — every technical choice, every design decision, every architectural judgement, every pattern selection — through a formal governance process with a named holder, a defined window, and a designed escalation trigger has not designed a governance architecture. It has designed a governance bottleneck. The process that was supposed to accelerate convergence by giving ambiguity a lifespan has become the source of the latency it was built to prevent. Every question is waiting for governance. Governance is waiting for every question. Nothing moves.

The governance architecture of Part Two produced this outcome through a different mechanism — not by routing all questions through formal process, but by allowing all questions to accumulate in informal process. The infrastructure of indecision created governance structures that inserted prerequisites at every stage, not because every question required governance but because the structures had no mechanism for distinguishing the questions that required it from the questions that did not. Every question was a candidate for escalation. Every escalation was a candidate for broader consultation. The governance architecture expanded to accommodate the questions that should not have been there and failed to serve the questions that should.

The design response is the decision surface — the explicit architecture of where questions are resolved, by whom, under what conditions, and with what escalation path when the resolution cannot occur at the designed altitude.

Not every question deserves governance. The decision surface is the designed specification of which ones do — and which ones do not.

What a Decision Surface Is

A decision surface is not an organisational chart. It does not show who reports to whom or which function has authority over which domain. It shows something more operationally precise: the altitude at which each class of decision is designed to be resolved, the conditions under which a decision at one altitude escalates to the next, and the boundary below which decisions are made locally without requiring the governance architecture's involvement.

The Velocity Architecture Framework names this placement precisely: Decision Altitude — the governance level at which a decision is made and owned, matched to the consequence it carries. Correct altitude produces fast, bounded decisions with clear accountability. A question resolved at too low an altitude is resolved without the authority and cross-domain context the trade-off requires. A question resolved at too high an altitude consumes governance capacity that the consequence does not justify — and sends a signal to every level below that local authority is insufficient, which over time produces the escalation-as-default behaviour that Chapter 18 described. Decision Altitude is not a positional concept. It is a consequence concept. The altitude is not determined by the seniority of the person asking. It is determined by the scope and reversibility of the answer required.

The concept of altitude is important and worth developing precisely. Altitude, in the context of the decision surface, refers to the scope of consequence — the range of the organisation that a decision affects and the duration over which its effects compound. A decision that affects a single service within a single team for a single sprint has low altitude. A decision that affects the integration architecture across multiple domains for the next three years has high altitude. The decision surface maps each class of decision to the altitude at which it should be resolved — the altitude where the authority to accept the trade-off, the context to understand the consequence, and the accountability to own the outcome are all present simultaneously.

This mapping is the work that most governance architectures have never done. They define governance forums at various levels — programme governance, domain governance, enterprise governance, executive governance — without specifying which questions belong at which level. The result is that questions find their altitude not through designed routing but through political gravity — they escalate to the level where the stakeholder with the strongest interest in the outcome has sufficient standing to convene a forum. The altitude of the question reflects the power of the stakeholder who raised it, not the consequence of the question itself.

The decision surface replaces political gravity with structural design. Questions are routed to their altitude not because a stakeholder with sufficient standing initiated the escalation but because the question's characteristics — its consequence, its reversibility, its cross-domain implications, its downstream dependencies — match the designed criteria for the altitude at which it belongs.

The Four Altitudes

The decision surface requires at minimum four distinct altitudes, each with a defined class of decision, a defined holder function, a defined window, and a defined escalation path. The specific number of altitudes will vary across organisations of different scales and structures — a large regulated enterprise may require six or seven, a smaller technology organisation may function effectively with three. But four provides the minimal viable architecture for most organisations of moderate complexity.

Altitude One: Team-level decisions. Decisions that are reversible within a sprint, affect a single team or service, do not cross domain boundaries, and do not require trade-offs that exceed the team's granted authority. These decisions are made by the delivery team without formal governance involvement. The holder is the team lead or the architect embedded in the team. The window is the sprint or the delivery cycle — the decision is made when it is needed, recorded in the team's decision log, and does not require escalation unless it reveals a constraint that exceeds the team's scope.

The boundary condition for Altitude One is scope, not permission. Teams can decide freely within their domain. When a decision crosses a boundary — touches another domain's data, adopts a pattern not previously validated in the estate, carries implications beyond the sprint's horizon — it is not a team-level decision regardless of how simple it appears. The simplicity of the decision is not the criterion. The scope of its consequence is.

Altitude Two: Domain-level decisions. Decisions that cross service boundaries within a domain, adopt new patterns within established constraints, affect multiple teams within the same capability area, or require trade-offs between competing priorities within the domain's scope. The holder is the domain architect or equivalent — a named individual, not a forum. The window is defined in advance for this class of decision: typically forty-eight to seventy-two hours for decisions within established constraints, up to five days for decisions that require pattern validation against the estate.

The critical design property at Altitude Two is the requirement that the holder decides rather than defers. The domain-level holder who receives a question must produce a binding outcome within the defined window — or escalate explicitly, with the question compressed to the specific trade-off that the domain level cannot resolve unilaterally. Deferral — the extension of the window without escalation, the accumulation of further consultation, the maintenance of the question in an open state past the designed window — is itself the escalation trigger. The holder who does not decide within the window has produced the condition that the escalation mechanism was designed to address.

Altitude Three: Enterprise-level decisions. Decisions that cross domain boundaries, establish new patterns for the estate, conflict with existing constraints, or carry regulatory, security, or commercial implications that exceed any single domain's authority. The holder is a named individual within the enterprise architecture function — again, not a forum — with the explicit mandate to make binding decisions about the organisation's technology direction at the level of the whole. The window is typically five to ten business days. The outcome is documented in the constraint record and the decision log, visible to all domains as binding direction.

Altitude Three is where the governance architecture described in Part Two most consistently fails. The enterprise-level question that requires a binding outcome from a named individual with concentrated authority is the question that the governance architecture routes instead to an enterprise governance forum — a body that produces recommendations, endorses directions, and notes risks without producing the binding outcome that the question requires. The design of Altitude Three must specify explicitly that the holder is an individual, not a forum, and that the forum's role — if a forum exists at this level — is consultative rather than decisional. The forum informs. The holder decides.

Altitude Four: Executive trade-off decisions. Decisions where a binding architectural constraint conflicts directly with a business priority — revenue, regulation, strategic commitment, contractual obligation — that the architecture function does not have the authority to resolve unilaterally. These decisions cannot be resolved within the architecture function. They require an executive holder to make an explicit trade-off and own the consequence. The window is ten business days. The outcome is documented as an executive decision with named ownership, explicit trade-off acknowledgement, and defined review criteria.

The critical design property at Altitude Four is the escalation path's specification in advance. Not escalate to leadership — a direction so vague that the escalation can be absorbed by the same political gravity that routes all questions to the level of the most powerful stakeholder. A specific role, a specific process, and a specific time boundary. Without this specification, Altitude Four questions dissolve into the second failure mode of Chapter 14 — the authority holder who retreats from the threshold of commitment into the vocabulary of virtuous avoidance, convening a broader stakeholder group rather than making the trade-off the executive position requires.

The Boundary Below Altitude One

The four altitudes describe the governance architecture's decision surface. But the design of the decision surface is incomplete without the specification of the boundary below Altitude One — the threshold below which decisions are made locally without any governance involvement, without a formal holder function, without a defined window, and without an escalation trigger.

This boundary is the most important and most consistently undesigned element of the decision surface. Its absence is responsible for a significant proportion of the governance overhead that organisations attribute to the complexity of their technology estate and that is actually the product of the governance architecture failing to specify which decisions do not require it.

Every decision that crosses the undesigned boundary — every technical choice, every pattern selection, every service design decision that is routed to governance because there is no designed criterion for keeping it below governance altitude — consumes governance capacity that should be reserved for the decisions at Altitudes Two through Four. It fills the escalation pathways with questions that the delivery teams should have the authority and the context to resolve locally. It trains delivery teams to route decisions upward as a default rather than as a designed response to a genuine scope exceedance. And it produces the governance overload that the infrastructure of indecision's multiplication of forums was designed to manage — at the cost of the governance architecture's capacity to serve the questions that genuinely require it.

The boundary below Altitude One must be specified explicitly and generously. Not so broadly that decisions with genuine cross-domain or cross-programme implications are kept below governance altitude. But broadly enough that the vast majority of the technical decisions that delivery teams make in the course of normal programme execution are made by the teams that hold the context and the accountability for the programme, without the governance overhead that routing them upward produces.

The specification of this boundary requires answering a question that most governance architectures have never asked: what is the minimum consequence threshold that justifies governance involvement? Not the maximum — the minimum. The question is not what the governance architecture should be able to handle. It is what delivery teams should be empowered to handle without it.

The answer is different for every organisation and every domain. But the specification must exist. A governance architecture without a designed lower boundary is a governance architecture that will fill itself with the questions that delivery teams cannot make without governance involvement — which, in the absence of the boundary, is all of them.

The Autonomy That the Decision Surface Enables

The design of the decision surface is often experienced, initially, as a constraint on delivery autonomy — as the governance architecture claiming more of the decision-making space rather than less. This experience is the opposite of the truth, and the misperception deserves a precise correction.

The decision surface enables autonomy. It does so by making the boundaries of local authority explicit rather than implicit — by telling delivery teams not what they cannot decide, but what they can decide without governance involvement.

The delivery team operating without a designed decision surface is not operating with full autonomy. They are operating with unlimited ambiguity about the scope of their authority. Every decision they make is a potential governance violation — a choice that may later be characterised as exceeding their mandate, as bypassing the governance process, as failing to escalate a question that should have been elevated. The rational response to this ambiguity is the same response that the incentive geometry of Chapter 13 describes at the organisational level: maintain optionality, avoid specific commitments, route questions upward rather than downward.

The decision surface changes this calculation fundamentally. When the boundary below Altitude One is specified explicitly and generously, the delivery team knows what they can decide. They do not need to route every design choice through governance to avoid the risk of a later characterisation as having exceeded their authority. They make the decisions that are theirs to make, record them in the team's decision log, and escalate only when the question's characteristics — its scope, its consequence, its cross-domain implications — match the designed criteria for a higher altitude.

This is the autonomy that genuine governance enables: not the freedom to make any decision regardless of consequence, but the freedom to make every decision within scope without the friction of governance overhead that was never designed to serve decisions of this type. The decision surface is the mechanism that makes this freedom structural rather than cultural — not dependent on the goodwill of governance forums or the interpretive generosity of the architects who manage them, but specified in the design of the governance architecture and enforced through the criteria that define each altitude.

What Over-Centralisation Costs

The governance architecture without a designed decision surface defaults, under the conditions of Part Two, to over-centralisation — the routing of decisions to higher altitudes than their consequence requires. The effects of over-centralisation are the same as the effects of high decision latency, because over-centralisation is one of the primary mechanisms by which decision latency is produced.

Delivery teams wait for governance decisions that they should have the authority to make locally. The governance forums that should be serving Altitude Three and Four questions are occupied by Altitude One and Two questions that have been routed upward in the absence of a designed lower boundary. The senior holders who should be compressing cross-domain trade-offs are engaged with single-domain questions that the domain architects below them should be resolving. The escalation pathways that should be reserved for questions that genuinely exceed lower-altitude authority are filled with questions that the design of the decision surface should have kept below governance altitude.

The cost of over-centralisation is paid in the same currency as the cost of high decision latency: rework, drift, structural debt, and the gradual attrition of the high-performing practitioners who have learned that the governance architecture is not designed to produce what it claims to produce. The delivery team that cannot make a technical choice without a governance review does not experience this as appropriate oversight. They experience it as an indication that the organisation does not trust them to make the decisions that their role was supposed to empower them to make. And they adapt — by routing decisions upward as a default, by waiting for governance rather than consulting it, by reducing their investment in the quality of their own decision-making because the governance architecture will either override or ignore it regardless.

The design of the decision surface is the structural response to over-centralisation — not by reducing governance, but by designing it. By specifying the altitude at which each class of decision belongs and enforcing that specification consistently enough that delivery teams can trust the boundary and operate freely within it.

The Decision Surface as Constraint That Enables

The Velocity Architecture Framework's design principle for the decision surface is the same design principle that Chapter 19 established for guardrails: constraint that is visible, specific, and enforced enables autonomy. Constraint that is invisible, general, and discretionary produces the paralysis it claims to prevent.

The governance architecture without a designed decision surface is a governance architecture with invisible, general, discretionary constraint. Every decision is potentially in scope. Every choice is potentially a governance question. The constraint is everywhere and nowhere — too vague to specify what is out of scope, too broad to specify what is within it, too discretionary to be consistently applied without the political gravity that routes questions to the altitude of the most powerful stakeholder rather than the appropriate one.

The governance architecture with a designed decision surface is a governance architecture with visible, specific, enforceable constraint. The altitudes are specified. The criteria for each altitude are clear. The boundary below governance involvement is explicit and generous. Delivery teams know what they can decide. Holders know what they are accountable for. Escalation pathways are reserved for questions that genuinely require them.

This is the design that makes velocity possible at scale. Not the absence of governance — the design of governance that is precise enough to serve the questions that require it without consuming the capacity of the teams and the authority structures that should be making everything else.

The decision surface is not a constraint on the organisation's capability. It is the structural condition under which the organisation's capability can actually function.