The pager fires at 2:47am. Within ninety seconds, three engineers are awake and in the incident channel. Someone starts checking dashboards. Someone else begins restarting services. A third person opens the runbook. Nobody has declared an incident commander.
This is the moment most incident response actually fails — not when the system breaks, but in the thirty to ninety seconds after humans arrive and before anyone establishes who is running the room. What follows is a familiar pattern: parallel investigations that don't share findings, remediation attempts that step on each other, and a growing pile of Slack messages that will be nearly impossible to reconstruct in the postmortem. The technical problem might be solvable. The coordination problem is already in progress, and it's making everything worse.
The Vacuum Fills With the Loudest Voice, Not the Right One
When no one claims the incident commander role, the vacuum doesn't stay empty. It fills — usually with whoever types fastest, whoever has the most context about the specific system that's failing, or whoever has the most seniority in the channel. None of these are reliable proxies for good incident command.
The engineer with the most context about the broken service is often exactly the wrong person to run the incident. They're the one who should be heads-down in logs and metrics, not managing communication cadence and stakeholder updates. Pulling them into coordination work is a double loss: you get a worse commander and a distracted investigator.
Seniority is its own trap. Senior engineers often have strong opinions about what's wrong, which creates a gravitational pull toward their hypothesis even when the evidence is ambiguous. Good incident command requires holding hypotheses loosely and keeping multiple investigation threads alive. That's hard to do when you're also the most confident person in the room.
The fastest typist problem is more subtle. In async-first engineering cultures, the person who establishes the initial framing of an incident — the first message that says "looks like a database issue" — often anchors the entire investigation. Confirmation bias does the rest. Teams spend twenty minutes ruling out database problems while the actual cause sits in a config change from six hours earlier.
The Fix Isn't a Process Doc, It's a Reflex
Most teams know they need incident commanders. They have it in their runbooks. They've discussed it in postmortems. And then at 2:47am, nobody claims the role anyway.
The gap between knowing and doing here is a training problem, not a documentation problem. Incident command is a skill that atrophies without practice, and most engineers only encounter real incidents a handful of times per year. That's not enough repetition to build the reflex of immediately claiming or explicitly delegating the commander role before any investigation begins.
Game days and chaos engineering exercises are the obvious answer, but they're often run in ways that undermine this specific goal. If your game day has a designated facilitator who implicitly acts as incident commander, you've practiced the technical response without practicing the coordination bootstrap. The most valuable thing a game day can do is start with nobody in the commander role and see how long it takes for one to emerge — and what happens to the investigation in the meantime.
The other intervention that actually works is explicit role rotation in lower-stakes incidents. Not every production event is a severity-one. Minor degradations, single-service blips, and elevated error rates that resolve quickly are all opportunities to practice the commander pattern under low pressure. If your team treats those as "not worth the overhead," you're leaving the best training reps on the table.
What Good Command Actually Looks Like at 3am
Incident command done well is mostly invisible. The commander isn't the one solving the problem — they're the one making sure the problem-solvers can work without stepping on each other. That means: one person owns external communication so engineers don't have to context-switch to write status updates. Investigation threads are named and assigned so findings get shared rather than siloed. Remediation attempts are coordinated so two engineers don't restart the same service simultaneously and corrupt the signal.
The commander also owns the clock. One of the most consistent failure modes in prolonged incidents is the absence of anyone tracking elapsed time and forcing periodic reassessment. Teams get locked into a hypothesis, spend forty minutes on it, and only step back when someone asks "wait, how long have we been on this?" That question should be asked on a schedule, not when someone finally gets frustrated enough to raise it.
None of this requires a formal incident management platform or a sophisticated escalation policy. It requires one person who has explicitly accepted the responsibility of running the room rather than running the investigation.
The next time your pager fires, the first message in the incident channel shouldn't be a dashboard screenshot or a theory about what's wrong. It should be two words: "I've got command." Everything else follows from that.