Delegation without abdication

Delegating a task is scheduling.

Delegating an outcome is management. The difference is whether the decisions go with it.

"Build the export feature by the fifteenth" is a task.

The decisions were already made. By you. The person is executing them.

Useful sometimes. It doesn't develop anybody, and it means every decision inside that work still lands on your desk anyway.

"Own how customers get their data out of the product, and here's what would make it a success" is an outcome.

They decide what to build, in what order, and whether an export is even the right answer at all.

That's the version that scales. It's also the version most leaders believe they're doing while actually doing the first one.

Say the level out loud

Most delegation friction comes from an unstated mismatch about how much authority actually changed hands.

You thought you'd given somebody a decision. They thought they were bringing you a recommendation. Both of you are annoyed.

So name it. One sentence, at the moment you hand it over. Four levels cover almost everything.

Do exactly this. Rare, and right for something urgent, unambiguous, or high-risk. Say why, because without a reason it's just demotivating.

Look into it and recommend. You still decide. Right for a genuinely irreversible decision, or for someone new to the area.

Decide and tell me before you act. The middle position, and the one doing the most quiet damage when it becomes permanent, because it looks like delegation and functions as approval.

Decide and act, tell me afterwards. The real one. Where you want most things to end up, and where most things should start for anybody senior.

The mistake is drifting between levels without saying so.

If somebody has been at "decide and act" for six months and you suddenly want to be consulted, that's a change. It needs to be spoken, not enacted.

What you keep

Handing over the decisions doesn't mean handing over everything. Being clear about what's left is what makes letting go safe.

You keep the definition of done.

What good looks like, what failure looks like, which constraints are genuinely fixed.

This is the piece most often left implicit, and most often the cause of a disappointing result, because "I would have known it wasn't right" is not a specification.

You keep the check-in rhythm, agreed at the start rather than imposed later on. Weekly for something new. Fortnightly or monthly for somebody experienced.

You keep the escalation triggers. The specific circumstances where you want to hear immediately.

Money above a threshold. Anything touching a named customer. Anything that would move the date.

Three or four named triggers replace an enormous amount of anxious checking.

And you keep the accountability.

If it goes wrong it's still yours, in front of everybody else, and that has to be true out loud or nobody will ever take a real risk for you again.

Check-ins that aren't micromanagement

The distinction isn't frequency. It's what you ask about.

Micromanagement asks about the how. Why did you do it that way, have you tried this, show me the code.

Even asked kindly, it communicates that the decisions were never really theirs.

Management asks about the what and the whether. Where are we against what we agreed, what's in the way, what have you learned that changes the plan, what do you need from me.

The other half is what you do with the answer.

If a check-in regularly ends with you taking an item away to sort out, you've taught the person that raising something is the way to be relieved of it. Comfortable for both of you. Produces somebody who never grows.

A test worth applying to yourself. In the last month, how many decisions did this person make that you'd have made differently and let stand anyway.

If the answer is zero, you haven't delegated. You've installed a channel.

Letting it be done worse than you'd do it

This is the actual barrier, and it isn't about trust.

It's watching a thing get done at 80% of the quality you'd have reached, and having to not intervene.

The arithmetic helps.

The 80% version is done by somebody whose capability is increasing, on work you're no longer carrying. Your 100% version is done by somebody whose capability is already fixed, at the cost of everything else those hours could have gone to.

Repeat that trade across a year and it isn't close. Even though on any given Tuesday, intervening looks obviously correct.

There's one exception, and it's genuinely an exception rather than an excuse. When the cost of the 80% version lands on somebody else, and it's large.

A customer commitment. An irreversible technical decision. Something that will hurt a person.

There, intervene. And be explicit that you're doing it and why, so that it reads as a specific judgment rather than as a withdrawal of trust.

Taking something back

Sometimes it isn't working and you have to.

Done badly, this is one of the most damaging things a leader does. Done well, it's survivable, and occasionally strengthening.

Do it explicitly, in a conversation, with the reason.

What isn't working, what you're changing, what would have to be true for them to have it back.

The version that destroys people is the ambient one, where nothing gets said, their scope quietly shrinks, and everybody else notices before they do.

Be honest about which of you the failure belongs to, and expect it to be you more often than feels comfortable.

Unclear definition of done. Not enough context. Check-ins too sparse to catch the drift early.

If any of those are true, say so.

And separate the outcome from the person's standing.

Something not working out doesn't mean they failed. If the org concludes that losing scope is a punishment, nobody accepts a stretch again.

The thing to check quarterly

List what only you can do. Then cross off everything that's really just what you've always done.

What's left is usually much shorter than people expect.

The gap between the two lists is your delegation backlog. It's also, usually, the explanation for why your calendar looks the way it does.