Delegation
Meera still reviews every payments pull request herself, because she knows that code better than anyone. The review queue is now eleven deep, and Kabir has waited two days for her approval on a one-line fix. The person slowing the team down most is its manager.
The rule
Delegate the outcome, not the steps, and match check-ins to experience.
A good handoff has three parts:
- The outcome, and why it matters. "Payments changes get a careful review within a day, so nothing unsafe ships and nobody waits" says what success looks like. "Check lines 40 to 90 of every pull request" is a list of steps, and it leaves the person no room to think.
- The authority. Say what they can decide alone and what they should bring back. There are roughly three levels:
- Bring me options, and you still decide.
- Decide, then tell me before you act.
- Decide and act, then tell me afterwards.
- The check-in rhythm. Someone new to the area gets short, frequent check-ins; someone experienced gets a milestone or two. Agree this up front, so a check-in feels like support rather than suspicion.
Delegating is not abandoning. Meera is still accountable for the result, so she stays available and steps in if things go badly wrong. Some work stays with her: confidential people issues, performance conversations, and anything else only the manager can do.
What should go first? Work that someone else can do nearly as well as you, and work that would stretch someone who is ready for it. Often those are the same task.
The shortcut
Ask: "Is this something only I can do?" If not, ask two more questions: who would grow from it, and how much support will they need?
The only-me test
Could someone else review payments code? Yes. Priya knows it nearly as well as Meera does.
There is a trap on each side. Snatching back means quietly redoing the work or checking every detail, which tells people the handoff was never real. Dumping means handing over work with no outcome, context or support, and then blaming the person when it goes wrong.
Drills
Answer fast — trust the rule.
Which request delegates well, handing over an outcome rather than steps?
Neha has never worked with the payment gateway. Which check-in rhythm fits best?
Which of these should Meera keep rather than delegate?
Priya approves a payments pull request. Meera quietly re-reviews it and asks for changes herself. What has happened?
Remember
- Delegate the outcome, not the steps, and match check-ins to experience.
- Ask "is this something only I can do?" If not, who would grow from it, and how much support do they need?
- Avoid both traps: snatching the work back, and dumping it without context.