An incident has been running for six hours and the same person has held Incident Commander since it started. How do you hand off the IC role mid-incident without losing the response, and what does the handoff have to transfer?
answer
- transfer, not a fade-out
- ruled-out ground is the costly loss
- say it out loud, pin it
- hand off before visible degradation
- the old IC has to actually leave
basics
~20 sHand off explicitly, never by drift: brief the incoming IC on impact, timeline, active workstreams and their owners, and pending commitments; state "you are now IC" in the channel; then the outgoing IC shadows briefly and leaves. Fatigued judgment costs more than the context reload.
solid answer
~50 sTreat it as a transfer of command, not a fade-out. The outgoing IC gives a structured brief — current user impact and whether it is improving, what has been tried and explicitly ruled out, every active workstream with its named owner, the next decision points and their timeboxes, and any outstanding commitments such as an update due at the top of the hour. The incoming IC reads it back, and the transfer is stated out loud and in the incident channel: "Sam is now IC." Then the outgoing IC stays available as a plain responder for ten or fifteen minutes and then genuinely leaves — a half-present former commander is worse than none, because the room keeps addressing them. The trade is real: the handoff costs a context reload and risks dropping a thread, but after several hours a tiring IC is exactly the person least able to notice that their own earlier decision was wrong.
go deeper
Know that the Incident Commander role can and should be handed over during a long incident, and that the transfer is announced explicitly rather than allowed to drift.
Be able to list what the brief must carry — impact and trend, ruled-out ground, workstreams with owners, pending decisions, outstanding commitments — and why a written brief beats a spoken one.
Demonstrate the judgment: hand off before degradation shows, weigh a bounded context cost against an unbounded fatigue cost, and enforce that the outgoing commander leaves so command actually moves.
Own the staffing strategy for multi-hour and multi-day incidents — deliberately releasing responders early to guarantee a rested second shift, and making command handoff a drilled routine rather than an improvisation at hour six.
## Why hand off at all The temptation in a long incident is that the person who has been commanding for six hours knows the most, so replacing them looks like a downgrade. That is true about facts and false about judgment. Late in a long incident, the IC is carrying accumulated fatigue and — more dangerously — accumulated commitment to the theory they endorsed three hours ago. Command is precisely the seat where you want someone willing to say "park that, we have spent long enough." The person who authorised the current line is the least likely to be that someone. The decision therefore has a cost on both sides, and an interviewer wants to hear you weigh it: - **Holding on** costs judgment quality, and it costs it invisibly. Nobody announces that their decisions got worse. - **Handing off** costs a context reload, and it genuinely risks dropping a thread — the workstream nobody mentioned in the brief, the vendor ticket someone opened, the promise to update the exec channel at the hour. The cost of the handoff is bounded and can be engineered down with a good brief. The cost of a fatigued commander is unbounded. So you hand off — and you hand off *before* you are visibly degraded, not after. ## What must actually transfer A handoff that consists of "you're up, read the channel" is not a handoff. Five things transfer: 1. **Impact and trend.** Who is affected, how badly, and whether the numbers are getting better or worse right now — not what they were an hour ago. 2. **The timeline, compressed.** What was tried, what changed as a result, and critically what has been *ruled out*. Ruled-out ground is the most expensive thing to lose, because the fresh IC's instinct is to re-run exactly those experiments. 3. **Active workstreams and owners.** Every thread currently in flight, the named person on it, and when they are next expected to report. If a workstream has no owner, it is not a workstream — resolve that during the brief. 4. **Next decision points and timeboxes.** "If the replica has not caught up by 14:20, we fail over" — a pre-committed decision the incoming IC inherits rather than re-litigates from scratch. 5. **Outstanding commitments.** Updates promised, escalations in flight, external parties waiting. These are what silently break across a handoff, and their breakage is what stakeholders notice. A useful discipline is that this brief is *written*, in the incident channel, not only spoken. Writing it forces the outgoing IC to discover what they were holding only in their head, and it gives everyone else the same picture at the same moment. ## Making the transfer unambiguous Command transfers in an instant, not gradually. The emergency-services convention is worth copying verbatim: an explicit "you are now Incident Commander" and an explicit acceptance, then an announcement to the room and a pin in the channel. Ambiguous command is worse than either person holding it, because two people making decisions is the same as none — and it shows up as contradictory instructions to the responder who is actually touching production. The outgoing IC then has one more job: leave properly. Staying ten to fifteen minutes as an ordinary responder to answer factual questions is helpful. Staying for two hours is not, because the room keeps routing decisions to the person it is used to, and the new IC never actually gets command. If the former IC is still the one being asked "should we roll back?", the handoff did not happen. ## The rest of the response also rotates Command is the role people remember to hand off, but a six-hour incident exhausts the Ops Lead, the comms role and the debuggers too. The IC's job includes noticing that: rotating the person who has been staring at logs since hour one, standing down responders who are no longer needed rather than keeping a dozen people on a bridge out of politeness, and — if the incident is going to run into the night — deliberately releasing half the responders so there is a rested second shift at all. Keeping everyone awake for twelve hours guarantees that hour thirteen has nobody fit to command. ## What good looks like in an interview Say explicitly that you hand off before degradation rather than after, describe the five things the brief carries, insist on the verbal transfer and the pinned announcement, and mention the outgoing commander's obligation to actually leave. Then name the trade honestly: you are trading a known, bounded context cost for an unknown, unbounded judgment cost, and that is why the answer is almost always to hand off.
- What is the single item most likely to be dropped in an IC handoff?Outstanding external commitments — the update promised at the top of the hour, the vendor ticket awaiting a reply, the exec expecting a call. Technical state gets briefed because it feels important; obligations to people outside the response live in the outgoing IC's head, and their breakage is exactly what stakeholders notice and remember afterwards.
- How do you stop the room from continuing to treat the outgoing IC as the commander?Make the transfer loud and visible — stated on the bridge, posted and pinned in the channel — and have the outgoing IC redirect explicitly: "ask Sam, she has command." Then have them leave within the quarter hour. If decisions are still being routed to the previous IC an hour later, command never actually moved.
- Is there a case for keeping the same IC through a very long incident?Only briefly and deliberately: if you are minutes from a decisive mitigation, swapping command mid-manoeuvre costs more than it saves. That is a short deferral, not a plan. Once the incident is measured in hours rather than minutes, an IC running on fatigue is a worse risk than any reload of context.
saying these in an interview costs you the question
- The person who has been on longest knows most, so keep them
- Just tell the new IC to scroll back through the channel
- Command can transfer gradually as the new person catches up
- Handoffs are for on-call shifts, not for roles inside one incident
- The old IC should stay in charge informally to help