The incident fires. A bridge opens. Someone is designated Incident Commander.
They assign roles. They write the status updates. They close the incident. The post-mortem credits their coordination.
In reality, the incident commander is a traffic director standing in the middle of an intersection, waving their arms while the actual work happens in the lanes they cannot see.
⸻
The Role Confusion
Incident command frameworks were borrowed from emergency response. In a wildfire, the incident commander controls resource allocation across multiple agencies with clear chains of authority.
In a software incident, the "resources" are engineers who already know more about the failing system than the commander does. The commander is not allocating expertise. They are managing optics: keeping leadership informed, preventing stakeholder interference, and maintaining the illusion of structured control.
This is valuable work. But calling it "command" creates a fiction. The engineers troubleshooting the database do not need the commander to tell them what to investigate. They need the commander to keep everyone else away while they work.
⸻
The Communication Overhead
The incident commander's primary tool is communication. Status updates every fifteen minutes. Stakeholder escalations. Executive briefings.
Each communication cycle pulls the commander's attention to the audience, not the problem. The commander must translate technical findings into management-safe language, repeatedly, in real time. This translation consumes bandwidth that could be spent coordinating with the engineers who are actually diagnosing the failure.
The commander becomes a communication bottleneck. Information flows through them, slowing down. The engineers know the fix but must wait for the commander to update the bridge before they can proceed. The process designed to accelerate resolution is throttling it.
⸻
The Attribution Error
When the incident is resolved, the post-mortem recognizes the incident commander. They led. They coordinated. They managed the crisis.
The engineer who found the root cause by reading a log file at 3 AM gets a mention. The engineer who wrote the monitor that detected the anomaly six months ago gets nothing.
Over time, this attribution pattern trains engineers to optimize for visibility during incidents rather than preparedness before them. The system creates more incident commanders and fewer engineers who prevent incidents.
⸻
The Right Frame
The incident commander role is logistics, not leadership.
Rename it if necessary. "Incident Communicator." "Stakeholder Liaison." Remove the mythology. The engineers doing the work are the ones commanding the incident. The commander is running interference.
This is not a demotion. It is an honest description of an essential function. And honest descriptions produce better outcomes than heroic fictions.
End.