Delegation: Giving Away Your Job to Do Your Job
A practical delegation system: five levels of authority, a briefing template that prevents boomerang work, and checkpoints that grow people without hovering.
The promotion email says you're a manager now. What it doesn't say is that most of what got you promoted — being the fastest, most reliable individual contributor on the team — is now a liability. Every task you keep doing yourself is a task your team never learns, a bottleneck you personally guarantee, and an hour you're not spending on the work only you can do: setting direction, removing obstacles, and growing people.
Delegation is not offloading. It's the deliberate transfer of ownership, with enough context to succeed and enough authority to decide. Done badly, it produces boomerang work that comes back half-finished. Done well, it's the highest-return activity in management. This guide covers the full mechanics: what to hand off, how to brief it, how much authority to grant, how to check progress without hovering, and how to use delegation as your primary tool for developing people.
Why managers hold on too long
Before the mechanics, name the resistance. Almost every manager who under-delegates gives one of four reasons, and each one has a rebuttal worth internalizing.
"It's faster if I do it myself." True — once. If a task takes you 1 hour and would take your report 3 hours plus 30 minutes of your coaching, doing it yourself wins this week. But run the math over a quarter. A weekly task done yourself costs you 13 hours per quarter, forever. Delegated, it costs you 3.5 hours of briefing and review in week one, maybe 1 hour of review in week two, and roughly zero after that. By week four you're net positive, and by next quarter you've bought back 13 hours and your report has a new skill. The "faster myself" argument is a loan with a brutal interest rate.
"They're already too busy." Sometimes true, often an assumption. You don't actually know your report's capacity until you ask — and reports frequently want the stretch work you're hoarding. The honest version of this conversation sounds like: "I want to hand you the monthly board report. It's about four hours a month. What would need to come off your plate to make room?" That's a trade, not a dump.
"It has to be perfect." Ask yourself: perfect by whose standard, and does the task actually require it? A board deck needs your polish. An internal status summary needs to be accurate and on time. Managers who apply board-deck standards to status summaries never delegate anything. A useful rule: if 85% of your quality bar is genuinely good enough for the audience, it's delegable today.
"I like doing it." The most honest reason and the hardest to fix. Keeping one or two tasks you love is fine — it keeps you sharp and connected to the craft. Keeping ten of them means you're paying yourself a manager's salary to do an IC's job while your actual job goes undone.
The five levels of delegation
The single biggest cause of delegation failure is a mismatch in assumed authority. You thought you delegated a decision; your report thought you delegated research. Or the reverse: they shipped something you expected to approve first. The fix is to make the authority level explicit, every time.
Use these five levels. Say the level out loud when you hand off the work.
| Level | What you're asking for | What they can do | Example phrasing |
|---|---|---|---|
| 1. Investigate | Gather facts and options | Research only; no recommendation needed | "Look into why churn spiked and bring me what you find." |
| 2. Recommend | Options plus a point of view | Propose; you decide | "Evaluate the three vendors and tell me which you'd pick and why." |
| 3. Decide, then act after approval | A decision, checked before execution | Decide; wait for your sign-off to act | "Design the new on-call rotation. Get my OK before announcing it." |
| 4. Act, then inform | Independent action with visibility | Execute; tell you what they did | "Handle the customer escalation. Drop a summary in the channel after." |
| 5. Act | Full ownership | Execute; no report-back required | "Interview scheduling is yours. I don't need to see it." |
Two rules make the levels work.
First, the level attaches to the task, not the person. Your strongest senior engineer might be Level 5 on architecture decisions and Level 2 on anything involving pricing, because pricing context lives with you. Assigning levels per task, not per person, prevents both micromanaging your best people and over-trusting anyone in an unfamiliar domain.
Second, move up one level at a time. The path from "I do it" to "they own it" runs through the middle levels. If someone has never touched vendor selection, don't jump from nothing to Level 4. Give them a Level 2 pass ("recommend one"), review their reasoning — not just their answer — and if the reasoning is sound, the next vendor decision is Level 3 or 4. Each successful pass at one level is the evidence that justifies the next. This is also how you make delegation feel like trust instead of abandonment.
The one-sentence contract
End every handoff with a sentence that states the level in plain words: "This is yours to decide — just walk me through it before you announce," or "I'd like your recommendation by Thursday, and I'll make the final call." Thirty seconds of explicitness prevents the two worst delegation outcomes: the report who felt second-guessed, and the manager who felt blindsided.
Deciding what to delegate
Not everything should leave your plate. Run your recurring work through three filters.
Filter 1: Is it management or is it work? Setting team priorities, performance conversations, hiring decisions, resolving conflicts between reports, representing the team upward — these are yours and mostly non-delegable. Nearly everything else is a candidate.
Filter 2: The teach-once test. Anything you've done three or more times is documented in your head whether you've written it down or not. Recurring reports, meeting facilitation, release coordination, customer onboarding calls, sprint ceremonies — if it repeats, the briefing cost amortizes fast. Delegate recurring work first; one-off tasks second.
Filter 3: Who grows from this? The best delegation decisions match a task to a person's development goal, not just their availability. If your report said in a one-on-one that she wants to move toward product management, the competitive analysis you've been hoarding is her stretch assignment, not the intern's busywork. Keep a simple two-column list: what each person wants to grow into, and which of your current tasks would move them there. When those columns line up, delegation stops feeling like offloading and starts being the development plan. (Your one-on-ones are where you learn what belongs in the first column.)
A quick audit exercise: for one week, log every task you do that takes more than 20 minutes. At week's end, mark each one K (keep — genuinely only you), D (delegate now — someone can do this at 85%+ today), or T (train — someone could do this within a quarter with coaching). Most managers who run this honestly find their week is 30–50% D and T. That's your backlog.
What not to delegate: anything where you'd be delegating the blame rather than the work. If the task is politically radioactive, half-defined, or set up to fail, fix that first. Handing someone a doomed project and calling it a growth opportunity burns trust you won't easily rebuild.
The briefing: where delegation succeeds or fails
Most "delegation failures" are briefing failures. The work came back wrong because the handoff was a Slack message that said "can you take the Q3 report?" A real briefing takes 15–30 minutes and covers six things. Write them down — a doc the person can re-read beats a conversation they half-remember.
The six-part delegation brief
- Outcome. What does done look like, concretely? Not "handle the report" but "a two-page summary the VP can read in five minutes, covering pipeline, risks, and asks, in her inbox by the last Friday of the month."
- Why it matters. Context is what lets people make good judgment calls when the situation deviates from the brief — and it always deviates. "The VP uses this to defend our headcount in the exec meeting" changes how someone writes a report.
- Constraints. Budget, deadline, tools, people who must be consulted, decisions that are already made and not up for relitigating. Fences make freedom usable.
- Authority level. State the level from the table above, explicitly.
- Resources. Prior examples, the doc where the data lives, the person who did this last year. Five minutes of pointing at resources saves five hours of rediscovery.
- Checkpoints. When you'll look at progress together — agreed now, not improvised later. More on this below.
Then do the step almost everyone skips: have them play it back. "Before we wrap — tell me what you're taking away as the goal and the first step." Playback surfaces misunderstandings in minute 25 of the briefing instead of day 12 of the project. It feels slightly awkward the first few times. It is dramatically less awkward than the alternative.
A realistic example
Here's the difference in practice. The weak version:
"Hey Maya, can you own the customer QBR deck this quarter? Thanks!"
The strong version, condensed:
"Maya, I want to hand you the Q3 QBR deck for Acme — fully, not just the slides. Outcome: a 30-minute deck that gets them to renew early; last year's is linked here. Context: their champion just changed, so the new VP has never seen our results — assume zero prior knowledge. Constraints: use the approved template, and pricing changes are off the table, so route any discount asks to me. This is Level 3: build it and make the calls on content, but let's review together before it goes to the client. Sarah ran it last year and offered to spend 30 minutes with you. Checkpoints: outline by the 10th, draft by the 17th, dry run on the 20th. What's your read on the goal?"
Two minutes longer to say. Weeks of rework avoided.
Checking in without hovering
Here's the tension: check too much and you've delegated nothing but the typing; check too little and you discover problems at the deadline. The resolution is to separate scheduled checkpoints (agreed in the brief, tied to milestones) from ambient visibility (status you can see without asking).
Scheduled checkpoints
Set them at natural milestones — outline, draft, pre-launch — not at arbitrary calendar intervals. Frequency should track the authority level and the person's experience with this kind of task:
- Levels 1–2, or first time doing the task: checkpoint at 25%, 50%, and pre-delivery.
- Level 3, or done it before: one mid-point checkpoint plus the approval review.
- Levels 4–5: no scheduled checkpoints; you rely on ambient visibility and their judgment about when to pull you in.
At the checkpoint, ask questions that probe thinking rather than inspect output: "What's the hardest open question right now?" "What would make you miss the date?" "Where did you deviate from the brief, and why?" That last one matters — you want deviation with reasons, because deviation-with-reasons is exactly what judgment looks like.
Ambient visibility
The silent killer of delegation is the manager who, lacking any passive view of progress, pings "how's it going?" every two days. Each ping communicates I don't trust you, and each answer costs the report a context switch. The fix is to make status pull-based: progress lives somewhere you can look without asking. A shared board where the task moves through stages, a brief async check-in, a status doc updated on a known cadence — any of these work. In Openbook, teams typically use a Project Status room for exactly this: standing questions answered weekly, goals with red/amber/green status, and a narrative history you can skim in two minutes — so the manager checks the room, not the person. (This deserves its own discussion; see Seeing Without Surveilling.)
The norm to set with your team: "I'll never ping you for status that's already on the board. In exchange, keep the board honest." That trade — visibility for autonomy — is the entire deal.
The escalation clause
Every brief should include one more sentence: "Come to me immediately if X." Define X concretely: a slipped date you can't recover, a customer threatening escalation, spend about to exceed budget, a conflict with another team. An explicit escalation clause does two things — it tells the person that asking for help within those bounds is following the process, not failing at it, and it lets you stay out of everything else with a clear conscience.
When it goes sideways
Delegated work will sometimes come back late, off-target, or not at all. What you do next determines whether delegation gets easier or harder on your team.
Resist the take-back. The reflex is to grab the wheel: "I'll just finish it myself." Every take-back teaches two lessons you don't want taught — the report learns that struggling means losing the work, and you learn (falsely) that delegation doesn't work. Instead, shorten the leash without taking the wheel: move from Level 4 back to Level 3, add a checkpoint, pair on the hardest part. The work stays theirs.
Diagnose before you judge. Off-target work has exactly four causes: unclear brief (your fault), missing skill (a training problem), missing capacity (a workload problem), or missing will (a performance problem). The fixes are completely different, so get the diagnosis right. A useful script: "This isn't what I expected, and I want to figure out where we diverged. Walk me through how you approached it." Nine times out of ten you'll find the divergence traces back to something ambiguous in the handoff — which is good news, because briefs are easy to fix. The tenth time, you're in a different conversation — a performance conversation, which has its own playbook.
Do the post-delivery debrief. Two questions after any significant handoff, successful or not: "What would have made the brief better?" and "What would you want more or less of from me next time?" You're training yourself as much as them.
Absorb the misses publicly, credit the wins publicly. When delegated work succeeds, the person who did it gets named in front of the team and up the chain. When it fails, you own the failure upward — "I briefed that badly" — and handle the coaching privately. Managers who reverse this polarity (claiming wins, forwarding blame) find that nobody wants their delegated work ever again, and they're right not to.
Delegation as your development engine
Everything above treats delegation as workload management. Its bigger payoff is that it's the only scalable way to grow people. Courses teach concepts; delegated ownership teaches judgment.
Run it deliberately with a simple skill-transfer ladder for each significant responsibility you hold:
- They watch you. They sit in while you run the vendor negotiation, with a 10-minute debrief after on why you made the moves you made.
- You do it together. They lead sections; you're in the room.
- They do it, you watch. They run it end to end; you observe and debrief only afterward — resisting the urge to jump in is the hard part.
- They do it alone. Level 4, then Level 5. You've exited.
Each rung might take one repetition or several. The point is that the ladder is explicit and the person knows where they are on it: "You've run two of these with me in the room. Next one's yours solo — I'll be at my desk if it catches fire."
One caution: distribute stretch work fairly. There's a well-documented tendency for growth assignments to flow to whoever is most visible or most similar to the manager, while reliable quiet performers get the recurring grunt work "because they're so good at it." Audit yourself quarterly: list the last six meaningful things you delegated and who got them. If the same two names keep appearing, you're growing two people and benching the rest. This compounds — see Accountability Without Micromanagement for how visible, evenly distributed ownership changes team dynamics.
Common failure modes, quick reference
| Failure mode | What it looks like | The fix |
|---|---|---|
| Boomerang delegation | Work comes back to you half-done for "review" and never leaves again | Return it with questions, not edits: "What's your recommendation?" |
| Seagull management | No contact for weeks, then swoop in with sweeping changes at the deadline | Agree on checkpoints in the brief; honor them; change nothing outside them without naming why |
| Phantom delegation | You "delegated" but redo the work at night to your own standard | Decide the real quality bar before delegating; if 85% is enough, ship their 85% |
| Level mismatch | They shipped what you expected to approve, or waited for approval you didn't expect to give | State the authority level in one sentence, every handoff |
| Dump-and-run | Task handed off with no context, no resources, no checkpoints | Use the six-part brief; if you can't spare 20 minutes to brief it, you can't delegate it yet |
| Favorite-horse syndrome | All stretch work goes to the same one or two people | Quarterly audit of who got the last six meaningful assignments |
| Reverse delegation | "Quick question" chains that gradually move the thinking back to you | Answer questions about constraints and context; return questions about the work itself: "What are the options you're weighing?" |
Your next two weeks
Delegation improves through reps, not resolutions. Here's a concrete start:
- Days 1–5: Run the task log. Every task over 20 minutes, marked K, D, or T.
- Day 5: Pick exactly one D task — recurring, clearly delegable, matched to someone's growth interest if possible. One. Overhauling your entire plate at once produces five bad briefs instead of one good one.
- Day 6: Write the six-part brief. Choose the authority level deliberately — probably Level 2 or 3 for a first handoff.
- Day 7: Deliver the briefing live, get the playback, put the checkpoints on the calendar, and set up wherever ambient status will live.
- Weeks 2+: Honor the checkpoints, stay out of the gaps, run the debrief after delivery. Then pick the next task, and move this one up a level next cycle.
Do this once a fortnight and within two quarters you'll have moved five or six real responsibilities off your plate, each one now owned by someone who's better for having it. That's the job: not doing the work, but building the team that does.
If the "ambient visibility" piece is what's missing on your team — status you can check without asking — that's the problem Openbook's Project Status and Check-in rooms were built for, alongside boards your whole team can see. Take a look at the features and set up a space where delegated work stays visible without a single "how's it going?" ping.