Delegation
Why it matters
Without delegation, the founder is the bottleneck on everything. Growth stalls at the number of hours one person can work, and the best use of their time, such as strategy and key relationships, gets squeezed by tasks others could own.
The usual failure is delegating the task but not the trust: hovering, re-checking and taking the work back the moment it looks different from how you would have done it. That costs more than doing it yourself, and the other person learns nothing.
Done well, it also builds the team. People who own an outcome learn to make decisions, and the founder gets back time for the work only they can do.
How to apply it
- Write a clear definition of done before handing anything off, so success is not a judgement you make afterwards.
- Give the person, or the system, the access and authority needed to reach the outcome.
- Agree how the result will be checked. Review the outcome, not every step taken to get there.
- Let the first attempt run before stepping in.
- Start with something reversible and low in stakes, then widen what you hand off as trust builds.
What it is
Delegation is more than handing over a task. Real delegation transfers responsibility for the result: the other party owns the outcome, decides the reversible details themselves and comes back only for the calls that cannot be undone.
It helps to think in levels. At the lowest, the person researches and reports back. Next, they recommend an action and wait for approval. Then they act and report afterwards. At the top, they act and only tell you about exceptions. A good delegator picks the level on purpose and says which one applies.
Common mistakes
- Handing over a task without the authority to complete it.
- Accepting "reverse delegation", where the problem keeps bouncing back to you.
Delegating to software
The same rules apply to automation and AI agents. Describe the outcome, grant only the access it needs, and decide in advance which decisions stay with a person. A founder who answers every refund query herself might write the refund rules once as an SOP, so a new hire can follow them. For a repetitive step such as routing incoming leads, she could build a workflow in n8n and review only the exceptions it flags.
