Why delegation usually fails
Most failed delegation looks the same in hindsight. The work came back wrong, the manager concluded the person was not ready, and the task quietly returned to the manager's list.
What actually happened is usually simpler. The outcome was never described precisely enough for anyone else to hit it, so the person guessed, and the guess did not match the picture in the manager's head. Nobody was ever going to hit a target that only existed in one person's mind.
The test before you hand anything over
Can you describe what done looks like in two sentences, without describing how to do it? If not, you are not ready to delegate it yet. That is a specification problem, not a trust problem.
What to say when you hand work over
A good handover covers five things and takes about five minutes.
The outcome, stated as a result
What has to be true when this is finished. Not the steps, the end state: the client has a proposal they can sign, the report is with finance, the three candidates have been scheduled.
Say it in one sentence. If it takes a paragraph, the task probably contains two tasks.
One sentenceWhy it matters, and to whom
Who is waiting for this and what they will do with it. This is the part most handovers skip, and it is what lets someone make sensible decisions when they hit something you did not anticipate.
A person who knows the purpose can adapt. A person who only knows the instructions has to come back and ask.
The most-skipped stepThe constraints that genuinely cannot move
Deadline, budget, anything legal, anything that would upset a customer. Be strict about this list: everything you name as fixed is a decision you are taking away from them.
If you find yourself listing eight constraints, you are describing a method, not setting boundaries.
Two or three, rarely moreWhat is explicitly theirs to decide
Say out loud which choices are theirs: the tool, the order, the format, who they involve.
Saying it matters. People default to assuming the manager has a preference, and they will spend energy trying to guess it unless you tell them there is nothing to guess.
Say it out loudWhen you will next talk about it
Agree the check-in at handover: a midpoint review, a draft on Thursday, a message if they hit a blocker. Put it in the calendar.
This single step removes most of the anxiety on both sides. You are not tempted to ask how it is going, because there is a known point at which you will find out.
Agreed at handover, not later
How much checking is the right amount
Checking is not micromanagement. Unpredictable checking is. The difference is whether the person knows in advance when it happens.
| Situation | Sensible check-in |
|---|---|
| New person, familiar task | Draft at the halfway point |
| Experienced person, familiar task | On completion |
| Anyone, task that is new to them | Short check after the first step |
| High stakes, hard to reverse | Agreed review before the irreversible action |
| Long-running work | A fixed weekly slot, not ad hoc |
The pattern to avoid is the drive-by: asking how it is going at random moments. It reads as distrust, it interrupts, and it produces a reassuring answer rather than a true one, because nobody wants to report a problem they are still working out.
When it comes back wrong
Two questions, in this order.
Was the outcome met by a different route? If yes, this is a success and treating it as a failure is how you teach people to stop thinking. The method being different from yours is not a defect.
If the outcome genuinely was not met, what did I not specify? Almost always there is something: an unstated constraint, an assumption about who the audience was, a quality bar that lived in your head. Fix the specification before you conclude anything about the person.
Only after both of those is it fair to ask whether the person needed more support than they got. And even then, the response is a clearer handover next time rather than taking the work back permanently.
The compounding version of this is worth stating plainly: every task you keep because it is faster to do yourself is a task you will still be doing in a year. The hour spent specifying it properly is the only way that changes.
Frequently asked questions
- What is the difference between delegating and micromanaging?
- Delegating means handing over the outcome and letting the person choose the method. Micromanaging means keeping control of the method while pretending to have handed over the work. The second one costs you the time you were trying to save and costs them the chance to get better.
- What should I delegate first?
- Work that is repeatable, where the outcome is easy to describe, and where a mistake is recoverable. Resist starting with the thing you hate most, because that is often the thing you have never written down, which makes it the hardest to hand over.
- How do I delegate when I am faster at the task myself?
- You almost always are, the first three times. Delegation is an investment that only pays back on repetition, so it makes sense for recurring work and rarely for a genuine one-off. If the task will never happen again, doing it yourself is the right call.
- How do I stop taking work back?
- Decide in advance what would justify intervening, and hold yourself to it. Most work is taken back because it is being done differently, not because it is being done badly, and reclaiming it teaches the person that ownership is conditional.
- What if they do it worse than I would have?
- Ask whether the outcome was acceptable, not whether it matched what you would have produced. If it met the standard by a different route, that is a success. If it genuinely fell short, the useful question is what you failed to specify.