Day 13 · 2026.06.02

Delegation: From Micromanaging to Trust Levels

Topic: Delegation·4 Principles
"It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do." — Steve Jobs
This week's thesis: Delegation isn't "I'm too busy, hand off the work." It's whether you can shift from being your team's strongest doer to the person who multiplies others' output—the hardest leap from IC to manager. The cost of not delegating is structural: your team's output ceiling equals your personal bandwidth; and the prerequisite for your promotion is precisely proving you can scale output that doesn't depend on you. But delegation isn't abdication either—"hands-off vs. micromanage" is a false binary. The real craft lives in between: the same task calls for different levels depending on the person and their maturity. Four principles: figure out what only you can do (the Delegation Matrix), the seven levels of delegation (the Trust Ladder), give the "monkey" back when someone brings you a problem (Coaching vs. Telling), and after letting go, use guardrails instead of surveillance and tolerate the 80% solution.
PRINCIPLE 01

List What Only You Can Do; Delegate the Rest by Default The Delegation Matrix

Delegation MatrixLeverageTrade-offs
Don't ask "can I hand this off?" Ask the reverse: "What are the few things only I can do?" Write that short list (rarely more than 5 items), and delegate everything else by default. Decide on two axes only: how high the leverage for the org, and whether someone else can do it to 80%.
"The most effective management style ... depends on the task-relevant maturity of the subordinate—the more experienced he is at a specific task, the more the manager should delegate." — Andy Grove, High Output Management, Ch.7
Leverage → Can someone else do it to 80%? → High leverage · only you Do it—but it's a dangerous single point. Grow a successor now High leverage · others can Delegate + heavy coaching Your main battleground Low leverage · only you Document / automate it— kill the dependency on you Low leverage · others can Delegate outright, don't touch— the cell to let go of first
Context: You spend 6 hours a week on things "others could do to 80%"—writing the team status, triaging bugs, approving routine PRs.
✗ Common mindset

"I do these faster and better, and teaching takes time—easier to just do it myself."
→ That's an account that counts today, not the year. A year later you're still writing the status, no one has grown, and you have no room for what only you can do (strategy, cross-team, developing talent).

✓ Better

Delegate the whole bottom-right cell (low leverage · others can). When you hand off the status: "From next week the status rotates. This isn't busywork—writing it forces you to see what the whole team is doing, which sharpens your view of the big picture. I'll give you a template and we'll do the first one together."

Key: reframe "I'm dumping this on you" as "this is valuable for you," give a template + a first run together, and don't vanish after handing it off.

  • Is my "only I can do this" list over 5 items? That usually means I haven't grown people, not that it's truly only me.
  • How many bottom-right (low leverage · others can) items am I still doing myself this week?
  • For each top-left item (high leverage · single point), have I named a successor?
  • Is what I delegate only the boring busywork? Am I also sharing the high-leverage growth opportunities?
  • "I'm faster" is a short-term account. The first time you teach is slow, but by the tenth time they do it solo you've already earned it back.
  • Only delegating the boring stuff. Reports aren't stupid—give only chores, keep the glamorous work for yourself, and they leave.
  • Reverse delegation. You delegate, then it gets "asked back" to you and lands on your desk again—Card 3 treats this.
Female Leader's Note Two effects stack on women leaders (Babcock, The No Club, on "non-promotable work"): (1) women are more likely—by themselves and others—to be assigned "office housework": notes, organizing team events, mentoring newcomers—low-leverage, non-promotable work that crowds out what should be delegated or declined; (2) when women assign tasks they're more readily labeled "bossy / pushy," while men's identical behavior reads as "leadership." Counter: frame delegation openly as "rotation + growth," and put glue work on the rotation too (neither hoard it nor get labeled).
This week: Write your "only I can do this" list. Over 5 items? Circle the ones that are really "I haven't grown people" and name someone to start coaching for each.
Reflection: The thing you spent the most time on last week—which cell does it fall in? If it's bottom-right, what mindset kept you from letting go?
PRINCIPLE 02

Delegation Is a Seven-Step Continuum, Not an On/Off Switch The Trust Ladder — Seven Levels of Delegation

Trust Ladder7 LevelsExplicit Boundary
Most micromanagement comes from one misconception: that delegation has only two settings—"I decide" and "you decide." It's actually a seven-step ladder, from "I decide and tell you" to "you have full authority and I stay out." Same task: level 3 for a newcomer, level 6 for a veteran. Saying out loud which step you're standing on erases half the misreads and hurt feelings.
"Delegation is not a binary thing. There are seven levels of delegation, from telling people what to do up to fully delegating a decision. Make the level explicit." — Jurgen Appelo, Management 3.0 (Delegation Poker / 7 Levels)
Their autonomy → 1 Tell 2 Sell 3 Consult 4 Agree 5 Advise 6 Inquire 7 Delegate
1 Tell = I've decided, informing you · 2 Sell = I've decided, but I'll convince you · 3 Consult = I hear you first, then I decide · 4 Agree = we decide together · 5 Advise = I give input, you decide · 6 Inquire = you decide first, then tell me · 7 Delegate = you decide, no need to tell me
Context: The same task—designing the API contract for a new service—goes to two different people.
✗ Common

Same level for everyone: either you don't trust it and watch every endpoint (effectively level 1), or you toss out "your call" (level 7) in one line. A newcomer drowns at level 7; a veteran suffocates at level 1.

✓ Better: say the level out loud

To the newcomer (level 4 · Agree): "We'll decide this API together. Draft a version, and Wednesday we'll review and decide together—not a test, I want you to see how I weigh trade-offs."

To the veteran (level 7 · Delegate): "This is yours—design, finalize, ship. Just drop a note in the channel when it's done; you don't need my sign-off. Pull me in on any point you want."

The key is that one line—"I'm at level X on this"—so both know the boundary and avoid the "I thought you'd ask me first" landmine.

  • For this delegation, did I say "which level" explicitly? Or assume they could read the boundary in my head?
  • As the same person's TRM rises, am I moving the level up? Or still stuck at level 3 a year later?
  • Am I "level 7 in words, level 2 in body"—saying it's yours, then quietly editing their PR?
  • When I temporarily drop a level (e.g., taking the decision back in a crisis), did I explain why? A silent downgrade = a distrust signal.
  • Same level for everyone. The level is a function of "person × task," not your fixed personality.
  • Saying one level, doing another. Level 7 in words but level 2 in action hurts trust more than "I'm watching" from the start—because you also lied.
  • Never leveling up out of fear of not getting it back. Levels move both ways; try level 5 first and drop back if it breaks—better than locking at level 3 so they never grow.
This week: Pick a task you own and a report, decide "which level you're handing it to," and say the exact line "I'm at level X on this" when you assign it.
Reflection: Who on your team is locked at level 3 without your being able to name a reason? Is that a real capability gap, or your need for control?
PRINCIPLE 03

When a Report Brings a Problem, Give the Monkey Back First Coaching vs. Telling

CoachingReverse DelegationQuestions
A report brings a problem; the moment you give an answer, the "monkey" (ownership of the problem) jumps from their back to yours—and next time they'll come ask again. Most of the time your job isn't to solve, it's to let them solve it and grow. Give a little less answer, ask one more question.
"Tell less and ask more. Your advice is not as good as you think it is. Stay curious a little longer, rush to action and advice-giving a little more slowly." — Michael Bungay Stanier, The Coaching Habit
Context: A mid-level engineer walks over—"I can't decide on the architecture, do you think Kafka or just SQS?"
✗ Don't say immediately

"SQS—simpler, our volume isn't that high, Kafka is overkill."
→ You solved it in 3 seconds and also took the decision with you. Next selection, they'll come ask again. You become the team's bottleneck; they don't grow judgment.

✓ Try asking first (leave the decision in their hands)

· "Which way do you lean, and why?" (force out their judgment)

· "What's the worst case for each? Which is harder to recover from if it's wrong?"

· "What information are you still missing to decide yourself?" (often the answer is "actually, enough")

· Close: "Sounds like you lean SQS and the reasoning holds—this one's yours, I'll back you."

Boundary—don't be dogmatic: when it's urgent, touches safety, or they genuinely lack the background, telling is the right move—endlessly questioning a newcomer who needs direction isn't coaching, it's torture. First judge "are they asking for an answer, for authority, or truly without background," then decide whether to give the monkey back.
  • When they throw a problem, can I hold back and first reply "what do you think yourself"?
  • Did I distinguish: truly no background (should tell) vs. just wanting my endorsement (give the decision back)?
  • Even when I do tell, did I explain "why"? Or just hand over the conclusion?
  • After asking, did I leave silence and resist answering my own question?
  • The advice monster. You enjoy being the one with the answer too much—exactly the IC reflex a manager must unlearn.
  • Turning coaching into "guess the answer in my head." Asking "what do you think" then shooting down any wrong answer is sneakier, more wounding micromanagement.
  • Hard coaching when you should tell. Questioning when the building's on fire or a newcomer has no direction is irresponsible. Coaching isn't a master key.
This week: Catch at least one "report comes to ask you what to do" moment, force your first sentence to be a question not an answer, and note how far their final decision was from your expectation.
Reflection: Recall the last time you "instantly answered" a report—if you'd first asked "what do you think," could they have reached the answer? Were you helping them, or feeding your own sense of being needed?
PRINCIPLE 04

After Letting Go: Tolerate the 80% Solution, Use Guardrails Not Surveillance Guardrails, Not Surveillance

ToleranceReversibilityGuardrails
Once you delegate, accept two things: they'll do it differently from you, and they'll make recoverable mistakes. The key isn't watching closely but distinguishing reversible / irreversible: let go and let them try on reversible calls; step in and slow down only on irreversible ones. Anchor check-ins to milestones and metrics, not to your anxiety.
"Some decisions are consequential and irreversible or nearly irreversible—one-way doors... But most decisions aren't like that—they are changeable, reversible—they're two-way doors. Type 2 decisions can and should be made quickly by ... small groups." — Jeff Bezos, Amazon 2015 Letter to Shareholders
Two-way door · reversible Cheap to undo → fully let go Let them try, debrief after Resist the "I'd do it this way" urge e.g. internal tooling, naming, refactor order One-way door · irreversible Costly to undo → step in, slow down Decide together, be present but still let them lead and reason e.g. public API, data schema, hiring
Context: You review a report's implementation—it works, but it's not how you'd do it: a bit roundabout, optimizable, and fully reversible.
✗ Common

"Hold on, this part I think should be written like this…" then you take over and replace it with your version.
→ You won this PR and lost the long game: they learn "the boss will rewrite it his way anyway," and next time stop thinking and wait for you to decide.

✓ Better: judge reversibility, then use "I intend to…"

First ask yourself: "Is this reversible? If we find it's wrong in three weeks, is it costly to undo?" Not costly → let go. Tell them: "This runs; I'd pick another style, but that's taste, not right/wrongyour call. We'll glance at the metrics in two weeks and tune if there's a perf issue."

For senior teams, use Marquet's "I intend to…": let the report say "I intend to do X, because Y," and you only halt at the irreversible or fatal points.

  • Before wanting to step in, did I ask "is this reversible"? If reversible, did I hold back?
  • Are my check-ins anchored to milestones/metrics, or to my anxiety about "wanting to know progress"?
  • Did we agree on red lines and milestones up front? And after agreeing, did I refrain from hovering in between?
  • After they fail, do I run a blameless debrief on improving the system, or settle scores and pull authority back?
  • When results land, did I publicly credit them by name?
  • Treating "different from me" as "wrong." The 80% solution + their growth often beats the 100% solution + their dependence.
  • Not even letting go of reversible things. If every two-way-door decision needs your sign-off, the team forever runs at your single speed.
  • Settling scores when things go wrong. Delegate, then audit after a failure, and next time no one dares take work—you killed the delegation culture yourself.
  • Nominal delegation, actual surveillance. Daily "concern" about progress sends one signal: I don't trust you.
This week: When you hit a "report did it differently but it's reversible" moment, force yourself not to take over—just say "your call, we'll look at the data in two weeks."
Reflection: Your most recent takeover of a report's work—was that truly a "one-way door"? Or were you just uncomfortable that it "wasn't my way"?

Deeper Questions

How should delegation levels (the Trust Ladder) shift across seniority and culture?
Two dimensions. Seniority: newcomers need not level-7 "freedom" but a clear level 3-4; giving direction is kindness, while a veteran suffocates low on the ladder. Culture: in high-power-distance teams (common in East Asia), even senior reports may expect you to "give a direction," and a blunt "your call" can read as dumping or a test, not trust. The fix isn't less delegation but naming level 7 explicitly as "I trust your judgment"—don't leave a blank for them to guess.
For remote / async teams, where does delegation break first?
In person you get reassurance from "glancing as you pass"; remote has none of that. Two failure points: managers, unable to see the process, grow anxious and fall back to high-frequency status check-ins (disguised as "syncs") that are really micromanagement; and reports, lacking instant feedback, hesitate to make reversible decisions. The fix is to make trust upfront and explicit: write down milestones, red lines, and decision gates (which are reversible = just do it, which irreversible = pull me in), and replace "watching them work" with documents and demo checkpoints. Remote delegation rests on systems, not tacit understanding.
Big company vs. startup: where's the real risk for BigCat as a big-company tech lead manager?
Big-company delegation carries higher political cost: a report botches a cross-team project and the fire reaches you, so the instinct is to fall back to micromanaging and review everything yourself. But that's the trap—the prerequisite for the next level is demonstrating "scaling without you": the team still produces and decides when you're absent. A team that always depends on you is your promotion ceiling, not your moat. The real risk isn't "delegation goes wrong," it's "not delegating = you and the team stuck in place together." Treat reversible mistakes as the cost of development, guard the irreversible doors—that's the realistic way to balance this tension in a big company.
The delegation-accountability tension: when something goes wrong, who's actually responsible?
This is delegation's most honest gray zone. What you can delegate is responsibility (the execution); what you can't is accountability (the final answer upward)—to your boss, you're still the one who has to explain. This means a deliberate asymmetry: on success the credit goes publicly to the report; on failure you carry the blame upward. That's not nobility—it's the structural cost of the leader role: you trade "shielding them" for "their willingness to own and to risk." If you can't do this (pushing the report out front when things go wrong), the delegation culture dies at the first failure and no one dares take any autonomy you offer.