Most new managers delegate in one of two ways. Either they hand something over with one line in a chat message and find out three weeks later that it went sideways, or they hand it over and then check on it so often that the engineer quietly gives the decisions back. Both feel like delegation from the manager's side. Neither feels like it from the other side. This post gives you a way to decide how much to hand over, a short brief to hand it over with, and a check-in rhythm that fits the person instead of your anxiety.
Why both failure modes happen
Andy Grove made the core point in High Output Management: delegation without follow-through is abdication. You stay accountable for the outcome of anything your team does, whether you did the work or not. Handing over a task doesn't hand over that accountability, so you still need some way to know how it's going.
The hovering failure is the opposite mistake. You know you're accountable, you don't trust the signal you're getting, so you check everything. The engineer learns that their decisions will be second-guessed and starts asking you before making any. Within a month you've delegated the typing and kept the thinking.
What both have in common is that the manager never decided, explicitly, two things: which decisions now belong to the other person, and how they'll find out if things are going wrong. Fix those two and most delegation problems go away.
Decide how much authority you're handing over
"Can you own the search migration?" can mean anything from "do what I say" to "it's yours, tell me when it's done." Jurgen Appelo's Delegation Poker, from Management 3.0, gives you seven named levels so you can be specific:
| Level | What it means | Example phrasing |
|---|---|---|
| 1. Tell | I decide and tell you | "We're using Postgres. Please set it up." |
| 2. Sell | I decide and explain why | "We're using Postgres, and here's my reasoning." |
| 3. Consult | I ask for your input, then I decide | "Give me your view on the options by Thursday; I'll pick." |
| 4. Agree | We decide together | "Let's sit down and agree the approach." |
| 5. Advise | You decide, after hearing my view | "Your call. Here's what I'd watch out for." |
| 6. Inquire | You decide, then tell me | "Your call. Let me know what you went with." |
| 7. Delegate | You decide; I don't need to hear about it | "Yours entirely." |
You don't need to play the card game to use the levels. What matters is that you name one, out loud, when you hand something over. "You're at level 5 on the schema design and level 7 on everything inside the service" removes a whole category of awkward conversations later.
Two practical notes:
- The level can differ inside one piece of work. The API contract with another team might be level 4; the internal implementation level 7; the go-live date level 3 because you've already promised it to someone.
- Levels 1 and 2 are not delegation. They're instructions. That's fine sometimes, but don't call it ownership.
Match the level to the person and the task
The right level depends less on how senior someone is and more on how much experience they have with this kind of work. Grove called this task-relevant maturity. A staff engineer who has never run a vendor evaluation is new at it; a mid-level engineer who has run three database migrations is not new at the fourth.
This lines up with Hersey and Blanchard's situational leadership, covered in the PTMP study guide: directing for someone new to a task, coaching as they build skill, supporting when they're capable but unsure, delegating when they're capable and confident. A rough mapping:
| Their experience with this kind of task | Starting level | Your style |
|---|---|---|
| None | 3 (Consult) | Directing: agree the plan in detail |
| Some, with help | 4 (Agree) | Coaching: decide together, explain your reasoning |
| Done it before, a little unsure | 5 (Advise) | Supporting: give input, let them decide |
| Done it well several times | 6 or 7 | Delegating: stay out of the way |
Then adjust for risk. The question isn't "Could this go wrong?" (everything can) but "If it goes wrong, how hard is it to undo?" A reversible decision, like which library to try or how to structure a sprint, can go a level higher than the table suggests. A one-way door, like a public API that customers will build on or a data deletion, can go a level lower. Say why when you do that, so it doesn't read as a judgment of the person.
Start one level lower than you think, and plan to move up. Raising someone's authority after a good first week feels like recognition. Taking it back after a bad one feels like a demotion.
Hand it over with a five-line brief
Most delegation goes wrong in the first conversation, because the manager knows things they forget to say. Write the handover down. It takes five minutes and it doubles as the record both of you check against later.
Outcome: what "done" looks like, in terms someone outside the team would recognize.
Why it matters: who it's for and what happens if it doesn't get done.
Your authority: the delegation level, plus anything that's already decided.
Constraints: deadline, budget, systems or people not to touch.
Check-ins: when we'll talk about it, and what would make you come to me sooner.
A worked example, hypothetical: say you're handing a search-indexing rework to Priya, who has built two services on the team but never led a migration.
Outcome: product search reads from the new index, and the old indexing job is switched off, with no increase in search errors.
Why it matters: the old job is our biggest source of on-call pages; support wants fewer "search is stale" tickets before the holiday peak.
Your authority: level 5 on design and rollout plan (you decide, I'll give input); level 7 on implementation; level 3 on the cutover date, because I've told support it'll be before December 1.
Constraints: cutover before December 1. Don't change the search API response format; the mobile team depends on it.
Check-ins: 20 minutes on Tuesdays until the design is agreed, then a written update every Friday. Come to me straight away if the cutover date looks at risk or if you need time from another team.
Notice what's missing: how to do it. If you find yourself writing the solution into the brief, you're at level 1 or 2, and you should say so honestly.
Set check-ins that fit, then loosen them
Follow-through doesn't mean watching. It means agreeing in advance where you'll look, so you don't need to look anywhere else. Grove treated it like quality control in a production line: check early, while problems are still cheap to fix, and check more often the less task-relevant maturity the person has.
A rhythm that works for most delegated work:
- Early and often at the start. The first check-in should come before any major work is done: a short review of the approach. This is where most misunderstandings surface, and it's cheap to fix them here.
- At natural milestones after that. Design agreed, first part in production, cutover. Not daily, unless the work is daily.
- Written by default. A three-line Friday update ("done, next, worried about") costs the owner five minutes and saves you from asking.
- Loosen on a schedule, not on a feeling. After two or three check-ins with no surprises, say so and reduce them: "This is going well; let's drop Tuesdays and keep the Friday note."
The one rule that matters most: when you check in, ask before you tell. "What are you weighing up?" or "What would you do if I weren't here?" gives you the information you need without taking the decision back. If you disagree with their choice at level 5 or above, say what you'd do and why, then let it stand. Overruling a decision you've delegated costs more trust than most bad technical choices cost time.
When it goes wrong
Sometimes it will. How you respond decides whether the next delegation works.
- They're stuck, not wrong. Drop one level temporarily and say it's temporary: "Let's decide this one together, then it's back with you."
- The outcome is at real risk. Step in, but be explicit about what you're taking back and for how long. Then, in your next one-on-one, work out together which part of the brief was unclear or which check-in missed the signal.
- They made a call you wouldn't have. If it's reversible and within their level, let it run. You'll learn whether your instinct was right, and so will they.
Most of the time, when delegation fails, the brief was vague or the check-ins were in the wrong place. Look there first, before deciding the person wasn't ready.
Your first step
Pick one piece of work you're currently holding onto because "it's faster if I do it." Write the five-line brief for it, including a delegation level for each decision inside it, and hand it over this week. Then put the first check-in in both calendars before you end the conversation.
The question to ask yourself a month later: which decisions on my team still route through me, and is that because they have to, or because I never said they didn't?