Delegate the Outcome, Not the Task List

A task list is not delegation. It's remote control with extra latency. You've decided everything that matters and then paid a salaried engineer to be your hands, and when it goes wrong, which it will, nobody involved can tell you why, because the only person who understood the shape of the problem was you.

Compare two handovers of the same piece of work.

The first: "Can you update the runbook for the failover process, add the new DNS steps, get it reviewed by Marcus, and stick it in the wiki under Operations."

The second: "Ops need to be able to run a failover at 3am without ringing us. That's the outcome. The runbook's the obvious way there but it's your call. Marcus knows the DNS changes, you'll probably want him."

The first one is four hours of somebody's life and nothing changes. They'll do exactly those four things. The runbook will be updated, reviewed, filed, and it will still not let a tired operations engineer run a failover unaided, because step seven assumes you know which cluster is primary and the document never says.

The second one puts the person inside the problem. They'll notice step seven. They might even ring the ops shift lead and ask what actually confused them last time, which is a thing you'd never have put on a list because you didn't know to.

The test for any handover: could the person tell you, without checking with you, whether they've succeeded? If not, you haven't given them an outcome. You've given them errands.

Three things need to travel with the work, and they take about two minutes to say.

The finish line. What is true in the world when this is done? Not "the migration is complete", which means nothing. "All 14 services are running on the new cluster, the old one is powered off, and nobody has had to roll back."

The fences. What can't they do. Budget ceiling, the date that can't move, the change freeze, the client who must not be contacted directly. Be specific, because vague constraints get treated as suggestions or as walls, depending on how cautious the person is, and you don't get to choose which.

The calls they own. This is the one everyone leaves implicit and it is the one that decides whether the thing actually leaves your desk. Say it explicitly: "You choose the sequencing, you can book the weekend maintenance window yourself, you can bring in a contractor up to fifteen days. Come to me before you change the date or talk to the client."

Everything not on the "come to me" list is theirs. Say that last bit out loud too, because most people assume the opposite by default.

The lazy version of delegation is looking at who's free. The useful version is looking at what this piece of work will make someone better at, and whether they can survive it.

Roughly, work lands in one of three places for a given person. Well inside their skill, in which case they'll do it fast and learn nothing, which is fine for genuinely routine things and corrosive if it's all they ever get. At the edge of it, where they'll be uncomfortable for a fortnight and noticeably better afterwards. Or beyond it, where they'll quietly drown and you'll find out in week six.

Most of the good stuff sits at the edge. And the difference between the edge and beyond it is almost always support rather than the work itself. The same database cutover is a stretch with a named person to ask and a drowning with nobody.

So when you hand over something ambitious, hand over the safety net in the same breath. "Sam's done three of these, I've asked her to give you an hour a week, use it." That sentence converts a risky delegation into a good one, and it costs you nothing but a conversation with Sam.

An online travel agent moving out of an ageing on-premise facility. Eleven months, around 200 workloads, a 19-person platform group, and a hard exit date because the lease was ending and there was no extension to be had.

The infrastructure lead was two months in and doing what a lot of us do: running the whole thing himself while three capable engineers waited for instructions. He'd built a task board with about 340 cards on it. He was the only person who understood the dependencies between them, so he was also the only person who could sequence anything, so every morning began with him assigning work and every evening ended with him re-planning it.

What changed was one uncomfortable conversation with his own manager, who asked him what happened to the programme if he broke his leg. The honest answer was that it stopped.

So he split it by outcome rather than by task. Three streams: the application workloads, the network and connectivity, the decommission and exit evidence. One owner each. Each owner got the finish line, the exit date, the budget line, and an explicit list of what needed his sign-off (anything touching the exit date, anything over a certain spend, anything that touched live booking traffic).

Two weeks of mess while people worked out what they now owned. Then the network owner discovered a circuit lead time nobody had checked, sixteen weeks, sitting quietly in the critical path. She found it because she owned the outcome and went looking, not because it was on a card. It had never been on a card.

They ordered the circuit in month three instead of month seven. That single find is the difference between hitting the lease date and not.

Before your next handover, open a document and write four lines: the finish line in one sentence, the fences, the decisions they own, and the checkpoint. Read it back and ask whether the person could work out, on their own, whether they'd succeeded.

Then have the conversation. The document isn't for them, it's for you, and you'll notice while writing it that you have not actually decided what "done" looks like on at least one of the things you were about to hand over. Decide that first. You can't delegate an outcome you haven't defined.