Decision architecture

Decision architecture describes how choices are distributed across roles, forums, thresholds and escalation paths. It is the structure that determines where decisions live before they appear as delays, conflicts or founder dependency.

In brief

Every organisation has a decision architecture, even when it has never designed one. Some decisions are local, some escalate, some are avoided, some are reopened, some are made informally.

A good decision architecture makes recurring choices clear enough that work can move without asking permission every time.

A weak decision architecture makes the process wait for authority.

Operational definition

Decision architecture includes decision categories, owners, thresholds, required information, forums, escalation paths and review mechanisms.

It is broader than decision rights. Decision rights define who can decide what. Decision architecture describes the whole system that makes those rights usable.

Why it matters for SMEs

Founder-led SMEs often operate with a centralised decision architecture by default. This works while the founder can absorb the volume. Growth turns that default into a bottleneck.

People wait because they do not know what they can decide. Managers escalate because thresholds are missing. Meetings discuss issues without authority. Decisions are reopened because review and ownership are unclear.

The company experiences this as slowness, but the cause is architectural.

Observable signals

Look for repeated escalation of the same decision category.

Look for decisions reopened after being made.

Look for meetings that discuss but do not decide.

Look for local decisions later overturned by the founder.

Look for people asking permission for low-risk choices.

Look for decisions nobody feels authorised to take.

Common mistakes

The first mistake is thinking decision quality is only about individual judgement.

The second is assigning responsibility without thresholds.

The third is creating forums without authority.

The fourth is reviewing decisions by reopening them instead of learning from them.

Operational example

A company wants faster commercial decisions. The problem is not the sales team. Discount approvals, payment exceptions and delivery commitments all have different informal paths.

The company defines decision categories, assigns owners, writes thresholds and creates a fortnightly review. Decisions inside threshold are not reopened. Out-of-threshold cases escalate through one path.

Lead time falls because the decision now has a home.

Diagnostic questions

Which decisions recur most often?

Who owns each category?

Which thresholds define local autonomy?

Where does escalation go?

Which forum can decide, and which only informs?

How are decisions reviewed after the fact?

Practical implications

Map recurring decisions. Group them by category. Define owner, threshold, information and review for each. Then align forums to decision types.

A decision forum should have a clear function: decide, review, escalate or coordinate. If the function is unclear, the meeting becomes latency.

MARTRO reading

In MARTRO’s reading, decision architecture is the hidden layer behind many process delays. The flow waits because the decision has no clear address.

This connects decision rights, governance, decision latency, stop rules and role gap.

Frequently asked questions

Is decision architecture the same as governance? It is a core part of governance focused specifically on how decisions are distributed and reviewed.

Where should SMEs start? With recurring decisions that currently escalate to the founder.

Do all decisions need formal rules? No. Start with decisions that create delay, risk or repeated conflict.

Can meetings fix decision architecture? Only if they have clear authority and decision categories.

What is the main benefit? Decisions become available to the work faster and with less ambiguity.