The Delegation Audit: Decide Which Tasks You Should Stop Doing Yourself
Why this prompt matters
A manager who personally holds 10+ hours a week of tasks that could be delegated isn't just losing their own time — they are actively training their team to route everything through them instead of building judgment of their own, which compounds every quarter the pattern continues. Teams with a single unacknowledged bottleneck typically discover the cost only when that person goes on leave or leaves the company, at which point the backlog and the missing institutional knowledge surface at the same time, with no transition plan in place.
What we use it for
You manage a team of six and personally review every pull request, approve every expense under $500, and write the weekly customer-facing release notes — roughly 11 hours a week combined. You added two senior engineers in the last two quarters specifically to take on more ownership, but you still haven't handed any of these three tasks to either of them, and you can't fully articulate why beyond “it's just faster if I do it.”
Prompt
Role: Act as an operations consultant who specializes in workload audits for managers and individual contributors who have quietly become the bottleneck on their own team — the person everything routes through because no one formally decided it should. Context: [YOUR ROLE AND TEAM SIZE] [LIST OF 5-10 RECURRING TASKS YOU PERSONALLY HANDLE, WITH ROUGH HOURS PER WEEK EACH] [WHO ELSE ON YOUR TEAM COULD PLAUSIBLY TAKE EACH TASK, IF ANYONE] [FOR EACH TASK, YOUR REASON FOR STILL DOING IT YOURSELF — e.g., “faster if I just do it,” “they don't have the context,” “it's sensitive,” “no one else wants it”] [ANY HARD CONSTRAINTS — budget for new hires, tools that only you have access to, approvals only you can legally or contractually sign off on] Task: Produce a delegation audit in four parts: (1) a per-task verdict — Keep, Delegate, Automate, or Eliminate — with reasoning that directly tests the excuse supplied for each task; (2) the two strongest delegation candidates, with a named or role-based recipient and what context-transfer looks like; (3) a direct challenge to any task where the stated reason for keeping it reveals a trust or management gap rather than a real workload or skill gap; (4) a 30/60/90-day handoff plan for the top delegation candidate only. Constraints: - Do not recommend delegating a task that requires judgment, authority, or legal sign-off above the proposed recipient's actual level — flag those as Keep even if they are time-consuming. - Do not accept “faster if I just do it” as a valid reason to keep a task unless the stated hours-per-week are under 30 minutes; otherwise, treat it as a training-investment problem and say so. - Every verdict must reference the specific hours, reason, or constraint supplied in the context — no generic “you should delegate more” language. - If three or more tasks share the same stated reason for not being delegated (e.g., “they don't have the context” for everything), call this out explicitly as a pattern, not a coincidence. Output Format: 1. Task audit table — columns: Task, Hours/Week, Verdict, Reasoning 2. Top 2 delegation candidates — recipient and what needs to transfer 3. Pattern check — any excuse repeated across 3+ tasks, named directly 4. 30/60/90-day handoff plan for the single highest-value delegation candidate
Result
Task audit table:
| Task | Hours/Week | Verdict | Reasoning |
|---|---|---|---|
| Reviewing every pull request | 5 | Delegate | At 5 hours/week this is well above the 30-minute threshold for “faster if I do it” to hold up. Your two senior engineers were hired specifically for more ownership — this is a training investment, not a bottleneck you need to protect. |
| Approving expenses under $500 | 1.5 | Delegate | No legal or contractual reason this needs you specifically — it is a dollar-threshold rule, not a judgment call. A senior engineer or team lead can take this with a simple written policy. |
| Writing weekly release notes | 4.5 | Delegate | Customer-facing tone matters, but tone is teachable and reviewable in under 15 minutes once a template exists. This is the easiest of the three to hand off because it is a writing skill, not a judgment call. |
Top 2 delegation candidates:
- Pull request review → Senior Engineer A. What transfers: your actual review checklist (not just “use your judgment”), access to the two repos with branch-protection admin rights, and a two-week period where they review first and you spot-check their approvals before stepping back fully.
- Release notes → Senior Engineer B. What transfers: the release-notes template, the Slack channel where customer-facing language gets flagged for tone, and the last 8 weeks of your notes as reference examples so they can match the voice before writing solo.
Pattern check:
You did not give the same excuse for all three tasks, which is a good sign — but note that both pull request review and release notes share an unstated version of “I'm the only one who has the full context,” when in both cases the actual blocker is that you have never written the context down anywhere. That is a documentation gap wearing a disguise as a context gap, and it will recur with the next task you try to hand off unless you fix the underlying habit of keeping process knowledge in your head.
30/60/90-day handoff plan — pull request review (highest-value candidate):
Days 1-30: Write down your actual review checklist — the 6-8 things you are really checking for beyond “does it work,” including the 2-3 things that have caused production incidents before. Hand it to Senior Engineer A along with the two repos. They review every PR first; you review their approvals same-day for the first two weeks.
Days 31-60: Drop your spot-check rate to one in three approvals. Have a 20-minute retro every Friday on anything they flagged as uncertain — this is where the real checklist gets corrected and expanded.
Days 61-90: Stop reviewing their approvals entirely. Keep a standing invite to be looped in only on PRs touching payments or auth, which should be the only carve-out left requiring your sign-off by day 90.
Most managers who feel overloaded can list exactly what is eating their week, but they rarely interrogate why they are still the one doing it. The Delegation Audit exists to force that interrogation — not by telling someone to “delegate more,” which is advice no one can act on, but by testing each specific excuse against each specific task until only the genuinely non-delegable ones survive.
Why “faster if I just do it” needs a time threshold, not a vibe check
The constraint that “faster if I do it” only counts as valid under roughly 30 minutes a week is the load-bearing rule in this prompt. Above that threshold, speed is not actually the variable that matters — it is a signal that no one else has been trained, and training time is being avoided by paying the task's full cost every single week indefinitely instead. A manager spending 5 hours a week on something because it is “faster” than teaching someone else is choosing a small recurring cost over a one-time training cost, forever.
Why the pattern check matters more than any single task
Auditing tasks one at a time misses the structural problem: when the same justification shows up across three or more tasks, it stops being a fact about those tasks and starts being a fact about the manager. “They don't have the context” repeated across unrelated tasks almost always means the context was never written down anywhere a successor could find it — which is a fixable documentation problem, not a permanent feature of the role.
Why the output deliberately hands off only one task at full depth
A 30/60/90 plan for three tasks at once reads as a wish list and rarely survives contact with a real week. Forcing the model to pick the single highest-value candidate and go deep — checklist, access, spot-check cadence, a real date to stop checking — produces something a manager can actually start on Monday, instead of a tidy table that gets filed away and never executed.
How to adapt it
This works for any role where work has quietly concentrated around one person: a team lead who approves every ticket, a founder who personally handles every customer escalation, an individual contributor who has become the only one who understands a legacy system. List the real tasks with real hours, name the actual excuse for each one, and let the prompt separate genuine constraints from habits that have outlived their reason.