You hired the person. You wrote the process doc. You even sat with them for a week. And you're still getting messages that start with "quick question — can I approve this?"
That's not a people problem or a training problem. It's a delegation problem with a specific shape: you handed over the task but kept the judgment. The clicking moved. The deciding didn't. And deciding is what was eating your calendar in the first place.
Tasks Are Cheap to Hand Off. Decisions Aren't.
Tasks are easy to describe. "Create the quote in the CRM." "Reconcile the statement." "Order the parts." You can show someone once and they'll get it.
Decisions are different, because the real content lives in your head as a set of unwritten conditions. How much discount is fine without asking. When a rush order is worth the overtime. Which customer complaints get a refund and which get an explanation. Which vendor you use when the usual one is backed up.
Nobody wrote those down, because to you they aren't rules — they're just obvious. So your team does the only safe thing available to them: they ask. Every ask is a small tax on your attention, and the sum of those taxes is why the business still can't run a week without you.
What a Decision Rule Actually Contains
A usable decision rule is more than a policy sentence. It needs enough structure that a competent person who has never met you can act on it alone:
- The trigger — the specific situation that invokes the rule, described in terms someone can recognize in the moment.
- The default action — what happens if nobody intervenes. Most rules fail because the default is "stop and ask."
- The boundary — the dollar amount, discount percentage, lead time, or risk level inside which the person decides alone.
- The escalation path — who gets it when the boundary is crossed, and how fast they need to respond.
- The record — where the decision is logged so you can review a batch of them later instead of each one live.
That last one matters more than people expect. You don't give up control when you delegate a decision; you move your review from before the fact to after the fact, in bulk. That's the whole trade.
Mine Your Inbox for the Rules You Already Have
You don't need a strategy offsite to find your decision rules. You need two weeks of your own messages.
Go through the approvals, the "what should I do here" questions, and the exceptions people brought you. Group them. You'll find the same five or six questions wearing different costumes: pricing exceptions, credit terms, refunds, scheduling conflicts, spend above some fuzzy line, hiring a temp.
For each cluster, write down what you actually decided and why. Be honest about the threshold — if you approved everything under a certain amount without thinking twice, that's the boundary. The rule already exists. You're just transcribing it.
Put the Rule Where the Work Happens
A decision rule in a wiki is a suggestion. A decision rule in the system is how the business works.
This is the part most operators skip. Your ERP, CRM, and project tools already support approval limits, routing rules, discount ceilings, required fields, and status gates. Configured properly, the system allows the decision inside the boundary without ceremony and routes it automatically when it crosses the line. Nobody has to remember the policy, because the policy is the path of least resistance.
This is also where fragmented tooling bites. If quoting lives in one place, approvals in email, and spend in a spreadsheet, the rule can't be enforced anywhere — which is exactly why unifying the stack into one hub tends to do more for owner independence than another round of process training.
Written Rules Are What Make AI Useful Here
There's a bonus that catches people by surprise. Once your decision rules are explicit — trigger, default, boundary, escalation, log — they become the exact artifact an AI system needs to help.
An assistant can draft the response, pre-fill the approval with the relevant history, flag the ones near a boundary, or summarize last month's exceptions so you can spot a rule that needs updating. None of that works when the rule lives only in your judgment. Humans that use AI win, but the AI needs something to stand on, and written decision rules are the sturdiest foundation you can hand it.
How You'll Know It's Working
Watch three things over a quarter. Are fewer decisions being escalated to you? When you review the decisions made without you, how often would you have chosen differently? And how long does an average decision sit before someone acts on it?
If escalations drop, disagreements stay rare, and cycle time shortens, the rule is good. If you're reversing decisions often, the boundary is wrong or the rule is ambiguous — fix the rule, not the person.
A business that runs without the owner isn't one where the owner stopped working. It's one where the owner's judgment was written down, encoded in the systems, and made available to everyone who needs it at the moment they need it.
If you're still the bottleneck on decisions your team should be making, that's usually a systems configuration problem as much as a management one. We'd be glad to walk through where your rules should live. Reach out and let's map it.