You hand a task over, and it comes back slower and worse than if you’d done it yourself. So you redo it that evening, and the lesson you take is the obvious one: faster if I do it. You may even have said the quiet version out loud once. Explaining it takes longer than doing it.
If you see yourself as faster than the people around you, that lesson feels like plain observation, and task by task it may be true. Founders know the pattern well. So does the manager who out-produces their team, and the team member stuck waiting on slower sign-off above them. It feels frustrating, but there are other ways to manage the effects. Speed and efficiency are assets. They stop being assets when carrying everything alone burns you out with frustration.
The math you’re running is wrong
“Faster if I do it” compares your time against theirs on a single task. On a single task, you win. But the comparison that matters is total output. If everything important runs through you, output is capped at what one person can produce. Hand work to others and several tasks move forward at once, even at eighty percent of your standard, while you do the few things only you can do. One person, however fast, produces less than several people working in parallel.
And the explaining-takes-longer objection is only true once. Explaining something might take longer than doing it today, but the time and expertise you put into other people develops them: each explanation makes the next one shorter, and a team you’ve developed moves more forward in parallel than you ever could alone. That is the longer-term point of delegating – you’re building the people you’ll be working with for years.
How do you delegate as a founder?
Delegate by trading short-term speed for capacity: pick one recurring task, write down what a good result looks like, and hand it over with the context you’d use to do it yourself. Review at an early checkpoint rather than at the deadline, and resist redoing the result. The first version will be slower and rougher than yours. That is the cost of building output that scales beyond your individual ability to deliver.
Founders ask this most, but the method is the same for a manager, or for anyone handing work to a peer.
A few mechanics make this work. Define done in writing, one short paragraph, before you hand anything over. If you can’t write it down, the task isn’t ready to delegate, and neither are you. Hand over the outcome and the context, never the steps, because steps produce compliance while context produces judgment. And put the checkpoint at roughly the one-third mark, where a wrong direction costs days instead of weeks and a correction still feels like help rather than a grade.
The written definition of done also works in reverse. If a slower manager is your bottleneck, agree on it with them up front and you cut the back-and-forth that stretches the wait.
The hard part is the worry, not the work
Most delegation advice stops at process, and process isn’t where fast people get stuck. You hand over the task and keep the anxiety. So you check in daily, which the other person correctly reads as “I’m not trusted.” Or you wait, receive the finished work, and quietly rewrite it that evening. From your side that’s protecting quality. From their side the message is unmistakable: nothing I produce will ever be final. Do it three times and you’ve trained a capable person to hand you drafts.
The handoff that matters is the emotional one. Before you delegate, ask yourself what a failure would actually cost. For most delegable tasks, written down plainly, the cost is far smaller than the one you imagined. Agree on what a real failure would look like, and then let everything short of that stand. When the final version clears the bar you wrote down, approve it, even though it doesn’t clear the one in your head. Give notes for next time instead of rewrites for this time. Notes build a person, rewrites build a bottleneck.
An experiment for this week
Pick one recurring task someone else could plausibly own. Write what done looks like in five sentences. Hand it over with the context, set a checkpoint at the one-third mark, and when the result arrives, resist improving anything that clears the written bar. Run it for four weeks and count a single number: how many times the task came back to you. If that number falls to zero, you haven’t lost speed. You’ve multiplied your output, and the next handover multiplies it again.