Systemising Decisions, Not Just Tasks

You can document every process, hire well, and still be the bottleneck — because the work keeps stopping at a decision only you make.

Should we take this client? Can I refund this? Is this discount okay? Should I bring in a contractor for this? Each one is small. Together they mean nothing finishes without passing through you, which is a different constraint from execution capacity and it doesn't respond to hiring.

Documenting tasks removes execution work. Documenting decisions removes the waiting.

Find the recurring ones

Not every decision is worth a rule. Look for the ones that recur.

For two weeks, note every decision someone brings you. Just a line each. Then sort:

• How often? Weekly is a candidate. Twice a year isn't.
• How much does it vary? If your answer is nearly always the same, that's a rule waiting to be written.
• What does the wait cost? A decision that holds up client work costs more than one that holds up an internal task.

The pattern is usually obvious after a fortnight, and it's usually four or five decisions accounting for most of the interruptions.

Write the rule from what you actually decided

The mistake is writing rules from principle. You end up with something that sounds right and doesn't match your own behaviour, so people follow it and you overrule them — which teaches everyone the rule isn't real.

Look backwards instead. Take the last ten times this decision came up. What did you actually decide, and what drove it?

Last ten refund requests: approved eight. The two I declined were both outside 30 days and the work had been delivered and accepted. The eight I approved were all inside 30 days, or genuine delivery failures regardless of date.

That's a rule, extracted rather than invented:

Refunds. Approve any refund request inside 30 days, or any request at any point where we failed to deliver what was agreed. Outside 30 days with work delivered and accepted: decline, and offer a credit toward future work instead. Escalate anything above £2,000 or where the client is threatening a public complaint.

The three parts

Every workable rule has all three. Miss one and it stops functioning as a rule.

A threshold. The number or condition that separates cases. Under £200, inside 30 days, fewer than three revisions. Without a threshold you've written a sentiment.

A default. What happens when the threshold is met — and it must be an action, not "use judgement." The default is what removes the wait.

An escalation point. When to come to you anyway. This is what makes people comfortable using the rule: they know where its edge is, so they're not guessing about whether this case is one you'd want to see.

DISCOUNTS
  Threshold:  Up to 10% on a first engagement
  Default:    Approve it, note it on the record
  Escalate:   Above 10%, or any discount on a renewal

Three lines. It removes a category of interruption permanently.

Delegate the decision, not the recommendation

A common half-measure: people bring you options instead of questions.

That's an improvement, and it's still a queue with you at the end of it. The work still waits, you still context-switch, and the person still hasn't learned to decide.

Move along the decision levels deliberately:

| Level | Sounds like | |---|---| | Ask me | "What should we do about this?" | | Recommend | "I think we should do X — okay?" | | Decide, tell me first | "I'm going to do X unless you object" | | Decide, tell me after | "I did X, here's why" | | Decide | It's in the rule; no notification needed |

Most decisions that have a written rule should sit at the bottom two. If someone is following a rule and still notifying you every time, the rule isn't doing its job.

Move one decision down one level at a time, and say explicitly that you're doing it.

What should never become a rule

Four categories where a rule produces worse outcomes than judgement:

Rare decisions. Writing a rule for something that happens twice a year costs more than the decisions do, and the rule will be stale by the second occurrence.

Expensive and irreversible. Large spending, hiring, firing, taking on debt, ending a client relationship. Keep these, and be honest that they're yours.

Strategy. Direction, positioning, what you don't do. These are the decisions the business exists to make well.

Anything where the answer depends on relationship context you can't write down — how much latitude to give a long-standing client, whether this particular person needs a conversation rather than an email.

For the last group, a playbook — principle, options, escalation — works where a rule wouldn't.

Review the escalations

The rule's edge is where the learning is.

Once a quarter, look at what got escalated. Two questions:

Did the escalations need to come to me? If you approved every single one without hesitation, the threshold is too tight. Loosen it.

Did anything go wrong that the rule allowed? Then the threshold is too loose, or a condition is missing. Tighten it and say why.

A rule that never gets escalated is either perfect or nobody's using it. Check which.

When someone gets it wrong

The response to a bad decision made under a rule determines whether the rule survives.

If you overrule someone who correctly applied the rule, you've taught everyone that the rule is provisional and the real answer is still to ask you. That undoes the whole exercise.

Two better responses:

• They applied it correctly and the outcome was bad → the rule needs changing. Say so, change it, and back the decision they made.
• They misapplied it → the rule is ambiguous. Clarify the wording rather than the person.

Both fix the system. Neither requires anyone to be told off, and both keep the rule credible.

The mistakes

1. Writing rules from principle. They won't match your behaviour, and you'll overrule.
2. No threshold. A sentiment, not a rule.
3. "Use judgement" as the default. That's the thing you were trying to remove.
4. No escalation point. People won't use a rule whose edge they can't see.
5. Stopping at recommendations. Still a queue with you at the end.
6. Overruling correct applications. Teaches everyone the rule is fiction.

What to do next

For the next two weeks, note every decision someone brings you. Take the one that recurs most and write the three lines — threshold, default, escalation — from your last ten actual decisions rather than from principle.

That single rule usually removes more interruption than any amount of task documentation.