You're Not Delegating. You're Just Watching Someone Do It Wrong Slowly.

I told people I'd got good at delegating, and I believed it. What I'd actually got good at was handing work over and then keeping it open in another tab. I gave away the typing and kept the worrying. Every so often I'd wander past someone's desk at 4pm with a casual "how's that going", which is the most expensive sentence in technical leadership and I said it roughly forty times a week.

Real delegation moves two things: the work, and the responsibility for how the work turns out. Most of us only move the first one.

You can spot it in yourself. You've handed over the firewall migration plan, and yet you're still reading the ticket queue on Sunday evening. You're still first to answer when the client asks a question about it. You've got a private version of the plan in your notes that you check theirs against. None of that is oversight. That's you doing the job twice, once slowly through someone else and once properly in your own head.

The person on the other end knows. They always know. They can feel that they're producing a draft for your approval rather than a result they own, so they stop making decisions and start making guesses about what you'd want. Which, by the way, is slower than if you'd just done it yourself, and you'll take that as evidence that delegation doesn't work with this person.

It's not a trust issue with them. It's a completion problem with you. You never actually let go of the end state.

The version that does real damage is handing someone the outcome and keeping the decision rights.

I watched this happen to a senior engineer on a 13-person database team at a supermarket chain. He was given the database consolidation: merge the four ageing clusters behind stock and pricing onto one platform, six-month window, high visibility. Genuinely the right person for it. And then every choice he made needed a nod. Which target version. Whether to keep the old clusters running in parallel. Whether to pull a second engineer in for the migration weekend.

He'd raise each one in the Tuesday catch-up. Sometimes he'd get an answer. Sometimes it would roll to next Tuesday because his lead wanted to think about it. By month three he had a list of eleven open questions and he'd stopped starting anything he couldn't finish alone.

Then the deadline slipped and the conversation was about his delivery.

He had the responsibility the whole time. He never had the authority. Those two things have to arrive together or you've built a machine that converts a good engineer into a frustrated one. If you're going to hold someone to an outcome, they get to make the calls that produce it, including the ones you'd have made differently.

Say the boundary out loud when you hand it over. "You pick the tooling, you decide the parallel run, you can pull Priya in for up to two weeks. Come to me if it needs money, if it needs a client conversation, or if the date's at risk." That took eleven seconds and it just removed eleven Tuesdays.

Here's the trade nobody does the arithmetic on.

The mistake you're hovering to prevent probably costs a few days and gets caught. The hovering costs you the thing you delegated for in the first place, which was a person who can run that class of work without you next time.

If you catch every wrong turn before it happens, they learn that wrong turns get caught, not how to spot one. You've bought a small amount of schedule safety this quarter and sold your own capacity for the next two years. That's a bad trade and most of us make it on instinct, because the cost of the mistake is visible and immediate and the cost of the hovering never appears on anything.

There's a real limit, obviously. Some decisions are genuinely one-way: the data migration that can't be rerun, the change that touches production during a freeze, the thing that goes in front of a regulator. Those you stay close to, and you say why. Everything else, let it be slightly wrong for a fortnight.

Before you step in, ask whether the thing will still be recoverable in a fortnight. Not whether you'd have done it that way. If it's recoverable, sit on your hands.

None of this means walking away and reappearing at the deadline with an expectant face. That's not empowerment, that's abandonment with better branding, and it fails just as often.

The difference is whether the check-in was agreed in advance.

An agreed rhythm sounds like: "Thursdays, fifteen minutes, tell me what's moved and what's stuck." It's predictable, so the person can prepare for it, and they don't experience it as surveillance. Crucially, between Thursdays, you leave them alone. The whole point of a scheduled checkpoint is that it buys you permission not to ask on the other four days.

A hover sounds like: "just wondering where we got to on the thing". Unscheduled, unbounded, and it communicates that you were thinking about their work when they weren't in the room.

Two questions are enough at a checkpoint. What's moved since last time, and what decision do you need from me that you can't take yourself? The second one is the useful one. If the answer is regularly "nothing", the delegation is working. If they're bringing you four decisions a week that are inside their remit, you didn't set the boundary clearly enough, and that's yours to fix rather than theirs.

Go through whatever you delegated in the last month and find the one you're still carrying in your head. You know which. It's the one you check on without meaning to.

You've got two honest options and neither of them is the current arrangement.

Either take it back, today, and say so plainly: "I've realised I haven't actually let go of this, so I'm taking it back, and that's on me, not you." People respect that far more than you'd expect.

Or finish the handover this week. Send four lines that say what the outcome is, what they can decide without you, what they must come to you for, and when the fifteen minutes on Thursday is. Then leave it alone until Thursday, even when you want to look. Especially then.