Delegation

Delegation is the most underrated tool in performance management. Most managers treat it as a workload-distribution problem — "I have too much, so I hand some off." That framing misses the point. Delegation is the primary way you grow people. You develop engineers mostly by handing them work that stretches them and supporting them through it — not by talking to them about growth in a 1:1. The conversation is the map; delegation is the journey.

It is also the skill managers get wrong in the two opposite directions, and both are damaging: micromanagement (delegating the task but not the authority) and abdication (delegating the task and disappearing). The whole craft lives in the space between them.

Why Delegation Is a Growth Tool

• People grow by doing, not by watching. No amount of feedback substitutes for owning a hard thing and figuring it out. Stretch work is the gym.
• It's the only way to scale. A manager who does the important work themselves caps the team at their own throughput and grows no one. A manager who delegates the important work multiplies the team.
• It surfaces readiness. Watching someone handle delegated scope is the clearest evidence of whether they're operating at the next level — exactly what promotion packets need.
• It builds ownership. People care about and improve at what they own. Borrowed tasks get borrowed effort.

The mental shift: stop asking "can I do this faster myself?" (you usually can, today) and start asking "who would grow from owning this, and can I afford to let them learn on it?" The first question optimizes for this week; the second optimizes for the team's capacity in six months.

Levels of Delegation

Delegation is not binary — it's a dial. A useful scale (adapted from Management 3.0's "delegation poker") runs from most to least manager control:

Two things make this powerful:

• The level should be explicit. Most delegation disasters are a mismatch of unstated expectations — the manager thought "inquire," the report thought "tell," and now there's a re-litigated decision and a bruised relationship. Say which level you're at.
• The level is per-task, not per-person. A senior engineer might be at level 7 on backend architecture and level 2 on a customer-facing comms decision they've never handled. Match the level to the person's competence on this specific thing, not their seniority in general.

Matching Task to Person

Good delegation is a deliberate match, not whoever's free.

• Stretch, don't snap. The task should be a notch beyond what they've done — uncomfortable but achievable with support. Too easy and they don't grow; too far and they fail in a way that damages confidence.
• Match to growth direction, not just current skill. The most valuable delegation gives someone the next-level work they need to demonstrate readiness (see career frameworks). Delegate toward where they're going.
• Vary the kind of stretch. Technical depth, scope/coordination, ambiguity tolerance, stakeholder management — people need to grow on different axes. The engineer who's technically strong but never led anything needs a coordination stretch, not a harder algorithm.
• Account for the cost. A stretch task takes longer and may need rework. That's tuition, not waste — but budget for it. Don't put a critical-path, no-slack task into a level-2 stretch and then panic.

Autonomy vs Oversight

Once you've delegated, the hard part is staying involved at the right altitude. Two principles:

Delegate the outcome, not the method. Define what done looks like and the constraints (deadline, quality bar, things that must not break), then let them choose how. If you specify every step, you've delegated typing, not the work — and they learn nothing about judgment. Their method will differ from yours; if it meets the bar, that's fine, and sometimes it's better.

Set checkpoints, not surveillance. Agree up front on when you'll sync — milestones, a demo, a design review — rather than hovering or vanishing. Checkpoints give you signal without taking over, and give them room to work without feeling watched. Frontload the oversight: more checkpoints early when the cost of a wrong direction is low, fewer as trust on this task builds.

A good handoff makes the boundaries explicit:

• The outcome — what success looks like, concretely.
• The constraints — the deadline, the quality bar, the non-negotiables.
• The authority — what they can decide alone, what needs a check-in. (This is the delegation level, made explicit.)
• The support — how to reach you, when you'll sync, that asking for help is expected, not failure.
• The why — the context behind the task, so they can make good calls when reality differs from the brief.

Micromanagement and Abdication

The two failure modes are mirror images, and most managers lean reliably toward one.

Micromanagement delegates the work but keeps the decisions — redoing people's work, demanding it be done your way, requiring sign-off on trivia. It signals distrust, kills ownership, and trains people to stop thinking ("why bother, they'll change it anyway"). It also doesn't scale — you become the bottleneck on everything.

Abdication is the over-correction. The manager, wanting to seem trusting (or just overloaded), hands off complex work with no clarity, no support, and no checkpoints — then is surprised when it goes wrong, and blames the person. It's not empowerment; it's negligence wearing empowerment's clothes.

The space between them is supported autonomy: clear outcome, real authority over method, agreed checkpoints, and genuine availability for help. You're on the hook for the outcome; they own the doing.

Catching yourself

Some honest diagnostics:

• Micromanaging? Do you redo delegated work to match your style? Need to approve small things? Feel anxious not knowing exactly what everyone's doing right now? Find people stop making decisions without you?
• Abdicating? Do you hand off complex things with a one-line brief? Avoid checkpoints because they feel like nagging? Get surprised by how delegated work turned out? Reach for blame when it goes wrong?

Building Ownership

The deepest goal of delegation is ownership — people who treat a piece of the system as theirs and improve it without being asked.

• Delegate whole problems, not slivers. "Own our flaky test problem" builds ownership; "go fix these three tests" doesn't. Whole problems invite judgment, prioritization, and pride.
• Let them keep what they build. Ownership grows when someone lives with the consequences of their decisions — runs the thing they built, fixes the bugs, hears the user feedback. Hand it off the moment it ships and you've cut the feedback loop that creates judgment.
• Let the method differ, and let small failures stand. If you override every decision or rescue every stumble, it's still your problem, not theirs. People own what they're allowed to get wrong and recover from.
• Credit publicly, correct privately. Ownership requires the upside being theirs. If you take the credit, it was never really delegated.

Anti-Patterns

• The bottleneck manager. Keeps all the important work, delegates only the dull bits. Caps the team at their own throughput and grows no one.
• Delegating tasks, hoarding authority. Micromanagement by another name — they do the work, you make every call.
• Delegate-and-vanish. Abdication. Complex work, no support, then blame.
• Unstated delegation level. Manager and report assume different levels; collision and resentment follow.
• Delegating only to the strong. The reliable senior gets everything; everyone else stays junior. Spread the stretch.
• Taking it back at the first wobble. Pulling work back the moment it's imperfect teaches helplessness and guarantees you'll never offload it.

The Bar To Hold

Delegate whole outcomes (not just tasks) at an explicit and appropriate level of authority, matched to the person's growth direction, with the method left to them and checkpoints agreed up front — staying genuinely available without hovering, and letting them own both the decisions and the credit.

Delegation is where career growth actually happens, where 1:1s get their material, and where you make yourself progressively less necessary — which, per the overview, is the whole point.