I watched Mission: Impossible — The Final Reckoning recently, and somewhere in the third act I stopped watching it as a film and started reading it as an incident review.
The shape is familiar. The protagonist is cut off from his own government. Nobody with authority knows where he is, what he’s found, or what he’s about to try. He fixes it alone, with the counter somewhere in the low single digits, and comes back to applause from the people he never called.
Great cinema. Also, almost beat for beat, the worst incident response I’ve ever sat through.
The movie needs the silence
This isn’t a criticism of the film. The isolation is the plot. Tension needs an information gap, and the cheapest way to manufacture one is to put your hero somewhere nobody can reach him. If Ethan Hunt filed a structured status update every twenty minutes, the film would be ninety minutes of a competent interagency working group closing a risk item, and nobody buys a ticket for that.
Every element that makes the story work is an element that makes the response worse. He withholds context, so the audience stays uncertain. He refuses support, so the odds stay long. He resolves at the last possible second, so the relief lands hard. Uncertainty, no support, and a resolution time that touches the limit. Read that list again as an incident timeline instead of a plot summary.
Going dark is unfunded work
The version I see in real life is quieter and better-intentioned. An engineer picks up the page, goes heads-down, and decides that talking to anyone right now is a distraction from fixing it. They’ll tell people once they have something worth saying.
They almost never do, because the things that unblock an incident do not arrive by telepathy. They arrive because somebody asked.
The read access to the system you don’t own. The DBA who has seen this exact lock pattern before. The vendor support ticket that has to be raised at severity 1 by an account contact, not by you. Permission to fail over to the secondary region. The decision to shed a feature to protect the write path. None of that is in your terminal. All of it is one message away, and the message never gets sent, because sending it feels like an interruption to the work — when it is the work.
Meanwhile the silence is doing something worse than nothing. Stakeholders do not experience an absence of updates as calm. They experience it as an unbounded problem. So they start their own investigation. They open a second bridge. They ask three different engineers the same question. They ping the one person who could actually fix it, every four minutes, for reassurance. Going quiet to avoid interruptions is the single most reliable way to generate them.
The clock doesn’t care that you were busy
Here’s where the movie logic really falls apart.
A film’s timer stops when the hero succeeds, and everything before that moment is narrative. An error budget doesn’t work that way. It burns in wall-clock minutes. It does not distinguish between the minutes you spent typing and the minutes you spent waiting for access you hadn’t asked for yet. Twenty-five minutes of heroic solo debugging and twenty-five minutes of nobody being paged look identical on the burn chart, and identical on the invoice if there are service credits attached.
The same is true of the SLA, and this is the part teams consistently miss: a lot of contracts don’t only commit you to a restoration time. They commit you to acknowledgement and update intervals. Which means the silence isn’t merely slowing the fix. In some contracts it is, all by itself, the breach. You can resolve inside the restoration window and still owe a credit because nobody updated the status page for ninety minutes.
And then there are the calls that were never yours. Accept data loss or extend the outage. Roll back the release the CEO announced this morning. Turn off the payment path in one region. An engineer who doesn’t escalate doesn’t avoid those decisions. They make them silently, alone, at 3am, on behalf of people who would have answered in ninety seconds and who now find out in the postmortem.
The last-second save is the worst outcome that still counts as a win
The genuinely dangerous thing about the movie ending is that it works. The world gets saved. Everybody claps.
In an incident, a recovery like that is the outcome I’d least like to see, and I’d rank it below a slower fix with clean comms. It teaches the wrong lesson to everyone watching. It tells the responder that going dark was vindicated. It tells the organisation that its escalation path is optional decoration. And it quietly converts one person’s availability into a load-bearing dependency — a single point of failure with a payroll number, who will eventually be on a flight, or asleep, or exhausted from the last three of these.
If the recovery deserved applause, the process failed. Applause is the tell.
The boring version
The fix isn’t more communication. It’s scheduled communication, which is a different thing and much easier to sustain.
- Split the roles immediately. Whoever is holding the keyboard is not the person holding the bridge. This holds at two people, not just at twenty. If you’re one of two, one of you debugs and one of you talks; you’ll finish faster than both of you debugging.
- Update on a timer, not on progress. Every fifteen or thirty minutes, whether or not anything happened. “No change since the last update, still isolating, next update at 14:40” is a complete and useful update. Waiting until you have news is how ninety minutes disappear.
- Write it in impact, not in cause. Stakeholders need what’s broken for customers, since when, what you’re doing about it, and when they’ll next hear from you. They do not need the stack trace. The engineer who leads with the stack trace gets asked to explain it, which costs more time than the update saved.
- Ask for the specific thing. Not “we may need help.” Name the access, the person, the decision, and the time it costs to wait. “I need someone with prod DB write access on this call in ten minutes, or we’re looking at another hour” gets a response. “Investigating” does not.
- Make escalation cheap. If paging a stakeholder is treated as an admission that you couldn’t handle it, nobody will do it until it’s far too late. The norm has to be that early escalation is good practice, and that standing people down five minutes later is a completely normal outcome.
- Rehearse the comms path, not just the failover. I’ve written before that a rollback you haven’t run isn’t a rollback. Same rule applies here. If your game day exercises the technical recovery but never the update cadence or the escalation tree, you’ve tested half the response, and it’s the easier half.
Where the other failure mode lives
I should be fair to the instinct, because there is a real thing being avoided.
The opposite failure is genuinely bad: a forty-person bridge where the one engineer who understands the system spends the incident narrating it, answering the same question from four VPs, and re-explaining the hypothesis every time someone new joins. That’s not communication. That’s a live-streamed debugging session with an audience that can’t help, and I understand exactly why an engineer who has been through one goes dark the next time.
But the answer to that isn’t silence, it’s structure. That’s what the role split is for. One person absorbs the audience, filters the questions, and converts them into either “not now” or “actually, that’s a good lead.” The responder gets to work with the organisation’s resources behind them instead of choosing between focus and support. Done properly, comms is not a tax on the response. It’s how the response gets funded.
Ethan Hunt gets a countdown with a red display and a soundtrack. You get an error budget, which is the same object with worse cinematography and a monthly invoice attached. The difference is that his clock stops when he wins, and yours has been running since the first customer noticed — including through every minute you spent not asking for help.