I handed off a client relationship three months ago. Clear handoff, lots of context, the partner had done this before. By week two, things were moving. By week four, I forgot I’d ever been involved. Then last Tuesday, the project hit a wall, and I got a message: “You need to jump back in. I can’t solve this without the original reasoning.”
I went back in. And it hurt.
Not because I was busy (I was), not because I’d forgotten the details (I hadn’t). It hurt because the problem I was about to solve was one I’d already solved three months ago, and I’d genuinely thought I was done with it. Handing work off felt like completion. Taking it back felt like failure.
But the real lesson was different: delegation is never a one-time handoff. It’s a conditional transfer of execution with standing permission to reverse.
The fantasy of clean handoff
When delegation works, it feels like you’ve truly passed something off. The mental overhead evaporates. You stop thinking about it. Your calendar opens up. You’re not checking in; you’re just… moving on to the next thing.
This is the part that gets written about. “Delegation allows you to scale yourself.” “Your job as a leader is to get out of the way.” All true. But there’s an unsaid condition: it assumes the person you handed it to can see around corners you’ve already turned.
They usually can’t.
Most of the problems that don’t surface immediately are the ones you’ve already solved. Edge cases you encountered once and built around. Relationships that only work because of a specific conversation three months ago. Unspoken context about why a decision was made instead of three other decisions that looked almost right.
When the work comes back, it’s coming back because they’ve hit one of those corners you already turned, and now both of you are back in the same room.
What taking something back actually costs
The moment you jump back in, the illusion of delegation ends. You’ve now got two projects: the original work, and the context transfer that should have happened before the handoff.
The second one is the killer.
You can’t just explain what went wrong; you have to re-explain why the decision was made that way. You have to remember why you rejected the three approaches that looked similar. You have to recover not just the solution but the reasoning behind the solution.
That’s context work. It’s not on the calendar. It’s not delegated. It’s what you get when delegation fails silently for three months and then surfaces.
The worst part: if you’re a good delegator, you don’t blame the person who’s handing it back. They did their job; they escalated. But you’re now facing a choice: do you get surgical with the context transfer and hand it back again (risking another wall), or do you just absorb it back into your own plate?
Most people absorb it back.
The permission structure that actually works
I’ve started treating delegation differently. Not as a transfer of ownership, but as a transfer of primary execution with standing reversal rights.
That sounds worse than it is. It just means: I’m giving you this to run. If you hit something I haven’t seen, bring it back. No judgment. We figure out together whether it’s a context gap, a capability gap, or a real new problem. Then we decide if it goes back to you or stays with me.
This requires a few things:
Tight context at the start. Not “here’s what you need to know,” but “here are the three wall-hitting points I’ve already hit, and here’s how I resolved them.” Spend the time upfront.
An escalation protocol, not a sign of failure. “This is above the context I can give you” is not bad delegation. It’s honest delegation.
A handoff window, not a deadline. After thirty days, we check: is this moving smoothly? If not, do we adjust context, bring it back, or shift scope?
Explicit reversal windows. “If you hit X by month two, we need to reconnect.” Not a threat. A checkpoint.
Why this matters beyond delegation
This is where a lot of teams break. Not because people are bad at their jobs, but because delegation is treated as a one-way door.
A ticket gets assigned. Work happens. But if the ticket hits something unforeseen, there’s no protocol to bring it back. So it gets hammered through anyway, with workarounds that pile up, or it just stalls.
The handoff becomes a wall instead of a bridge.
I’ve stopped trying to make delegation permanent. Now I’m aiming for delegation that’s strong enough to move forward but flexible enough to reverse when it needs to.
That work that came back last Tuesday? I took it because the protocol said I should. I got frustrated because the protocol wasn’t clear enough at the start. Then I fixed the protocol.
That’s the game: not better handoffs, but better reversal.
Everything else is just pretending you’re done.