Delegation is a design problem

Most managers I coach think they have a delegation problem because they don't trust their team. Usually that's not it. The real problem is that they delegate badly: a task with no context, no clear authority and no agreed way to check progress. Then it goes sideways, they step back in, and the lesson everyone learns is that delegation doesn't work.

I've come to think of delegation the way I think about designing a software interface. You decide what goes across the boundary, what the contract is, and how failures are reported. Get the design right, and things hum. Get it wrong, and you get the organisational equivalent of a leaky abstraction: you end up debugging someone else's work at eleven at night.

Delegate outcomes, not tasks

"Can you add retry logic to the payment client?" is a task. "Payments to our provider fail about two percent of the time and customers see an error. Can you own getting that below a tenth of a percent?" is an outcome.

The difference matters more than it looks. With a task, the person executes your solution. If it was the wrong solution, that's on you, and they learned nothing about the problem. With an outcome, they own the problem. They might find that retries are right, or that the real issue is a timeout set too low, or that a third of the failures come from one malformed request type. They'll know more about it than you do within a week, which is exactly the point.

When I hand over an outcome, I try to cover five things:

1. The outcome. What does done look like, ideally as something you can measure or see?
2. Why it matters. Who's affected, and what happens if we don't do it?
3. The constraints. Budget, deadlines, systems that can't change, people who must be consulted.
4. The authority. What can they decide alone, and what needs a conversation first?
5. The check-ins. When and how will we look at progress together?

It takes ten minutes. It saves weeks.

Decide how much authority you're handing over

The most common source of delegation pain is a mismatch in authority. The manager thinks they asked for a recommendation; the engineer thinks they were asked to decide and is annoyed when it's overruled. Or the reverse: the engineer waits for approval on every small choice because nobody said they didn't need to.

I use a simple ladder and say out loud which rung we're on:

• Level 1: Look into it and report back. I'll decide.
• Level 2: Recommend an option. We'll decide together, and I'll usually go with your recommendation.
• Level 3: Decide, and tell me before you act. I might push back, but I expect to agree.
• Level 4: Decide and act, then tell me. I want to know what happened, not approve it.
• Level 5: Decide and act. No need to report unless something goes wrong.

The rung depends on the person and the stakes, not on how much you like them. A strong senior engineer might be at level five on code design and level two on anything that changes a customer contract. A new joiner might start at level one on everything and move up within a month. Moving someone up the ladder deliberately, and telling them you're doing it, is one of the clearest ways to show growth and trust.

Design the feedback loop before you need it

Every interface needs a way to report errors. Delegation is the same. If the only way you find out something is off track is when it misses a deadline, the design has failed, not the person.

Agree up front how progress will be visible. For a two-week piece of work, that might be a quick check-in on day three and a demo on day eight. For a quarter-long project, a short written update every Friday and a review at each milestone. The cadence should get lighter as trust and track record build.

What I try hard not to do is check in at random because I'm anxious. Unscheduled check-ins feel like surveillance, however friendly the tone. Scheduled ones feel like support. The same information, very different message.

What to do when it goes off track

It will, sometimes. When it does, resist the reflex to take it back. Ask questions first: what's the situation, what options do you see, what would you do next? Most of the time the person already knows what to do and needs a sounding board, not a rescue. If you do need to step in, say so explicitly, change the authority level openly, and explain why. Quietly taking work back teaches people that ownership is temporary.

What not to delegate

Some things stay with the manager, however busy you are:

• Performance conversations and feedback about people. You can gather input from others, but the conversation is yours.
• Hiring decisions. Delegate the interviews and the evaluation, not the final call.
• The team's direction. You can and should involve everyone in shaping it, but you're accountable for it.
• Anything that exists only to make you look busy. If you'd be embarrassed to explain why it matters, don't hand it to someone else. Stop doing it.

Delegate the interesting work, too

New managers often delegate the work they find boring and keep the work they enjoy: the gnarly design problem, the architecture review, the important customer call. It's natural, and it's a mistake. That interesting work is exactly what your senior people need to grow, and when you hoard it, you become the ceiling on everyone else's career.

The test I use: if I'm the only person on the team who could do this, that's a risk I should be fixing, not a reason to keep doing it.

Try it this week

Pick one piece of work you're currently holding that someone on your team could own. Write down the five things: the outcome, why it matters, the constraints, the authority level and the check-ins. Then have the conversation, and put the first check-in in both your calendars before you leave the room.

It will feel slower at first. It isn't. You're building a team that doesn't need you in every decision, and that's the whole job.