The "Too Many Cooks" Problem
Imagine a restaurant kitchen during the dinner rush where five different chefs are all shouting conflicting orders, trying to use the same stove, and nobody is talking to the waiters. The result is a disaster: burned food, angry customers, and stressed-out staff. No single person is accountable, so nothing gets resolved efficiently.
Now, imagine your company's main website goes down on Black Friday. If everyone — engineers, managers, executives — jumps into a Slack channel and starts shouting ideas and asking for updates simultaneously, you have the exact same problem. Engineers can't focus. Decisions get made by whoever is loudest. Critical steps get skipped or duplicated. The outage lasts longer than it should.
The Incident Command System (ICS)
To manage the chaos of a major incident, we need a clear structure. The technology industry borrows a proven framework from emergency services — firefighters, paramedics, and disaster response teams — called the Incident Command System (ICS). ICS was developed in the 1970s after a series of catastrophic wildfires in California revealed that poor coordination between agencies was killing people. The same coordination failures that cost lives in wildfires cost revenue, reputation, and customer trust in software systems.
The core idea of ICS is simple: assign clear, distinct roles with defined responsibilities. This ensures that everyone knows who is in charge, who is doing what, and how information flows. It transforms a disorganized mob into a disciplined team with a shared operating picture.
Why Structure Matters Under Pressure
Human cognition degrades under stress. When adrenaline is high and stakes are real, people default to familiar behaviors: they start doing things without coordinating, they ask the same questions repeatedly, and they lose track of what has already been tried. A pre-defined structure offloads the cognitive work of "who should do what" so that mental energy can be spent on "how do we fix this."
Interviewers at companies with mature SRE practices often ask: "Walk me through how your team handles a SEV1 incident." A weak answer describes the technical debugging process. A strong answer describes the organizational response first — who declares the incident, who takes IC, how communication is structured — and then describes the technical process within that structure. Demonstrating awareness of ICS shows operational maturity.