This transcript was produced by robots and left as-is. Accuracy and elegance are not guaranteed.

The thing you delegated came back. Half done or done wrong or done with a question attached. That means you’re doing it yourself anyway. So you conclude the person wasn’t ready. Or you delegated too early. Or you should have just handled it yourself. If you want something done right, do it yourself.

That’s the wrong read. The work didn’t bounce because the person failed. It bounced because you handed over the easy part and kept the part that mattered. I had this happen not long ago. I’d shifted all the project management work to an internal PM. But I held on to the client relationship. The day-to-day chatting, surfacing the gotchas.

Sorting the nice to have’s from the need to haves. And I didn’t always get those handed over. So when I had to step away to deal with something else, It left the team in a bind. I’d handed over part of it and I kept the rest. And that set everyone up to fail. My first instinct.

Was that the PM couldn’t handle it? The team didn’t do a great job. But when I went back and ran the postmortem, they’d done the best they could with the information they had. The problem was the rest of the information was sitting with me. Engineers think delegation fails because they’re too controlling. I need to trust my team more.

That’s the management training answer, and it’s wrong. Controlling isn’t the mechanism. The mechanism is what you transferred. You can be the most hands-off person in the building and still get bounced back if you transferred the wrong thing. Back in episode four, we talked about how being indispensable is a trap. It gets you stuck.

Today is about how you actually move out of it. Naming the trap isn’t the same as having the mechanics.

What you usually transfer is a task. What you need to transfer is a system. Three things move at a handoff. Most engineers move one. The first transfer is the outcome, not the task. Go fix the data pipeline is a task. You own the pipeline reliability. Here’s what good looks like, and here’s how we’ll know it’s working is an outcome.

Task assignment keeps the definition of done in your head. So every judgment call inside the task routes back to you. Because you’re the only one who knows the target. The tell? if the person you delegated to keeps coming back to ask, is this what you wanted? You transferred a task. They’re checking against your spec.

Because you never gave them one. Outcome transfer means they own the definition of done, not just the doing. Jocko Willink calls this commander’s intent in extreme ownership. The person doing the work understands what the finished outcome looks like without being handed the list of tasks to get there.

The second transfer is authority, not just work. This is the one engineers withhold even when they think they’ve handed over the outcome.

Authority is concrete. What can this person decide without checking with you? Can they spend up to X? Tell a client no? Change the approach? Pull someone else onto the task. Without it, you didn’t delegate. You routed the work through someone else’s hands and kept the steering wheel. Every real decision still comes back to you.

which feels like them being needy and is actually you being the bottleneck you delegated to escape.

The test here, name three decisions this person can now make without you. If you can’t name three, you didn’t transfer authority. You just transferred labor.

Back in episode 13, we talked about decision triage. You don’t grant the same latitude to a junior on a critical path that you’d give an expert on a reversible call. Authority transfer is calibrated the same way. And notice it’s a different move than the outcome. The outcome is the definition of done.

Authority is handing over some of the how.

The last transfer is context. Context is the fuel. Judgment runs on context. The why, the constraints, the history, the trade-offs you already considered and threw out. Skip it, and you’ve set them up to fail with full authority. They can decide, but they’ll decide blind because they don’t know the three things that make the obvious answer wrong.

Go back to my PM story. I transferred the work and most of the authority. What I never fully transferred was the context sitting in my client conversations. The team had the outcome and the latitude and none of the history. So when I stepped away, they were deciding blind. That’s not a team failure. That’s a context transfer failure.

And it was mine.

Episode 11 is the sharper version of the same mistake. I put a young engineer into a team lead role, handed over the outcome and the authority, never transferred the judgment first. He had the title and the latitude, and no context for how to use either, and it didn’t hold. Context is the difference between authority and an accident waiting to happen.

Now the pivot. The handoff is the setup. The hold, that’s the job.

Get all three transfers right, and you’ve still only done the setup. The system hasn’t settled. Here’s where delegation actually fails. Not at the handoff, but weeks later when the work comes back, uncomfortable. Part one of the hold is check-in design. Two default failure modes, both broken. The first

Reactive check-ins. You swoop in when you get nervous. That teaches the person your anxiety sets the cadence and it pulls authority back the moment you’re worried. They learn not to move until you hover. The other is no check-ins. It feels like trust, but it guarantees bounce back when things get hard because they’ve got no structured place.

To surface a problem early. The third path is prescheduled, structured, at intervals you set at the handoff. Predetermined means your nerves don’t drive it and their silence doesn’t hide a problem until it’s expensive. The check-in is a designed signal path, not a reaction.

Part two of the hold is not taking it back. This is where the whole system lives or dies. The work comes back slower than you’d have done it, done differently, with a mistake you wouldn’t have made. Every instinct says, take it back. I’ll just handle this one. Taking it back is the failure. Not because it’s bad management vibes.

Because of the mechanism.

The moment you take it back, you’ve taught the system the work is still yours. Authority snaps back to you. You’re the bottleneck again. And now they’ve learned not to fully commit because you might yank it back at any moment. Episode 12 is about identity lag. The urge to take it back is residual identity.

The part of you that still feels like yourself when you’re the one solving. The hold is where you collect the evidence that they got it done because you didn’t step in.

Slower today is the price of running without you later. Same trade-off as episode four. The hold is where you actually pay it instead of just agreeing it’s worth paying. So here’s the check. Not go delegate better. Before you delegate the next thing, run it. Did I transfer the outcome or just the task?

Can they name three decisions they can make without me? Did I give them the context or just the assignment? Do we have check-ins on the calendar or am I planning to hover? And the one that’s harder than all four combined, when it comes back at 80%, will I hold or will I take it back?