You've decided to hand something off. Good. Now comes the part where most people mess it up.
Not intentionally. Nobody sets out to do a bad handoff. But the gap between "I'm going to delegate this" and "this task is now reliably handled by someone else" is where delegation goes to die. It's a transition, and transitions are where things break.
I've watched this play out hundreds of times. The owner knows the task cold, does a quick walkthrough, says "you got it?", gets a nod, and walks away feeling productive. Two weeks later, something's wrong and they can't figure out why. The answer is almost always that the handoff was incomplete.
So here's how to do it properly.
Before the handoff: get your own head straight
Before you talk to anyone else, answer these questions for yourself. What does this task actually involve, step by step? What's the quality standard, the thing that separates "done right" from "done but not quite"? What are the most common mistakes? What decisions are embedded in this task that you've been making unconsciously?
That last one is the killer. After years of doing something yourself, you have judgment calls baked into the process that you don't even register as decisions. "I always check the inventory numbers before confirming the order" is not an obvious step to someone who's never done it. "I always call the client if the turnaround time is going to be more than three days" is a decision you make automatically, but it's invisible to a newcomer.
Write these things down. Even if it's rough notes on a napkin. The act of articulating what you do will reveal complexity you didn't know was there.
The handoff conversation
When you're ready to actually hand the task over, have a real conversation about it. Not a drive-by explanation between meetings. Sit down, or get on a call, and walk through the task in detail.
But here's the key: don't just show them. Have them do it while you watch. People retain almost nothing from watching someone else work. They retain a lot from doing it themselves, making mistakes, and getting corrected in real time.
During this conversation, cover five things.
The purpose. Why does this task exist? What happens if it's done well? What happens if it's done badly? People do better work when they understand the stakes and the context, not just the steps.
The process. Walk through it. Let them take notes. Let them ask questions, especially the ones that feel dumb. Those "dumb" questions are usually pointing at assumptions you forgot you were making.
The standards. What does good look like? Be specific. "Make sure it's accurate" is not a standard. "Every invoice should match the project scope within 2% and be sent within 48 hours of project completion" is a standard.
The boundaries. What decisions can they make on their own? What needs your approval? Where's the line between "handle it" and "check with me first"? If you don't define this, they'll either ask you about everything (defeating the purpose) or guess wrong on something important.
The safety net. What should they do when they're stuck? Who do they ask? How quickly do they need an answer? This isn't about babysitting. It's about making sure they have a path forward when things don't match the documentation.
The first two weeks matter most
The period right after the handoff is when the task is most likely to fail. Not because the person isn't capable, but because reality is always more complicated than the walkthrough.
Check in after the first time they do the task. Not to grade them, but to compare notes. "How did it go? What was confusing? What took longer than expected? What would have helped to know beforehand?" This conversation will surface gaps that no amount of preparation could have predicted.
Check in again after the third time. By now they should be getting comfortable, but they'll have encountered edge cases and made a few mistakes. Review those mistakes together. Not punitively, but as data. Each mistake is information about what the documentation or training was missing.
By the end of two weeks, if you've been checking in consistently, you should have a task that's running reasonably well and a set of notes about the things that needed clarifying. Update your documentation with those notes. Future handoffs of the same task will be dramatically smoother.
The micromanaging trap
There's a real tension here. You need to follow up enough to catch problems early, but not so much that you're essentially still doing the task yourself through someone else's hands.
The distinction is this: checking the output is follow-up. Checking every step along the way is micromanaging.
Review the finished product. Look at the invoices that went out, the reports that were generated, the emails that were sent. If the output is good, you don't need to know how they got there. If the output has problems, then you dig into the process to find out where things went sideways.
Over time, reduce the frequency of your reviews. Every time, to weekly, to spot-checks, to "I only look if something seems off." The goal is to gradually remove yourself from the loop entirely, not in one dramatic gesture, but through a slow, verified withdrawal.
When a handoff isn't working
Sometimes, despite doing everything right, a handoff doesn't take. The person is struggling, the quality isn't there, problems keep recurring.
Before you take the task back, ask two questions. First, is this a training gap or a capability gap? Training gaps are fixable. Maybe they need more time, more examples, more context. Capability gaps are harder. Maybe this task requires skills or judgment that this person doesn't have yet.
Second, is the system failing or is the person failing? If you put a different person in the same role with the same documentation, would they struggle too? If so, the system needs work, not the person.
Taking a task back should be the last resort, not the first instinct. Every time you take something back, you reinforce the pattern that only you can do it. And that pattern is exactly what you're trying to break.