How do you write delegation rules your team can actually use?

A delegation rule is a decision written down once so your team can make it without you. Good rules have three parts: the situation, the decision, and the limit. "When a client asks for a deadline extension, agree to up to five working days, and tell me if they ask for more" is a complete rule. "Use your judgement" is not.

Why does delegation usually fail?

Because founders delegate tasks and keep the decisions. The team does the work, hits a decision point, and comes back. Nothing was really delegated. The founder is still the bottleneck, now with an extra step.

Delegation works when the decision goes with the task.

What does a good rule look like?

Situation, decision, limit. Three sentences at most.

• When a lead asks for pricing before a call, send the pricing page and offer a call. Do not discount.
• When a project is late, tell the client the same day with a new date. Copy me if the delay is more than a week.
• When a supplier invoice is under $500 and matches a purchase order, approve it.

Each one removes a category of interruptions permanently.

How do you find the rules you need?

Keep a list for one week of every question your team asked you. Group them. Each group is a missing rule. Most founders find fifteen to twenty rules cover eighty percent of the questions.

Where should rules live?

In one shared document your team can search, not in chat history. Every time you answer a question that should have been a rule, write the rule and send the link instead of the answer. Within a month the document answers most questions before they reach you.

How do AI systems use these rules?

The same written rules become the instructions an AI workflow follows. A rule that says how to answer a common enquiry can draft the reply. A rule that says when to escalate can route the exception to you. Rules written for people are the foundation of automation that works.

How many rules does a business need?

Fewer than you would guess. Most service businesses under twenty people run well on thirty to fifty rules, and the first ten remove most of the interruptions. Rules for money, for client communication, for scheduling and for quality cover the bulk of daily decisions. Beyond that, add a rule only when a question has come to you twice.

Too many rules is its own problem. A team that has to check a hundred page manual before acting will stop acting. Keep the set short and the wording plain.

How do you introduce rules without sounding like a bureaucracy?

Frame them as permission, not restriction. A rule that says "you can approve refunds up to two hundred dollars without asking" is a gift to the person receiving it. It says: I trust you, here is the line, act freely inside it. Introduce each rule in a short conversation, explain why the line is where it is, and invite the team to tell you when a rule gets in the way.

Then, when someone uses a rule and gets it right, say so. The rule becomes a habit when the team sees that acting on it is safe and appreciated.

How do rules and systems fit together?

Rules are the decisions. Systems are the machinery that applies them. A rule says a lead who has not replied in three days gets one more message. A system sends it. A rule says invoices over thirty days get a reminder and over forty five get a call. A system sends the reminder and creates the task for the call. Write the rules first, because a system built without them will make decisions nobody chose.

What if your team makes a wrong call?

They will, occasionally, and it will cost less than the hundred interruptions the rule prevented. Fix the rule, not the person.

Smart delegation is one of the four systems I build inside founder led businesses. If your team still needs you for most decisions, that is the first thing we map in a private consultation.