skip to content

Tell me about a time you delegated something important and it went off track.

level: seniorimportance: should knowfreq 41%

answer

  1. the work and why handing it over mattered
  2. outcome, definition of done, checkpoint agreed
  3. the signal something was wrong
  4. what you did instead of taking it back
  5. the number, the cost, the change you kept

basics

~10 s

Probes whether your trust survives contact with bad news. Tell one hand-off that slipped, what you saw at the checkpoint, and how you fixed the system rather than quietly reclaiming the work.

how to answer

6 beats
  1. the work and why you handed it over
    Set the stakes in two or three sentences and say what handing it over was for. Situation and task together should take under a fifth of your airtime.
  2. how you set the hand-off up
    Give the outcome you named, what done meant, and the checkpoint you agreed. Being concrete here is what makes the later failure a system failure rather than a character judgement.
  3. the signal that it was going wrong
    Name what you saw and when, in plain terms. Say whether it reached you through the checkpoint you designed or by accident — the accidental route is a more honest and more interesting answer.
  4. what you did instead of taking it back
    This is the bulk of your airtime, around sixty percent across this beat and the previous one. Give the actual words: what you told the person, what decision you left with them, and what you did take on yourself and said out loud.
  5. the result, stated honestly
    Include the cost — the slip, the awkward conversation, the number that was worse than promised — alongside what recovered. A clean result with no cost sounds edited.
  6. the change you made to how you hand off
    End with one durable change in your process and where you have applied it since. Result and reflection together are roughly the last quarter of the answer.

your answer

5 story prompts
pick a story
  • Pick a hand-off you owned in the last two years where the outcome, not just the task, moved.
  • Choose one where things slipped and you stayed out of the delivery.
  • Write down the checkpoint you set and exactly what you saw at it.
  • Name the cost out loud: the slip, the awkward call, the number worse than promised.
  • Name one change to how you hand work over that came out of it.

draft and rehearse your own answer in a learn session

go deeper

The interviewer wants to see delegation under stress, where composure is cheap and behaviour is not. This probes ownership of an outcome you did not personally produce, judgement about when to intervene, and whether you repair the system or reclaim the work. A strong answer keeps the other person's ownership intact while still telling the truth to whoever was waiting.

at senior level

On a client mobile release at the agency, I gave the release-readiness judgement to a tester who had never made that call in front of a client. There were four of us on that engagement and I wanted her holding it before I rotated onto another account. I set it up the usual way: she owned the outcome, we wrote three lines on what ready meant, and we booked a checkpoint for the Monday before the demo. What I never asked was how she was counting. At the checkpoint she reported the suite at eighty-eight percent and it sounded fine. Two days later I was reading a run log out of curiosity and saw that retries were being scored as passes. The true regression pass rate was nearer sixty-two, with the demo three days away. Everything in me wanted to grab the suite, fix the counting and present the numbers myself. I did not. I showed her what I had found, told her plainly that I had missed it too by not asking, and left the decision with her: what do we tell the client, and when. She chose to call that afternoon and ask for four working days. We went into the demo at ninety-four percent with retries excluded, and the client's own QA lead said it was the first time our figures matched theirs. The uncomfortable phone call was the entire cost. Since then, how a number is computed is part of every hand-off I do, not something I stumble on later.

why this lands

Strong because the failure is located in the hand-off design — no agreement on how the number was computed — and the recovery leaves the decision and the client call with the tester. Saying he missed it too is what keeps the relationship intact. It would downlevel if he had fixed the counting himself and presented the result.

at principal level

I had three engagements running against one client programme, each with its own quality lead, and I handed the whole gate to those leads — including the authority to tell the client's programme manager that a release was not going out. About six weeks in, one of them let a release ship below a threshold none of us would have accepted, because the programme manager pushed hard and he did not believe refusing was really his to do. That is a delegation failure and it was mine. I had granted the authority in a meeting and given him nothing to stand on when someone senior leaned in. The tempting repair was to put myself back in the room as the person who says no. I deliberately did not. We wrote the gate down as a joint artefact with the client — the threshold, who declares it, what happens when it is missed — and the leads presented it, not me. Then I told the programme manager, with the lead sitting there, that his call was final and I would not overturn it. Next time it came up he held the line without me in the room, and that release slipped six working days instead of going out broken. The number I watch is not any one release. Across the programme, releases going out under the agreed threshold fell from roughly one in four to one in fourteen over two quarters, and I stopped being the escalation path for any of them.

why this lands

This is principal-level because the diagnosis is structural — authority granted verbally with no artefact behind it — and the repair is a mechanism plus a public transfer of standing, not a rescue. The willingness to say the failure was his own, and to measure across releases rather than one, is what carries the signal.

for a junior

Use a small hand-off you were part of — covering for someone, splitting a task with a peer, receiving work that was under-specified. What matters at this level is noticing early that expectations were unclear and raising it rather than absorbing it silently.

for a middle

Feature or workstream scope. Show the mechanics: what you wrote down, when you checked, what you saw, and how you raised the gap with a peer without taking their work. A recovery you did jointly reads better here than one you performed alone.

for a senior

Team and delivery scope, including the conversation with whoever was waiting on the outcome. The bar is that the person kept ownership through the wobble, that you were honest with the stakeholder on time, and that the fix changed your hand-off process rather than your opinion of the person.

for a principal

The failure should be structural — authority given in a meeting with nothing behind it, a standard that existed only in your head, an escalation path that ran through you. The repair should be a mechanism others operate, and you should be able to say what it cost before it worked.

saying these in an interview costs you the question

  • A story where the lesson is that you should have done it yourself
  • Taking the work back silently and letting the person find out later
  • Blaming the person for a definition of done you never wrote
  • No bad moment at all, which means the hand-off was never real
  • Ending at the rescue with no change to how you delegate now

  • What was the first sign, and could you have seen it earlier?
    Name the signal precisely and be honest about the lag between when it existed and when you noticed. Strong answers point at a checkpoint that was scheduled too late or measured the wrong thing, and describe the earlier signal they now watch for. Avoid answering that you should simply have checked more often — that reads as more supervision rather than better design.
  • How did that person feel about how you handled it?
    Interviewers are checking whether the relationship survived. Say what you told them directly, including that you found the problem yourself, and what they owned afterwards. Evidence beats assertion: they stayed on the work, they ran the next one, they told you about the following problem earlier. If the relationship did suffer, say so and say what you would change.
  • What would you do differently next time?
    Give one change to how you hand work over, not a resolution to trust people less. Good answers change the contract — what done means, how a number is computed, when the first checkpoint falls, what triggers an early escalation. Keep it to a single change you actually applied afterwards, and say where you applied it.

context