skip to content

How do you decide what to delegate and what to keep on your own plate?

level: seniorimportance: should knowfreq 54%

answer

  1. state your keep-or-hand-off rule first
  2. outcomes handed over, not chopped-up tasks
  3. match the work to a growth edge
  4. define done out loud, together
  5. the checkpoint where you did not take over

basics

~20 s

Tests whether you hand out whole outcomes rather than chopped-up tasks. Answer with a stated rule for what only you can hold, work matched to someone's growth edge, an agreed definition of done, and light checkpoints.

how to answer

6 beats
  1. the rule you use to decide
    Open with one sentence a listener could repeat back — what stays with you, and what that category has in common. Keep it to about fifteen seconds; the rest of the answer earns it.
  2. what you kept, and why only you could hold it
    Name one or two concrete things and the reason each is genuinely yours — an external commitment, an irreversible call, a relationship that sits with you. Avoid listing everything technical as unteachable.
  3. who you handed it to and why them
    Say what made this person the right stretch, not just the available pair of hands. Naming the risk you accepted in choosing them is stronger than claiming they were obviously ready.
  4. what done meant, agreed out loud
    Give the actual shape of the agreement: how many lines, when it was written, who wrote it. State that the judgement calls travelled with the work, or the hand-off was a task list.
  5. the checkpoints and what happened at one
    Give the cadence, then spend your time on a single checkpoint where the news was not good. What you said in that moment is where most of the signal in this answer lives.
  6. the result and what stuck afterwards
    Close with one number and one durable change — they ran the next one alone, or they now hold a decision you used to hold. This is roughly the last quarter of your airtime; do not let it become a footnote.

your answer

5 story prompts
pick a story
  • List three things you handed off last year and one you deliberately kept, with the reason for each.
  • Pick one hand-off where the person ended up solving it differently than you would have.
  • Write the definition of done you actually agreed, in one sentence, as you agreed it.
  • Recall a checkpoint where the news was bad and note the first thing you said.
  • This can reuse your coaching or missed-deadline story, re-angled to the hand-off decision.

draft and rehearse your own answer in a learn session

go deeper

Delegation is the clearest read on whether someone scales beyond their own hands. The interviewer is probing ownership, judgement about people, and comfort with being accountable for work you did not do. A strong answer shows a repeatable rule, work handed over as an outcome rather than a task list, and trust that survives the moment things wobble.

at senior level

I lead quality on client engagements at a software agency, usually five testers spread over two or three accounts. My rule is that I keep the things where my name is the reason an answer gets accepted, and everything else goes out as a whole outcome rather than a list of tickets. On one engagement the client's checkout release was nine days out and our regression pass rate had stalled around sixty-eight percent. The obvious move was to run the suite myself. Instead I gave one of the mid-level testers the outcome — our team signs this release off, and she decides what signed off means — and we wrote that definition in four bullets before she started. I kept two things: the client-facing readiness call, because the account relationship sat with me, and the decision to actually recommend a delay. We agreed two checkpoints: a fifteen-minute look at the failure list on day three, and a dry run of her sign-off argument on day seven. At the day-three check the flaky tests were eating her week, and I nearly pulled the triage back myself. I asked what she wanted to do instead, and she quarantined thirty-one tests with an owner and a date on each. Pass rate was ninety-three percent on the day of the call, and she gave the readiness summary while I sat there and said nothing. The part I care about is the next release: she set her own checkpoints and I only heard about it at the end.

why this lands

The signal sits in two beats: naming what he kept and why, and the day-three checkpoint where he felt the pull and asked a question instead of taking the work. The closing line about the next release is the evidence that this was development, not load-balancing. It would downlevel if the definition of done stayed a claim rather than four written bullets.

at principal level

I run the quality practice at the agency — nineteen testers across seven client engagements, each with its own lead. At that scope I am not deciding which tasks to hand out. I am deciding which judgements live permanently with the leads, and what evidence I need in order to not review them. What I held back was narrow: which accounts get a dedicated lead, the written standard for what ready-to-ship means, and the escalation where we tell a client we are recommending a slip. Suite design, tooling, who runs which release, automate or stay manual — all of that became standing authority for the leads, not something they asked me for each time. The hard part was evidence. We were computing regression pass rate three different ways, so a lead reporting ninety-one percent told me nothing I could compare. I did not fix it by auditing their numbers. Two of the leads wrote the definition, we adopted it across all seven accounts, and the review turned into a forty-minute session every second Friday where leads read each other's readiness calls instead of reading mine. Where I got it wrong: on one account I kept the ship decision about four months longer than I needed to, and that lead was visibly waiting for permission on things she already owned. I said so out loud and gave it up. Two quarters later the spread in pass rate between our strongest and weakest engagement had gone from twenty-two points to six, and three leads were running accounts I never looked at.

why this lands

This reads as principal because the unit being delegated is authority, not work, and the safety net is a written standard plus a peer review others run. The admission about holding one decision four months too long is what keeps it credible. It would downlevel immediately if it described per-task hand-offs or if the speaker stayed the reviewer of every number.

for a junior

You are rarely the delegator yet, so answer from the receiving end and from small hand-offs: a task you passed to a peer while you were out, or work you took on because someone trusted you with the outcome. Show that you know what a clear hand-off felt like.

for a middle

Scope is a feature or a workstream. Talk about splitting work with peers, writing down what done means so nobody guesses, and asking for the whole problem rather than tickets. One example of coaching someone through a piece you could have done faster yourself lands well here.

for a senior

Interviewers expect a rule they can repeat back, applied to a real team. Name what stayed with you and why only you could hold it, how you sized the hand-off to the person, and the checkpoint cadence. Include the moment you felt the pull to take the work back and did not.

for a principal

Talk about delegating standing authority, not individual pieces of work: which decisions live permanently with leads, what written standard makes that safe, and what evidence reaches you. Name a mechanism others now run without you, and the authority you held too long before giving it up.

saying these in an interview costs you the question

  • Describing delegation as offloading whatever you personally find boring
  • Handing out chopped-up tasks and calling the result ownership
  • No agreed definition of done, then blaming the person for missing it
  • Checkpoints that are really daily status interrogations
  • Quietly redoing the work yourself and never saying so
  • Naming only what you hand off, never what you deliberately keep

  • What do you never delegate?
    Give a short, principled list rather than a long one: decisions where your name is the reason the answer is accepted, and calls whose consequences you cannot hand over. Say why each is genuinely yours today, and be ready to admit one thing on that list is there out of habit rather than necessity. Interviewers listen for whether the list shrinks as your team grows.
  • How do you know it is on track without hovering?
    Describe checkpoints agreed in advance rather than status requests invented mid-flight, and say what you look at rather than who you ask. Strong answers name an artefact the work itself produces, so the signal arrives without an interruption. Add what you do when a checkpoint looks bad: ask what they want to do before you offer what you would do.
  • When do you step back in and take the work over?
    Have a threshold, not a mood. Usually it is customer harm, a commitment to someone outside the team, or a deadline that no longer has room in it. Say the step-in out loud rather than doing it quietly, keep it scoped to the specific decision, and hand it straight back. Never taking over reads as absent; taking over often reads as the real answer to this question.

## How the prompt is asked This prompt appears in most lead, staff and manager loops, and it is usually asked flat: "how do you decide what to delegate?" The common variants are: - "what do you keep for yourself?", - "how do you decide who gets what work?", and - the softer "how has what you do personally changed as your team grew?" All four are answered by the same material, so prepare **one rule and three short illustrations** rather than four separate stories. ## Weak versus strong The **weak answer** is a taxonomy with no teeth: "I delegate things that are not urgent and keep the critical path." It sounds reasonable and it says nothing, because it never mentions a person. The **strong answer** sounds like a decision procedure applied to named humans. Two things do most of the work. ### Outcome versus task The first is **outcome versus task**. - Handing someone a list of tickets is scheduling, not delegating; they cannot make a judgement call because you have already made all of them. - Handing someone an outcome — this release is signed off, this migration lands, this customer stops reporting the bug class — gives them the decisions along with the work. Interviewers listen for whether your hand-offs contain any decisions at all. A useful test to state out loud: if the person cannot surprise you with how they solved it, you delegated a task. ### Fit to growth edge The second is **fit to growth edge**. - Delegation to the person who will do it fastest is load-balancing; - delegation to the person for whom it is one step past their current range is development. The strong answer names the stretch explicitly and names the safety net that made the stretch responsible — a checkpoint, a named fallback, a decision you kept. ## Evidence, strongest first The evidence types that carry this prompt are worth choosing deliberately. 1. **Strongest** is what someone did later without you: they ran the next one themselves, they set their own checkpoints, they now hold a decision you used to hold. 2. **Next strongest** is a moment you did not take the work back, described with the pull you felt, because that is the only part of the answer a candidate cannot fake by reading a management book. 3. **Weakest**, and unfortunately most common, is a list of categories of work you delegate. ## Defining done Defining done deserves one specific sentence rather than a claim. - "We agreed what done meant" is a claim; "we wrote four bullets before she started, and the fourth was that she decides, not me" is evidence. - Same with checkpoints: give the cadence and what happened at one of them, especially a checkpoint where the news was bad. What you did in that thirty seconds is the whole signal. ## The bar shifts sharply with level - At **mid-level** this is a peer-collaboration answer: you split work, you write down the contract, you avoid duplicating each other. - At **senior** it is a team answer: you hold the customer-facing or irreversible calls, you hand out everything else whole, and you can point at someone who grew. - At **principal** it stops being about work items entirely and becomes about standing authority — which decisions permanently belong to leads, what written standard makes it safe to not review each one, and what evidence reaches you instead. A principal answer that is still describing per-task hand-offs downlevels itself. ## One trap worth naming Candidates often over-rotate into never intervening, as if any step-in were a failure. Interviewers do not believe it, and it reads as absence rather than trust. Have a stated threshold for taking a decision back, say it out loud to the person when you use it, keep it to that decision, and give it back. Delegation is not abdication, and the sentence that proves you know the difference is usually the one about the time you did step in and why that case was different.

context