Delegate Work

---
name: delegate-work
description: Use when a manager needs to transfer ownership of a task or responsibility to a direct report — to clarify scope, authority, and success criteria upfront so the work transfers completely rather than bouncing back.
source: "Oncken & Wass \"Management Time: Who's Got the Monkey?\" (Harvard Business Review, 1974 — one of HBR's most-reprinted articles); Hackman & Oldham Job Characteristics Model (1976); Management 3.0 Delegation Boards (Jurgen Appelo)"
tags: [delegation, ownership, manager, autonomy, task-transfer, empowerment, reverse-delegation, authority]
---

# Delegate Work

Transfer a task or responsibility to a direct report with clear scope, authority level, and success criteria — so the work moves completely without bouncing back through ambiguity or over-checking.

## Why This Is Best Practice

**Adopted by:** Oncken & Wass's 1974 HBR article "Management Time: Who's Got the Monkey?" is one of the three most-reprinted articles in Harvard Business Review history, establishing the principle that managers who do not delegate effectively become bottlenecks carrying their team's work; Hackman & Oldham's Job Characteristics Model (1976), the standard framework for work design at most large organizations, identifies autonomy as the primary driver of intrinsic motivation; Google's Project Oxygen manager effectiveness framework lists "empowers the team and does not micromanage" among the top manager behaviors
**Impact:** Gallup's meta-analysis (2015) found that delegating CEOs — those who excelled at delegating — generated 33% greater revenue than non-delegating CEOs in a study of 143 CEOs at Inc. 500 companies; Hackman & Oldham's field research (1976, replicated extensively) found that autonomy — the degree to which a job provides freedom and discretion — is the single strongest predictor of internal work motivation; managers who do not delegate accumulate work until they become the team's bottleneck, reducing throughput and developing no one
**Why best:** Delegation failures trace to three causes: (1) unclear scope — the employee takes over work outside the intended boundary; (2) unclear authority — the employee brings every decision back to the manager (reverse delegation); (3) unclear success criteria — the employee completes the task but delivers something the manager considers wrong; all three are cured by explicit upfront definition, not by better follow-up

Sources: Oncken & Wass, Harvard Business Review (November 1974); Hackman & Oldham "Motivation Through the Design of Work" (Organizational Behavior and Human Performance, 1976); Appelo "Management 3.0" (Addison-Wesley, 2010); Gallup "State of the American Manager" (2015)

## Steps

### 1. Choose what to delegate

Delegate tasks where:
- The employee has (or can develop) the competence — see `apply-situational-leadership` to assess readiness
- Your involvement does not add meaningful value beyond what the employee brings
- The work will develop the employee's capability

Do NOT delegate:
- Tasks where your personal judgment or relationships are the actual product ("represent the team to the executive")
- Tasks the employee clearly cannot do yet without support — that requires coaching, not delegation
- Performance management of other individuals — never delegate a manager's responsibility to a peer

### 2. Define scope explicitly

Unclear scope is the most common delegation failure. Before handing off, answer these in writing or in conversation:

```
What exactly is being delegated?
  "Lead the Q3 customer migration project from kickoff through go-live."

What is NOT included?
  "Budget decisions above $10k require my sign-off. Changes to the migration 
  timeline that affect external commitments need my awareness before communication."

What are the deliverables?
  "A kickoff deck shared with me by May 1, weekly status updates to the team, 
  a go-live report within one week of completion."
```

Underdefined scope leads to the employee either over-reaching (taking on things they shouldn't) or under-reaching (constantly asking permission for things they should own).

### 3. Define the authority level

Most delegation failures occur here. Tell the employee explicitly what decisions they can make without you and what requires your involvement. Use a clear framework:

| Level | What it means | Example |
|---|---|---|
| **Level 1 — Inform** | Make the decision, then tell me | "Decide the project schedule — let me know what you landed on." |
| **Level 2 — Consult** | Consult me before deciding | "Before you commit the team to a timeline externally, run it by me." |
| **Level 3 — Recommend** | Bring me a recommendation, I decide | "Bring me a vendor recommendation with your rationale — I'll make the final call." |

Assign authority levels to each significant decision type within the delegated scope. Leaving authority level ambiguous guarantees reverse delegation — every decision comes back to the manager.

### 4. Define success criteria

State clearly what "done well" looks like:

```
"This project is a success if: (1) all 200 accounts are migrated by August 15 
with zero data loss, (2) customer satisfaction score on the migration process 
is ≥ 8/10, (3) we document the runbook so future migrations can run without me."
```

Success criteria allow the employee to self-assess without constant manager input, and give both parties a shared basis for evaluation at the end.

### 5. Agree on milestone check-ins — not micromanagement check-ins

Define upfront when you will check in, and what you expect to see at each point. This is different from checking in whenever you feel anxious.

```
"I'd like a brief status at our weekly one-on-one through the project, 
and a heads-up if you hit a blocker that changes the timeline or scope. 
Otherwise, I'll trust you to run it."
```

Pre-defined milestones are the agreed boundary between oversight and micromanagement. Ad-hoc check-ins beyond the agreed cadence signal distrust and undermine the delegation.

### 6. Resist reverse delegation

Reverse delegation occurs when the employee brings the problem back to the manager for a decision that is within their delegated authority. Common form: "I'm not sure what to do here — what do you think I should do?"

The correct response is not to answer the question. Instead:

```
"That's within your authority on this project. What are your options? 
What would you do?"
```

If they genuinely don't know, coach them through it (see `apply-grow-coaching`). If they know but lack confidence, affirm their authority: "You've got this — what does your judgment say?"

Every time you solve a problem that belongs to a delegate, you reclaim that monkey. Over time, the manager's desk is covered in monkeys that should be owned by the team.

### 7. Debrief the delegation, not just the output

After the work completes, debrief what the employee learned — not just whether the outcome was good:

```
"Looking back at how you ran that project — what worked well? What would 
you do differently? What did you learn that you'll apply to the next one?"
```

This closes the development loop. Delegation without debrief produces output but not growth.

## Rules

- Define scope, authority, and success criteria before starting — verbal "you've got this" is not delegation; it's abdication
- Assign authority levels explicitly for each significant decision type — vague authority = every decision bounces back
- Agree on the check-in cadence upfront — don't improvise follow-up; pre-defined milestones protect against both micromanagement and neglect
- Resist solving delegated problems — the moment you solve a problem you delegated, you take back the monkey; coach instead
- Match delegation to readiness — delegating to someone not yet capable without adequate support sets them up to fail; use `apply-situational-leadership` to assess

## Common Mistakes

- **"Let me know if you need anything"**: this is not delegation; it places the burden of asking on the employee and does not transfer ownership or authority.
- **No authority definition**: the employee makes decisions, then learns they needed approval; trust erodes, productivity drops, work returns to the manager.
- **Checking in constantly**: repeated check-ins beyond the agreed cadence signal distrust; the employee disengages from ownership because the manager is clearly still running the work.
- **Delegating delivery but not decisions**: "you run the project but all decisions come to me" is not delegation; it is task assignment with an illusion of ownership.
- **Delegating upward**: the manager takes back the problem when the employee brings it. The monkey moves from the employee's desk to the manager's desk, often permanently.

## When NOT to Use

- For work where the employee's development level is D1 (enthusiastic beginner with no demonstrated competence on this task) — delegate to D3/D4; coach and direct D1/D2 employees instead.
- For personnel decisions about peers — performance feedback, conflict management, and compensation decisions belong to the manager, not to other team members.
- During a crisis where the manager's specific judgment is the actual value-add — some situations require a senior decision-maker, not a delegate; read the context.