Imagine a city block is on fire. Three fire departments arrive simultaneously — each with trucks, hoses, and trained crews. But one department calls the hydrant a "standpipe," another calls it a "water post," and the third is on a completely different radio frequency. Nobody knows who is in charge. Crews step on each other's hoses. The building burns down not because of a lack of firefighters, but because of a lack of coordination. This is exactly what happened in California in the early 1970s, and it is exactly what happens during major software outages today.
The Origin of ICS
In 1970, a series of catastrophic wildfires swept through Southern California. Post-incident analysis revealed a devastating finding: the fires were not lost due to insufficient resources. They were lost due to coordination failure. Fire agencies from different counties arrived on scene unable to communicate — they used different radio frequencies, different terminology for the same equipment, and had no agreed-upon chain of command. When two chiefs gave conflicting orders, crews froze.
To fix this, the US government developed the Incident Command System (ICS) — a standardized, scalable management framework for emergency response. ICS was later formalized into the broader National Incident Management System (NIMS), which mandates ICS as the standard for all US emergency response agencies, from local fire departments to FEMA itself.
The core insight of ICS is that coordination problems are universal and predictable. Whether you are managing a wildfire, a hurricane evacuation, or a distributed database outage, the same failure modes appear: confusion over authority, communication overload, and resource mismanagement. ICS provides a pre-built organizational skeleton that any group of people — even strangers — can step into and immediately function within.
Translating NIMS to Tech
Google, Amazon, Netflix, and PagerDuty did not invent their incident management frameworks from scratch. They adapted ICS. The terminology shifts slightly — "Incident Commander" stays the same, "Public Information Officer" becomes "Comms Lead," "Logistics Section" becomes "Tooling and Access" — but the underlying structure is identical.
The reason ICS transfers so cleanly to software incidents is that the problems are structurally identical:
- A wildfire crosses three county lines simultaneously → A service outage spans three microservice teams simultaneously.
- A fire chief cannot reach the water supply coordinator → An IC cannot reach the database team because they are all in different Slack channels.
- Two agencies give conflicting evacuation orders → Two on-call engineers apply conflicting configuration changes and make the outage worse.
By adopting ICS, engineering organizations gain a pre-negotiated coordination protocol. When an incident starts, nobody debates who is in charge or who talks to customers. The structure already exists. People fill roles, not vacuums.
Interviewers at companies with mature SRE practices (Google, Cloudflare, Stripe) frequently ask: "Walk me through how your team handles a major incident." A weak answer describes chaos. A strong answer describes a structured process with named roles. Referencing ICS by name — and explaining why it works — signals that you understand incident management as a discipline, not just a fire drill.