How to Write a Decision Rule.
How to Write a Decision Rule
Last week, the series looked at the five categories of decision that most owner-led businesses still route through the owner by default.
This week: how to stop that happening.
The answer is not “trust your team more.” It is to give them something more useful than trust. A rule.
Research on managerial overload keeps finding the same pattern: when too many decisions route through one person, decision quality drops and stress rises, even in highly capable leaders. That is not a motivation problem. It is a design problem.
Why the team keeps asking
Most owners have a clear, intuitive sense of how they would answer common questions. They know what threshold makes a client discount acceptable. They know which spend requires approval and which does not. They know when something is good enough to go out and when it needs another pass.
The team does not know any of this. So they ask.
This is not a confidence problem. It is an information problem.
In studies of information overload, managers who face a high volume of unstructured requests report higher stress levels and make slower, less accurate decisions. When the information does not exist in a form the team can access, the only rational move is to ask the person who holds it. Which is the owner. Every time.
“Use your judgement” fails because judgement needs context. Without shared context, one team member approves the spend another would have queried. One replies to a client in a way the owner would have reworded. The inconsistency creates rework. The rework creates more owner involvement, not less.
“Ask me if you are not sure” fails because it keeps the owner as the fallback. Which is the pattern the post is trying to break.
The Decision Rule
A decision rule is the owner’s unwritten answer, written down.
It does not need to be complex. In most cases, one sentence is enough. What it does need is precision.
A well-formed decision rule has three components.
Scope. What type of decision does this apply to? Be specific enough that the team knows when the rule is relevant and when it is not.
Threshold. What is the boundary that defines the answer? A number, a condition, a yes/no trigger. Something that removes the need for judgement on the standard case.
Escalation. When is it right to bring the decision to the owner anyway, and how? This is the release valve. It acknowledges that edge cases exist without making every case an edge case.
Well-designed escalation rules are not just a business fad. In safety-critical environments, clear escalation thresholds and simple steps are associated with faster response times and fewer missed issues. The same logic applies to commercial decisions: clear triggers reduce hesitation and make it obvious when something genuinely is an exception.
Three worked examples.
Purchase approvals: Any supplier spend under 250 can be approved without referral. Over 250, send a one-line message with what it is for and a response will come within 24 hours.
Client discount requests: If a client asks for a discount, none is offered proactively. If they push, a 10% reduction on the next invoice is acceptable without escalation. Anything beyond that comes to the owner.
Quality sign-off: Anything going to a client for the first time should be reviewed by [name]. Routine updates and reports follow the checklist. No additional sign-off needed.
None of these rules require sophisticated judgement. They require precision. The owner already knew the answer. The rule just makes it available to everyone else.
Result: fewer interruptions, faster decisions, and less invisible load on the owner’s head.
What makes a rule work
Precision over flexibility. A rule that says “use common sense” is not a rule. A rule that says “under 250, no approval needed” is.
It should be testable. If someone reads it and still does not know what to do, it needs to be more specific. A good test: could a new team member apply this rule correctly in their first week, with no additional guidance?
It should be written somewhere the team can find it. Not mentioned once in a meeting. Not in the owner’s head with the assumption that it was communicated. Written down, in a place that is accessible.
And it should have a version date. Rules that were right two years ago may not fit the business today. A rule that is never reviewed quietly becomes a constraint nobody questions.
There is a useful parallel here. In regulated environments, escalation protocols that are overly complicated or out of date become hard to follow in practice and are more likely to be bypassed when pressure is high. Simple, current rules are used. Complicated, stale rules are worked around.
Result: a small set of simple, current rules that are actually followed, instead of a thick manual nobody trusts.
Where to start
Take the Decision Audit from last week. Find the question that came up most often. The one that arrived two or three times in different forms.
Write the rule that would have made the answer unnecessary.
One rule. One sentence with a threshold. Tested once. Then refined.
Not twenty rules at once. That is the mistake most owners make when they finally commit to this. They try to document everything in a week and produce a manual nobody reads.
Start with the most frequent question. Get the rule right. Then move to the next. In research terms, this reduces information overload by tackling the highest-frequency decisions first, which is where the greatest relief often comes for the least effort.
This is the second of four posts in the Decision-Free Business series. Next week: the one meeting structure that removes most of the remaining interruptions and creates a predictable window for the decisions that genuinely do need the owner.
If working through this with structure and support would be more useful than building it alone over four weeks, a Clarity Call is the place to start.
