🚨 No Incident Commander: How Coordination Chaos Inflates MTTR

Overview

Coordination chaos is the anti-pattern where a major incident pulls a crowd onto the bridge but no one is in charge — so the incident is worked by a leaderless committee. It attacks a phase of MTTR that dashboards never show: the organizing overhead between “many people are here” and “everyone knows what they are doing.” On a large incident this overhead can dwarf the actual technical fix.

The counterintuitive truth is that adding responders to an uncoordinated incident often makes it slower, not faster. Past three or four people, the failure mode flips from “not enough hands” to “too many uncoordinated hands.” Several engineers independently form the same hypothesis and debug it in parallel, duplicating work. No one owns stakeholder communication, so the actual responders get interrupted every two minutes by “any update?” No one writes anything down, so each new joiner restarts the investigation from zero. The room is loud and busy and moving nowhere.

An incident commander is the cheap fix. The IC does not need to be the best engineer or know the root cause — their entire job is to impose structure: assign roles, keep one owner per workstream, set a communication cadence, and hold the tempo. Without that role, MTTR inflates on pure coordination waste.

Symptoms

• Duplicate work. Two or more engineers are investigating the same hypothesis or running the same queries without knowing it.
• The bridge is a crowd, not a team. Many people are present, several are passive spectators, and there is no clear owner for any workstream.
• Constant interruptions for status. Responders are pulled off the problem repeatedly to answer “what’s the update?” from stakeholders because no one owns comms.
• No running timeline. When someone joins late, the answer to “what have we tried?” is a scramble through scrollback or “let me catch you up” — repeated for every joiner.
• Decisions stall or get relitigated. With no one empowered to decide, the team debates the same choice repeatedly and no action gets taken.
• Unowned critical areas. Everyone assumed someone else was watching the database, the status page, or the customer impact — and no one was.

Common Root Causes

• No defined IC role. The organization has no incident-command model, so major incidents default to leaderless.
• The most senior engineer becomes hands-on-keyboard. The person who should be commanding is instead deep in a terminal, so no one is steering.
• No role definitions at all. Commander, comms lead, scribe, and ops leads are undefined, so responders improvise or do nothing.
• “All hands” reflex. Severity is high, so everyone piles in, but no one right-sizes the room or releases people without a job.
• Comms treated as an afterthought. Stakeholder updates are nobody’s assigned duty, so they land on whoever is deepest in the fix.
• No scribe norm. Documenting the timeline is seen as overhead during the incident rather than the thing that keeps handoffs and the post-mortem cheap.

Diagnostic Workflow

Find coordination chaos in your incident history, then close the gaps.

1. Reconstruct the role timeline. For a recent major incident, ask when an IC was named — if ever. A late or absent IC assignment is the primary signal.

2. Count duplicated effort. Review the timeline or chat log for moments where two people worked the same hypothesis in parallel. Duplication is a direct symptom of unowned workstreams.

3. Measure comms interruptions. Count how often responders were pulled off the technical problem to give status. High counts mean no one owned communications.

4. Check for a timeline artifact. Did a scribe maintain a running record? If the post-mortem had to be reconstructed from memory and scrollback, no one owned the timeline.

5. Audit room size versus active roles. Compare how many people were on the bridge to how many had a defined job. A large gap is passive-spectator overhead.

6. Look for decision latency. Identify decisions that were debated repeatedly without resolution. Relitigated decisions indicate no one was empowered to make the call.

Example Root Cause Analysis

A region-wide latency incident pulled fourteen engineers onto a call. For the first thirty-five minutes there was no incident commander. Three separate people independently suspected the load balancer and each opened its config, unaware of the others. The VP kept joining to ask for updates, and each time the two engineers closest to the problem stopped to explain. No one was updating the status page, so support was flying blind. When a network engineer joined at minute twenty, four different people spent six minutes catching her up because there was no written timeline.

The MTTR autopsy found the actual technical fix — shifting traffic away from a degraded availability zone — took under four minutes once someone owned the decision. But it took thirty-nine minutes to get there, almost all of it coordination waste: duplicated load-balancer investigation, repeated status interruptions, and re-briefing every joiner.

Root cause of the long MTTR was not the degraded zone. It was the absence of an incident commander: no one assigned roles, so workstreams overlapped, comms went unowned, and the timeline lived only in people’s heads. The fix was organizational — a formal IC role that must be claimed within the first minutes of any major incident, a standing set of roles (IC, comms lead, scribe, ops leads), and a norm that the IC stays hands-off-keyboard to keep steering. The next comparable incident resolved in eleven minutes.

Prevention Best Practices

• Define and require an incident commander. For any major incident, someone must claim IC in the first minutes. Make it explicit and non-optional.
• Keep the IC off the keyboard. The commander coordinates and decides; they do not also debug. Separating these roles is the single highest-leverage move.
• Pre-define the role set. Incident Commander, Communications Lead, Scribe, and one Operations lead per workstream — documented so responders assign them by reflex.
• Own communications separately. A dedicated comms lead shields responders from status requests and keeps stakeholders and the status page current.
• Always keep a scribe. A running timeline makes joiner hand-offs cheap and the post-mortem free, instead of a memory-reconstruction exercise.
• Right-size the room. Give everyone present a role or release them. A small focused team resolves faster than a large passive one.
• One owner per workstream. Ensure each active area has exactly one owner and no critical area is unowned.

Quick Reference

Signal	Well-commanded	Coordination chaos
Incident commander	named early, hands-off keyboard	absent or also debugging
Workstream ownership	one owner each	overlapping or unowned
Stakeholder comms	dedicated comms lead	interrupts the responders
Timeline	maintained by a scribe	lives in people’s heads
Room composition	everyone has a role	passive spectators
Decisions	IC decides, team executes	debated and relitigated

Conclusion

On a major incident, coordination is not overhead you tolerate — it is often the largest single component of MTTR, and it is the cheapest to fix. A leaderless bridge burns minutes on duplicated work, status interruptions, and re-briefing every joiner, all while the actual technical fix waits on a decision no one is empowered to make. Name an incident commander early, keep them off the keyboard, pre-define the role set, and always keep a scribe. Turning a crowd into a coordinated team is usually worth more minutes of MTTR than any diagnostic tool. For a prompt that assigns war-room roles from whoever is actually present, see the Reduce MTTR category.