Delegation: letting go without losing control

Your team is three months old. The product roadmap has just changed. One of your engineers, Priya, needs to own migrating a critical authentication service to a new provider — the kind of task that, if it goes wrong, wakes up the VP at 2 a.m. You want to give her the work. You also have a small, quiet voice saying: “But what if she does it wrong?”

So you write a twelve-step Jira ticket. You schedule daily check-ins. You re-read her pull requests before she can merge anything. Two weeks later the migration is done, on time, correctly. Priya resigns the following month. In her exit interview she says she felt like a pair of hands, not an engineer.

This is the dump-or-hover trap. New leaders who overcorrect from “I must do everything” land in micromanagement. Those who overcorrect from “I must empower my team” dump whole outcomes on people who are not ready for them, then vanish until the deadline. Both postures destroy trust. The question is not whether to delegate — everything you do yourself does not scale past a team of one — but how to calibrate the level.

The Delegation Ladder

Think of delegation as a ladder with five rungs. Each rung describes how much decision authority you are handing off, and each maps to a different kind of conversation.

Rung 1 — Tell. “Do exactly this. Here is the step-by-step.” Used for brand-new hires on high-risk tasks, or for one-off work where there is genuinely only one right answer. This is not a permanent state; it is an onboarding phase. If you are still on Rung 1 with someone after six months, one of you has a problem.

Rung 2 — Show me your plan first. “Here is the outcome. Come back with your approach before you start.” The person has some experience; you want to catch misunderstandings before they become half-built solutions. Feedback happens at the plan stage, not the implementation stage. This is the rung most experienced ICs (individual contributors) who have just been promoted to lead should start on with their team.

Rung 3 — Start, then check in at milestones. “Own the approach. We meet at these three points so I can unblock you or course-correct.” The person is capable but the task is novel or the stakes are high. You agree upfront: the check-in exists to spot structural drift, not to second-guess every commit message.

Rung 4 — Keep me informed. “You own this. Tell me when something goes sideways or when a decision has cross-team impact.” Used for a trusted senior engineer or a capable mid-career IC who has done this type of work before. Your job is to be available, not to hover.

Rung 5 — Fully own the outcome. “You decide everything. I may not even hear about this unless you choose to loop me in.” Reserved for staff-level or equivalent, on tasks squarely inside their domain. This is the mode that lets you, as a manager, actually spend time on strategy, hiring, and the work only you can do.

The ladder is not a ranking of people. It is a calibration tool for a specific person on a specific task. Your senior architect might live at Rung 5 for system design and at Rung 2 for anything involving compliance — because compliance is new territory for them, not because they are junior.

Delegate the outcome and the why, not the keystrokes

This is the principle most managers get wrong, and it costs them in two directions at once.

When you hand someone a task by specifying every step, you are removing the very cognitive load that makes work engaging and that builds judgment over time. The person follows the recipe. They do not develop the mental model that lets them improvise when step four encounters an unexpected situation. You also make yourself a bottleneck: any deviation requires a call to you.

When you hand someone a task by specifying only the outcome — “get the auth service migrated by Friday” — without context, you deprive them of the information they need to make good tradeoffs. Is availability more important than a clean rollback path? Is the deadline hard or soft? Are there political landmines with the infra team? They will make guesses, and some of those guesses will be wrong in ways that were entirely preventable.

The right conversation sounds like this: “The outcome I need is: auth migration done, no downtime, rollback tested, security team signed off. The reason this matters now is that we have a compliance audit in two weeks. The main risk I see is that the identity provider’s API is poorly documented — expect surprises there. Given all that, what is your plan, and where do you want my input?”

You have handed off the outcome, explained the why, named the known risks, and invited them to surface their approach before committing. That is Rung 2 or 3, done well.

Agree on check-ins upfront; do not improvise surveillance

One of the most common ways well-intentioned managers undermine delegation is by checking in at irregular intervals driven by their own anxiety. The engineer is heads-down on Thursday afternoon; you tap on their shoulder or send a Slack message asking “how is it going?” This is not accountability — it is interruption. And it signals that you do not actually trust them to surface problems when problems arise.

The alternative is to name the check-in structure at the moment you delegate. “We will sync on Tuesday to look at the rollback plan together, and again on Thursday once the staging run is done. Between those, if anything is blocked or looks different from what we expected, reach out and we will make time immediately.” Now the engineer knows exactly when to expect contact. They can batch their questions. They are not spending cognitive cycles wondering whether you are about to tap their shoulder.

The check-in should also have a clear agenda: it is not a status update for its own sake. It is a structural review — are we headed in the right direction, are there risks you have found that change the plan, do you need any resource or decision from me? If the answer to all three is “no, we are on track,” the meeting should end in four minutes.

Why doing it yourself does not scale

There is a seductive argument that says: I am faster at this than they are, the cost of the mistake is too high, it is just quicker if I do it.

This is true, once. It is catastrophically false as a strategy.

When you absorb tasks your team should be doing, three things happen. First, your team stops developing the judgment that would eventually make them able to handle more. The people who are not growing are the people who eventually leave for somewhere that does let them grow. Second, you fill your own calendar with work that should be two levels below your job description, leaving no time for the planning, stakeholder management, and hiring that are genuinely yours to do. Third, you create a single point of failure: when you are sick, traveling, or managing a crisis elsewhere, the work stops.

The cost of delegation is a higher short-term error rate and a real investment of your time in teaching. The return is a team that gets stronger every quarter and a personal capacity that is not permanently capped by the number of hours you can work.

A simple test: write down the five things you did last week that only you could have done. If that list has fewer than three items, you are probably not delegating enough. If that list has more than five, you have not defined your job correctly.

The experience-and-risk matrix in practice

Combining the two axes — person experience with this type of work, and task risk — gives you a quick calibration every time you delegate.

A new analyst running their first customer report: Rung 1 or 2 regardless of their overall capability. The stakes of a wrong number reaching a client are real, and they have no schema yet for what “good” looks like in your specific context.

An experienced data engineer you have worked with for two years, migrating a non-critical internal tool: Rung 4 or 5. You are not the right reviewer; you are the safety net if the building catches fire.

An experienced person taking on a task that is new to them — say, a strong backend engineer leading their first external API integration: Rung 3. Their engineering judgment is sound, but the specific surface area is novel. Milestone check-ins let you catch directional drift without hovering over every commit.

The mistake is calibrating to comfort rather than to the intersection of experience and risk. If you are on Rung 2 with a senior engineer on a routine task, you are managing your anxiety, not managing the work.

A word on letting people fail small

Contained failure is one of the best learning mechanisms available. If you catch every mistake before it happens, the person never builds the instinct for catching their own mistakes. There is a class of errors — wrong approach, not wrong direction — where the right call is to let the work proceed, observe the result, and debrief afterward. This requires you to have calibrated the risk correctly: the failure must be recoverable, the cost must be bounded, and the learning must be proportionate.

This is different from setting someone up to fail. You have given them the right rung, explained the outcome and the why, and agreed on check-ins. Within that structure, if their approach turns out to be suboptimal and they discover it themselves, the debrief is worth ten times any amount of pre-emptive correction.

The conversation you are actually avoiding

Most delegation failures are not about frameworks. They are about a conversation the manager does not want to have. Telling someone their plan needs to change before they execute it is uncomfortable. Saying “this task is at a level where I need you to show me your approach first, because the stakes are high” feels like distrust.

But the alternative — either micromanaging silently or handing something off without enough structure — is more corrosive. It is just more comfortable in the moment.

The best managers I have seen are direct about the level they are delegating at and why. “I am giving you Rung 3 on this, not because I doubt you, but because I do not know this vendor well and I want a checkpoint before we are committed.” That sentence takes twelve seconds to say. It prevents two weeks of misaligned expectations.

Pick your rung, explain it, and commit to the check-in structure you agreed to. Then get out of the way.