Delegation vs. abdication.

Delegation moves the decision. Abdication only moves the work. If the person doing the task still has to check with you before they can act, you delegated nothing. You just added a step.

Because you still get to say yes or no at the end. The risk of a bad call feels contained. In practice it is the opposite. The person doing the work stops thinking, because the thinking is not theirs. Quality drops. Speed drops. And every task still costs you a decision.

Three things, in order:

1. The decision itself, named. Not "handle client requests." "Approve any change of scope under $2k without asking me."
2. The rule they use. One or two lines. When to say yes, when to say no, when to escalate. If you cannot write the rule, you are not ready to hand off the decision, which is fine, but say that out loud.
3. The feedback loop. Not approval before the fact. Review after the fact. Once a week, look at the calls they made. Talk about the ones you would have made differently. Update the rule.

The first bad call the person makes. This is the fork. If you take the decision back, you are back to abdication for the next year. If you sit with them, walk through what changed, and update the rule, they get better and the decision stays with them. Every founder who has cleared the bottleneck has done this at least once and hated it.

Sometimes the person genuinely cannot make the call yet. That is a different question, and it is covered in when to bring in operator help. Handing a decision to someone without the judgment for it is not delegation either. It is the same problem in a different direction.

Write down the three decisions you were pulled into most last week. For each one, name who should own it, the rule they use, and when they escalate. That is a page of writing. It is also, in most small firms, the difference between a team that runs and a team that waits.

If you want help figuring out which decisions to move first and to whom, a Friction Audit is built around that question.