Most engineering leads are promoted for being good at doing the work. Then the job changes: the output that counts is the team's, not yours. Andy Grove put it as a definition in High Output Management: a manager's output is the output of the organization under them. Every hour you spend on a task someone else could own is an hour not spent on the work only you can do.
Delegation is how that shift happens, and it fails in two predictable ways. The first is not letting go: the lead reviews every pull request, makes every design call and becomes the bottleneck of the team. The second is letting go too far: a task is handed over with a vague "you own it now", and the lead finds out three weeks later that it went in the wrong direction. Grove has a word for the second one: abdication.
This cheatsheet collects the tools that make delegation explicit: levels of authority, the "monkey" model of who holds the next move, context instead of control, task-relevant maturity, checkpoints, and a section on what changes when part of the team's work is done by AI assistants.
1. Vocabulary
| Term | Meaning |
|---|---|
| Delegation | Transferring ownership of an outcome, plus the authority to make the decisions it requires. Not the same as assigning tasks |
| Assignment | Handing over a piece of work with the decisions already made. Useful, but it does not grow anyone |
| Abdication | Handing over an outcome and then not following up. In Grove's words: "Delegation without follow-through is abdication." |
| Decision area | A category of decisions: architecture, hiring, release timing, tool choice, vendor selection |
| Delegation level | How much of a decision the other person makes, from "I decide" to "you decide, I do not even need to know" |
| Monkey | Oncken and Wass's metaphor for the next move on a problem. Whoever holds it has the work |
| Checkpoint | A pre-agreed moment to review progress. Its timing and form are part of the delegation |
| Task-relevant maturity (TRM) | Grove's term for how ready someone is for a specific task, not for their job in general |
The core idea: delegation is a set of explicit agreements. What is the outcome, who decides what, when do we check in, and what happens if something goes wrong. Most delegation failures are one of these left implicit.
2. Seven levels of delegation (Management 3.0)
Jurgen Appelo's Management 3.0 (the book appeared in 2010) breaks the false choice between "I decide" and "you decide" into seven levels:
| Level | Name | What it means | Example for an engineering lead |
|---|---|---|---|
| 1 | Tell | I decide and tell you | "We are moving to the new CI provider on the 15th" |
| 2 | Sell | I decide and try to convince you | "Here is why we are standardizing on Postgres" |
| 3 | Consult | I ask for your input, then I decide | "What do you think of these two API designs? I will pick by Friday" |
| 4 | Agree | We decide together | Team agreement on the on-call policy |
| 5 | Advise | I give advice, you decide | "I would add a feature flag, but it is your call" |
| 6 | Inquire | You decide, then tell me | "Choose the logging library and let me know what you picked" |
| 7 | Delegate | You decide, I do not need to know | Internal refactoring, naming, test structure |
How to use it:
- Delegation poker. Each person privately picks a level for a decision area, everyone reveals at once, and you discuss the differences. The discussion is the point: the lead who thinks "release timing" is level 5 and the senior engineer who thinks it is level 2 have just found a future conflict.
- Delegation board. A simple grid: decision areas as rows, levels as columns, a marker per area. Put it in the team wiki. Review it every few months as people grow.
- Levels are per decision area and per person, not per team. The same engineer can be at level 6 on database choices and level 3 on customer commitments.
- Moving up is the goal. Each step up the ladder is a step of trust. Write down what would need to be true to move a decision area up one level.
3. Who's got the monkey?
William Oncken Jr. and Donald L. Wass published "Management Time: Who's Got the Monkey?" in the November-December 1974 issue of Harvard Business Review. HBR reissued it in 1999 as a classic with a commentary by Stephen R. Covey. Its opening question still describes many engineering leads: why are managers running out of time while their people are running out of work?
The metaphor: a monkey is the next move on a problem. When an engineer says "we have a problem with the deploy, let me know what you think" and the lead answers "let me look into it", the monkey has jumped from the engineer's back to the lead's. The engineer now waits; the lead now works for the engineer. Do that a dozen times a week and the lead's calendar fills with other people's next moves.
Five degrees of initiative
Oncken and Wass describe five degrees of initiative a person can take, from lowest to highest:
| Degree | Behavior | What it means for the lead |
|---|---|---|
| 1 | Wait until told | The lead does all the thinking |
| 2 | Ask what to do | The monkey lands on the lead |
| 3 | Recommend, then take the resulting action | The lead decides between options someone else prepared |
| 4 | Act, but advise at once | The lead stays informed, the work stays with the owner |
| 5 | Act on own, then routinely report | The lead reviews outcomes, not steps |
Their advice is to stop accepting degrees 1 and 2. The practical version: when someone brings a problem, ask for their recommendation ("what would you do?") and agree on which degree applies before the conversation ends.
The rules of monkey care and feeding
Paraphrasing Oncken and Wass:
- Monkeys should be fed or shot. A problem should either get attention or be explicitly dropped. Starving monkeys produce surprises.
- Keep the monkey population below what the lead has time to feed. If you cannot check in on it, you cannot delegate it at that level.
- Feed monkeys by appointment. Scheduled check-ins, not hunting people down or being ambushed in the hallway.
- Feed them face to face or by phone, not by mail. A written reply to a problem usually makes the next move yours again.
- Every monkey has a next feeding time and a degree of initiative. They can change by mutual agreement but should never become vague.
Translated to engineering: the ticket, the design doc or the incident follow-up has a named owner, a next step that owner will take, a date when you will look at it together, and an agreed degree of initiative. If any of the four is missing, the monkey is probably on your back.
4. Context, not control
"Context, not control" and "highly aligned, loosely coupled" are two of the principles in the Netflix culture deck that Reed Hastings and Patty McCord published in 2009, and both are still in Netflix's culture memo. The idea: instead of controlling how people do the work, give them enough context to make the decision you would make, or a better one.
For an engineering lead, context means:
| Context | Example |
|---|---|
| The goal and why it matters | "Checkout latency is our top churn driver; p95 under 300 ms is the target" |
| Constraints | Budget, deadline, compliance rules, systems that must not change |
| What good looks like | Acceptance criteria, an example of a past design that got it right |
| What has been tried | "We tried a cache here in 2023; it broke invalidation for promotions" |
| Decision rights | The delegation level for each decision area involved |
| Who to involve | Stakeholders, reviewers, the security contact |
A useful test after a bad decision: ask "what context did they not have?" before "why did they do that?". Most bad delegated decisions are context failures.
Context is not the same as being hands-off. "Highly aligned, loosely coupled" only works if alignment is real: shared goals, shared definitions of done, and the lead staying close enough to the work to notice when alignment drifts.
5. Task-relevant maturity
In High Output Management (1983), Andy Grove argued that there is no single best management style. The right style depends on the task-relevant maturity of the person for the specific task, which he described as a combination of achievement orientation and readiness to take responsibility, plus education, training and experience.
His table, roughly:
| TRM | Effective management style (Grove) | In engineering terms |
|---|---|---|
| Low | Structured, task-oriented: tell "what", "when" and "how" | Pairing, small well-defined tickets, detailed review, short feedback loops |
| Medium | Individual-oriented: two-way communication, support, mutual reasoning | Design discussions, the person proposes, the lead challenges and coaches |
| High | Minimal involvement by the manager: establish objectives and monitor | Agree on outcome and constraints, check in at milestones |
Three consequences that matter in practice:
- TRM is per task. A senior backend engineer may have high TRM for API design and low TRM for running a vendor negotiation or leading their first incident. Delegation level and checkpoint frequency should follow the task, not the title.
- TRM changes. It rises with experience and drops when the task, the team or the environment changes. A reorganization or a new domain resets it, even for strong people.
- Low TRM is not a reason not to delegate. It is a reason to delegate with more structure. Grove's point is that teaching is part of the supervisor's job, and that once someone is competent, delegating increases the manager's leverage.
Map TRM to the earlier tools: low TRM pairs with delegation levels 2-3 and degrees of initiative 2-3; high TRM with levels 5-7 and degrees 4-5.
6. Checkpoints: monitoring without meddling
Grove is explicit that delegation still needs monitoring: "Monitoring is not meddling," and you "can never wash your hands of a task." His suggestion is to check like a quality inspector samples output: go into details randomly, just enough to see that things are on track, not 100% of the time.
Agree on checkpoints at the moment of delegation, not later:
| Element | Decide upfront |
|---|---|
| Timing | Fixed dates or milestones: design ready, first deploy, half-way, before launch |
| Form | Short written update, a demo, a design review, a five-minute sync |
| Signals | What the owner should raise immediately: scope change, slipping date, a decision above their level |
| Frequency by TRM and risk | Low TRM or high cost of mistakes: early and often. High TRM and reversible decisions: milestones only |
| Exit | When does the lead step back further? When does the lead step in? |
Practical rules:
- Check early. The first checkpoint should come soon after the start. Direction errors are cheap in week one and expensive in week four.
- Inspect outcomes, sample details. Look at the result and a few random details (one PR, one test, one dashboard), not everything.
- Delegate what you know best. Grove's advice: since it is easier to monitor what you are familiar with, delegate the activities you know best when you have a choice. That is counterintuitive for leads who want to keep the work they enjoy.
- When you step in, say so. Taking a decision back is sometimes right, for example in an incident or a customer escalation. Do it explicitly ("I am taking this one back to level 3, here is why"), not silently.
7. What to delegate in an AI-assisted team
By mid-2025, AI coding assistants are part of most teams' workflow. The Stack Overflow 2025 Developer Survey, published in July, found that 84% of respondents use or plan to use AI tools in development, while more of them distrust the accuracy of those tools (46%) than trust it (33%). The top frustration, cited by 66%, was AI solutions that are "almost right, but not quite", and 45% said debugging AI-generated code takes more time.
That shapes delegation in three ways.
Delegation to people changes shape. When part of the typing is done by tools, what you delegate to engineers is more about judgment: problem framing, design trade-offs, review and verification, and ownership of outcomes. The monkey is no longer "write this function" but "make sure this works in production".
Delegation to tools needs levels too. It is useful to treat an AI assistant or agent like a new team member with very low task-relevant maturity on anything specific to your system, and to decide its level per decision area:
| Area | Reasonable level for AI tools | Human role |
|---|---|---|
| Boilerplate, tests for existing behavior, refactors with good coverage | High (the engineer reviews the diff) | Review and merge |
| Exploring an unfamiliar codebase or library, drafting docs | Advise: it suggests, the engineer decides | Verify claims against the source |
| Design and architecture decisions | Consult at most: it produces options | The engineer and lead decide |
| Security-sensitive code, data migrations, production access | Low, with strict review, or not at all | Full ownership and review |
| Customer commitments, priorities, people decisions | Not delegated | Lead and team |
Accountability does not transfer to the tool. Whoever merges the code owns it. Make that explicit in your team agreements: "the engineer who opens the PR is accountable for every line, whoever wrote it." It is the AI-era version of Grove's rule that you cannot wash your hands of a task.
What changes for the lead:
- Review capacity becomes the bottleneck. If tools increase the volume of code, the scarce resource is careful review. Delegate review explicitly, to people with the right task-relevant maturity, and keep changes small.
- Juniors still need to build maturity. If tools do all the low-TRM tasks, juniors lose the tasks that used to teach them. Delegate some work to them deliberately, with structure, even when a tool could do it faster.
- Context matters even more. AI tools and new team members fail in the same way: missing context. The context table in section 4 is also a good prompt and a good design doc template.
8. A one-page delegation template
Use it at the moment of handing something over. It takes ten minutes and saves weeks.
| Field | Example |
|---|---|
| Outcome | Checkout p95 latency under 300 ms by end of quarter |
| Why it matters | Latency is the top driver of abandoned carts |
| Owner | Ben |
| Decision levels | Technical approach: 6 (inquire). Changes to the payments API contract: 3 (consult). Scope cuts: 4 (agree) |
| Constraints | No new vendors, no schema changes to orders this quarter |
| Context | Previous cache attempt and why it failed; the dashboard to watch |
| Checkpoints | Design review in week 1, demo in week 3, weekly written update |
| Raise immediately | Scope or date risk, any decision above the agreed level |
| Degree of initiative | 4: act, but advise at once |
Why this matters
- A lead's output is the team's output. Time spent holding other people's monkeys is time not spent on work only the lead can do.
- Explicit beats implicit. Delegation levels, degrees of initiative and checkpoints turn vague trust into agreements that can be discussed and changed.
- Style follows maturity, per task. Grove's TRM explains why the same person needs close support on one task and freedom on another.
- Context is the main lever. Most bad delegated decisions come from missing context, not from bad judgment.
- AI changes what you delegate, not who is accountable. Tools can do more of the work; people still own the outcomes.
Final Thoughts
Delegation is not a single act of letting go. It is a set of small, explicit agreements that get revisited as people grow: who decides, who holds the next move, what context they have, and when you will look at it together.
Start with one decision area this week. Write down its current delegation level, ask the owner what level they think it is, and agree on the next checkpoint. If you cannot name the owner, the next move and the date, the monkey is yours.
Sources
- William Oncken Jr. and Donald L. Wass, Management Time: Who's Got the Monkey? (Harvard Business Review, November-December 1974; reissued November-December 1999 with commentary by Stephen R. Covey): the monkey as the next move, the five degrees of initiative, the rules of monkey care and feeding.
- Management 3.0, Delegation Poker and Delegation Board: the seven levels of delegation (tell, sell, consult, agree, advise, inquire, delegate), created by Jurgen Appelo.
- Jurgen Appelo, Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley, 2010): origin of the delegation levels.
- Andrew S. Grove, High Output Management (Random House, 1983; Vintage edition 2015): managerial output and leverage, task-relevant maturity and the matching management styles, "Delegation without follow-through is abdication", monitoring as sampling, delegating what you know best.
- Netflix, Netflix Culture: Freedom and Responsibility (culture deck first published by Reed Hastings and Patty McCord in 2009): "context, not control" and "highly aligned, loosely coupled".
- Stack Overflow, 2025 Developer Survey: AI (July 2025): 84% using or planning to use AI tools, 46% distrust vs. 33% trust accuracy, 66% "almost right, but not quite", 45% say debugging AI-generated code takes more time.