Decision frameworks for small teams that keep revisiting the same choices

Some decisions should only be made once. If your team is relitigating the same question every quarter, the problem is not that the people are indecisive. The problem is that the criteria for the decision have never been made explicit. A decision framework is just a way of writing those criteria down.

Why recurring decisions are a process problem, not a people problem ¶

When a team keeps revisiting the same decision, the usual response is to add more process: another meeting, another approval layer, another committee. That rarely helps. The decision keeps recurring because the underlying criteria are contested or unclear, and more process does not resolve that.

The fix is to surface the criteria explicitly. What factors actually matter for this class of decision? Who has standing to weigh in? What information is needed before a decision can be made? Writing those things down, even roughly, changes the nature of the conversation from 'what should we do' to 'do we have what we need to decide'.

What a one-page decision framework contains ¶

A useful decision framework fits on one page. If it does not fit on one page, it will not be used. The page contains four things: the decision type it applies to, the criteria that matter and their relative weight, the information required before the decision can be made, and who has authority to make the final call.

The weight of the criteria is the hardest part to agree on. That disagreement is usually the real source of the recurring debate. Making it explicit does not always resolve it, but it moves the argument to the right level.

• Decision type: what class of choice does this apply to?
• Criteria: what factors matter, and how much?
• Information threshold: what do we need to know before deciding?
• Authority: who makes the final call?

How to embed the framework without a training programme ¶

A framework that lives in a shared drive is not a framework. It is a document. The difference is whether people reach for it when the decision comes up. The fastest way to embed a framework is to use it in the first real decision that falls within its scope, with the people who will use it regularly in the room.

That first use is a test. The framework will probably need one or two adjustments based on what the real decision looks like versus what you imagined when you designed it. Build in a short review after the first three uses. After that, it tends to stabilise.

The goal is not a perfect framework. It is a framework that gets used. Imperfect criteria that are applied consistently produce better outcomes than perfect criteria that sit in a document.