How to delegate as a manager

You keep the hardest project for yourself because you can finish it faster, and you tell yourself you'll hand it over once things calm down. Meanwhile your team is waiting on four of your decisions, and the person you hired to run that area is still asking permission for things you already told them they own.

This article covers what to give away first, and how to hand off an outcome instead of a task list. It also covers setting check-ins that don't feel like surveillance, and what to do when the work comes back rougher than you wanted. Start with the one area you're most reluctant to let go of, because that's usually the one holding your team back.

The advice comes from Molly Graham, who ran teams at Google, Facebook, and Quip and now coaches leaders through rapid scale; Cameron Adams, co-founder and chief product officer at Canva; Claire Hughes Johnson, who was chief operating officer at Stripe from about 160 people to several thousand and wrote Scaling People; and the Mochary Method, the coaching curriculum Matt Mochary uses with startup CEOs.

Why handing work off feels like a loss

Molly Graham coined the phrase most managers now use for this. She describes joining a fast-growing company as being handed a giant pile of Legos and told to build something. You build a house, you get good at building houses, and then someone tells you it's a neighborhood, hands your half-built house to a new hire, and asks you to go build dog parks instead.

Graham has been doing this for close to twenty years and says she still gets hit by those feelings. Her point is that they're normal and they're not useful. They aren't a signal about whether the handoff is right, so don't let them decide for you.

She also gives the practical reason to do it anyway. In a growing company the pile of Legos keeps getting bigger, and if you hold on to the thing you were good at two years ago, you end up buried under everything you didn't hand over. At Facebook she got to a point where she was giving away her job every few weeks and rehiring herself into a bigger one.

She has a rule for the emotions too. Most of them roll through in a couple of days. Anything that's still bothering you two weeks after a handoff is worth taking to your own manager, a peer, or a coach, because that one is probably real.

Decide what to give away first

The instinct is to hand off whatever you like least. That usually backfires, because the work you hate is often the work you're worst at explaining, and the work you love is often the work that's now too big for one person.

Cameron Adams, co-founder and CPO of Canva, runs every new employee through a culture session that includes a segment on giving away your Legos. His example is the person who wrote all of Canva's marketing emails. That job worked fine for a year. Then the emails had to go to a hundred million people in 190 countries in a hundred languages, at every stage of using the product.

Adams frames the handoff as the moment you decide who to bring in, what systems you need, and what processes have to exist. That's a different job from writing the emails, and it's the job that scales.

Write the list down. Most managers who say they've delegated have handed over execution and quietly kept every decision, and the list is where you notice that.

Give every area one named owner

The structural version of delegation is simple to state and hard to do. Group the work into areas, and put exactly one name next to each area.

The Mochary Method calls these Areas of Responsibility, or AORs, and starts from the tragedy of the commons: when several people share responsibility for something, it tends to get done badly or not at all. The fix is a document that lists every function in the company with the responsible person next to it, kept current as roles shift, and visible to everyone. Apple popularized the practice and most tech companies now use some version of it.

Molly Graham makes the same point about goals, and she's blunt about how uncomfortable it is to do.

Two practical notes from the AOR doc. First, write down the process for each area as soon as you've done something twice, and link it from the list. Second, map a backup person to every area and have them work alongside the owner until they could cover it, so that no area depends on one person being available.

Mochary suggests doing the first pass live rather than as homework. Take 45 minutes in a team meeting: fifteen for everyone to write their own areas, fifteen to read each other's and flag overlaps, fifteen for each person to document one process. Overlaps that can't be settled in two minutes become a written issue for the next meeting. Doing it live matters because people who aren't sure what's expected will often do nothing rather than risk doing it wrong.

Describe the outcome instead of the steps

When you hand someone a task list, you keep the thinking. Give them the outcome, the constraints, and the decision rights, and they get the whole problem to solve.

A good handoff conversation covers six things:

1. The outcome. What's true when this is working. Use a number if there is one.
2. Why it matters. Who's affected, and what happens if nobody does it.
3. The boundaries. Budget, headcount, legal or brand limits, things that are genuinely off the table.
4. The decision rights. What they decide alone, what they tell you about afterward, and the short list of things they check with you first.
5. What you know. The history, the two approaches that already failed, the person who will be unhappy about it.
6. The check-ins. When you'll talk, and what you'll look at together.

Then say it again. Graham points out that re-explaining roles and expectations is one of the hardest parts of leading, because you feel like a broken record. She describes managers who think they've been clear and then find out the person heard something completely different: you described an elephant and they came away with a tiger. Her rule of thumb is that you've said it 45 times and nobody heard the first 43.

One more thing to say out loud during the handoff: tell the rest of the team, and tell the people outside your team who used to come to you. Delegation that nobody else knows about turns into two owners, which Graham would tell you means no owner.

Agree on the check-in cadence up front

Most micromanagement is a cadence problem. You didn't agree on when you'd look at the work, so you check whenever you get anxious, and the person on the other end experiences that as being watched.

Claire Hughes Johnson, who was COO of Stripe from about 160 people to several thousand, argues that a regular rhythm is what makes an unstable environment feel workable.

The difference between a check-in and an interruption is usually just whether the person knew it was coming. Agree on the rhythm once and you stop having to decide each week whether you're allowed to ask.

The Mochary Method has a short format for reviewing actions that keeps the check-in from turning into an interrogation. For each thing the person said they'd do, they write whether it's done. If it's done, any learnings or next steps. If it isn't, three questions: what blocked you, do you still want to do it and by when, and what will you change so you don't get blocked the same way again. The guidance is explicit that an undone action is a chance to fix whatever blocked the person.

Mochary's note on being a good manager adds a cadence rule most managers get backwards. Start weekly to build the relationship and the habit. Once you're showing up and there isn't enough new to talk about, drop to every two weeks. For people who work well without much guidance, monthly is fine. Fewer check-ins are something concrete you can offer someone who has earned them.

If you're rolling this out across a group of managers, Mochary's manager training outline pairs each topic with live practice in pairs rather than a reading list, which is the part most training skips.

If your reports are the ones who feel over-managed, our guide to running a useful 1:1 with your manager is worth sharing with them, since half of a good check-in is what the other person brings.

When the work comes back worse than you'd have done it

It will, for a while. That's what it costs to build someone who can do it without you. The question is what you do in that moment, because the two easy answers both cost you.

If you take it back and fix it yourself, you've taught the person that ownership was conditional, and you've added the work back to your own plate. If you say nothing and quietly redo the edges yourself, they'll assume the bar is lower than it is.

Do this instead:

1. Separate the standard from your preference. Write down what specifically falls short. If the answer is "I'd have phrased it differently," that's taste, and you should let it go.
2. Check what you actually asked for. Graham's advice on performance problems is to start with whether the person knew what you expected before you conclude anything about them. Most of the time the elephant came back as a tiger because the brief was thinner than you remember.
3. Give the feedback that same week. Be specific about the gap and what good looks like. Feedback four weeks later sounds like a verdict. Our guide to giving feedback that lands covers how to say it.
4. Decide who fixes it. If there's time, they fix it and you review. If a customer deadline means you have to step in, say so explicitly and say it's a one-off: "I'm taking this one because of Friday. Next time it's yours, and here's what I'd change."
5. Fix the system as well as the artifact. Write down the checklist, the example of good, or the review step that would have caught it. That's the part that stops it happening again.

Also check your own share of it. If the work came back rough because the person got the assignment with two days left, that's a scheduling problem you created. If they were juggling this on top of a full plate, read our guide on what to do when there's too much work and consider whether you'd have raised it any earlier in their position.

How to tell whether someone is struggling or failing

Someone who's struggling is learning something hard and getting better at it. Someone who's failing isn't closing the gap, and you've already tried the obvious plan for closing it. Managers routinely mistake the first for the second, usually within about three weeks of a handoff.

Molly Graham teaches a model for diagnosing team problems that she calls the waterline. A team is a boat, and four things sit under the water: structural issues like goals, roles, and expectations, then dynamics like how the team makes decisions and handles conflict, then relationships between two people, then what's going on inside one person. Her rule is that you snorkel before you scuba. Most managers dive straight to the bottom and decide it's the human.

Graham says she's taken over a lot of teams, and almost every time she arrives, nobody knows what their job is and nobody knows what success looks like. Her whole instruction for managers, if they do nothing else, is clear roles and clear expectations.

She runs the conversation from both sides: here's what I'm seeing, now tell me what you think your job is and what number you were hired to move. What you often find is that their picture is different from yours.

Before you conclude it's failing, run the checks in order: did they know the outcome and the standard, did they have the authority and the budget, did they have the time, did they get feedback early enough to use it, and has anything about the situation changed. If the answer to any of those is no, that's yours to fix first. If they all check out and you've been direct twice, then you're in performance territory, and that needs a written plan with dates on it.

When the problem is above you rather than below, and a delegated project is going to miss its date, our guide on telling leadership a project is delayed covers the escalation.

Frequently asked questions

How do I delegate without losing control of quality?

Define the standard before the work starts rather than after. Show an example of good, name the two or three things that must be true, and agree on a review point early enough that a correction is still cheap. The standard and the check-in are how you keep quality once you've stopped doing the work yourself.

What if I can do it faster myself?

You almost always can, the first three times. Compare the hours over a quarter instead of a week. If the task recurs, teaching it once costs less than doing it twelve times, and doing it twelve times means you never get to the work only you can do.

How do I stop micromanaging?

Replace the random checks with a scheduled one. Agree on the frequency, what you'll look at, and the conditions where they should interrupt you sooner. Then hold your questions until the check-in. If you can't, that's usually a sign you didn't actually agree on the outcome.

What does "give away your Legos" mean?

It's Molly Graham's phrase for handing off the work you've gotten good at as your company grows, so you can take on the bigger version of the job. The uncomfortable feelings that come with it are normal, and she argues they're not a reason to hold on.

Should I delegate the work I enjoy or the work I dislike?

Often the work you enjoy. That's usually the work you're best at, which is exactly why it's worth teaching someone else, and it's frequently the thing that has outgrown one person. Keep hiring, performance, and goal-setting for your team.

How much authority should I give with a task?

Enough that they can finish without you. Name the decisions they make alone, the ones they tell you about afterward, and the short list that comes to you first. If that last list has more than three items, you've handed over the work but kept the actual job.

The handoff on one page