DECISION ARCHITECTURE RESET
When ownership, scale, strategy or operating structure changes, the old decision system can remain in place long after it has stopped fitting the organisation. A reset restores authority, evidence, escalation and closure to the level where work now occurs.
Reset the decision system when the organisation has changed but authority has not.
Decision architecture becomes unstable after events that alter responsibility faster than governance: rapid scale, founder transition, acquisition, international expansion, a new matrix, a new executive team, capital entry, portfolio expansion or a strategic shift. The visible symptom is often slowness. The structural cause may be that the old ownership of decisions no longer matches the work.
A reset is not a blanket decentralisation exercise. Some decisions should move downward; others need stronger central authority because risk or coherence has increased. The objective is to place each material decision where the necessary accountability, evidence and execution proximity can coexist.
Map actual decisions, not job descriptions.
Organisation charts show reporting relationships. They rarely show how the organisation really commits resources, approves products, changes prices, hires leaders, selects suppliers, enters markets or resolves exceptions. A reset therefore begins with a decision inventory.
For the most consequential recurring decisions, record: what is being decided; who currently recommends; who believes they decide; who can veto; what evidence is required; which forum is used; how long closure takes; where escalation occurs; and whether the decision is frequently reopened.
McKinsey's decision research repeatedly finds role ambiguity, overreliance on consensus and committee congestion among the causes of slow or poor decisions. Bain's RAPID work makes the same underlying point with a different role vocabulary: major decisions need explicit accountability for recommendation, input, agreement, decision and execution.
Give each decision a clear route from recommendation to execution.
Virgili Studio's Decision Architecture distinguishes five roles because they solve different governance problems:
The discipline is not the labels themselves. It is to prevent the roles from collapsing into one another. Validation is not a hidden veto. Input is not shared decision authority. Execution accountability does not automatically confer the right to redefine the decision after closure.
Decision location should also reflect type. High-risk strategic commitments often require concentrated authority and robust debate. Cross-functional decisions require coordination among the few stakeholders whose information materially changes the answer. Reversible, lower-risk operational decisions should generally sit closer to the work, with thresholds that define when escalation is necessary.
Authority without an evidence standard creates arbitrary decisions; evidence without authority creates analysis without closure.
For each decision class, define the minimum evidence required before the decider can reasonably close it. A product decision might require prototype, cost, margin, supplier and commercial evidence. A market-entry decision might require strategic fit, capital requirement, operating capability and risk. The standard should be proportional to reversibility and consequence.
Escalation should be equally explicit. A decision should move upward because a defined threshold has been crossed — capital, legal risk, strategic exception, reputational exposure, cross-unit conflict — not because the current owner is uncomfortable carrying accountability.
Leaders preserve delegation when they distinguish material exceptions from normal judgement under uncertainty.
A decision architecture is real only when behaviour changes.
A static rights matrix will not reset an organisation. Activation requires the redesigned roles to be used on real decisions, in the real forums, with the real evidence. Meetings should be redesigned around decision classes rather than inherited calendars.
Executors should understand the decision when it is made, not receive a stripped-down instruction later. Deciders should see whether their choices can be implemented. Validators should raise material issues before closure rather than reopen decisions afterwards. This is where governance becomes operating rhythm.
Redesign the forum around closure.
For every recurring governance forum, define: what class of decision belongs here, who decides, what pre-read is required, what constitutes closure, and how the decision is recorded. If a meeting cannot answer those questions, it is probably an information exchange rather than a decision forum.
Preserve the rationale so the organisation does not become dependent on memory.
Decision records should capture the decision, owner, date, evidence considered, relevant constraints, rationale, execution commitments and any explicit review trigger. The purpose is not bureaucracy. It is to prevent the same organisation from repeatedly paying to reconstruct why a material choice was made.
Review the architecture when the operating condition changes again or when evidence shows recurring congestion: decision lead time rises, escalations concentrate at the top, decisions reopen, or execution repeatedly disputes what was agreed.
Recent decision-rights research also warns against treating role frameworks as sufficient on their own. Decision framing, interaction quality, evidence and execution context matter. A reset should therefore be judged by behaviour and outcomes — not by whether every box in a matrix has been filled.