What decision architecture actually means in practice

The term decision architecture gets used in consulting circles often enough that it has started to lose meaning. This article is an attempt to restore some precision to it, based on eight years of doing this work with leadership teams in professional services, logistics, and public-sector adjacent organisations.

What the term actually means ¶

Decision architecture refers to the structural conditions under which decisions are made in an organisation. That includes: who has authority to decide what, what information reaches them and in what form, what the decision criteria are and whether they are explicit, and what happens after a decision is made. It is not about the quality of individual decisions. It is about the system that produces them.

A useful analogy is building design. The architecture of a building does not determine what happens inside it, but it shapes what is easy and what is difficult. A building with no common spaces makes collaboration harder. A building where the CEO's office is on a separate floor from the rest of the team shapes communication in ways that no policy document can fully override. Decision architecture works the same way.

The most common structural failures ¶

In most organisations, the biggest structural failure is not that decisions are made badly. It is that it is unclear who is supposed to make them. Authority is distributed across roles in ways that made sense at a previous stage of the organisation's growth, and nobody has updated the map. The result is that decisions either get escalated unnecessarily, or they get made by whoever happens to be available, or they do not get made at all.

The second most common failure is information asymmetry. The people with decision authority do not have the information they need, and the people with the information do not have the authority to act on it. This is not a communication problem. It is a structural problem, and it requires a structural solution.

• Unclear decision authority across roles
• Information reaching the wrong people in the wrong format
• No explicit decision criteria for recurring choices
• Decisions made but not recorded or communicated
• Escalation paths that bypass the people with relevant knowledge

What an audit actually involves ¶

A Decision Architecture Audit at Logi Mastery runs over four to six weeks. The first two weeks are spent on stakeholder interviews: structured conversations with the people who make decisions and the people who are affected by them. The questions are designed to surface the gap between the formal process and the actual one.

The output is a written report. Not a slide deck. A document that can be read, annotated, and acted on without Oliver in the room. The recommendations are prioritised: the three changes most likely to have the largest effect on decision quality, followed by a longer list of secondary improvements.

If you are not sure whether your organisation has a decision architecture problem, the question to ask is this: when a significant decision needs to be made, do the right people know it is theirs to make? If the answer is not immediately obvious, that is usually the answer.