← Blog · Incident Management · July 28, 2026 · 9 min read · By Operate Technical Editorial Team

Span of Control Is Five to Seven: What Fire Command Doctrine Actually Says About Running Software Incidents

Software took the incident commander title from fire service ICS and dropped the doctrine. What actually transfers - span of control, transfer of command - and what doesn't.

Span of Control Is Five to Seven: What Fire Command Doctrine Actually Says About Running Software Incidents

Span of Control Is Five to Seven: What Fire Command Doctrine Actually Says About Running Software Incidents

TL;DR: An incident commander (IC) is the single person responsible for all aspects of an incident response, including quickly establishing objectives, managing resources, and strategy. While software teams have adopted the IC title from the Fire Service's Incident Command System (ICS), they often ignore the underlying doctrine—specifically the "span of control" limit of five to seven people—resulting in bloated, inefficient response calls.

Software engineering has a long history of borrowing metaphors from high-stakes physical industries. We look to aviation for checklists and manufacturing for "lean" workflows. Perhaps the most visible loaner is the role of the incident commander. When a production system fails, someone "takes the conn," directing traffic and making the final call on mitigation.

However, borrowing a title is not the same as adopting a system. In the fire service and disaster response, the incident commander is part of a rigid, tested framework called the Incident Command System (ICS). In software, we’ve kept the name but often discarded the discipline. The result is "incident command" in name only: twenty-person Zoom calls where everyone is talking, no one is leading, and the person with the "IC" title is actually just the most senior engineer grepping logs.

To run more effective incidents, we must look at what the original doctrine actually says about how humans handle high-pressure environments.

Where the Title Came From: ICS in One Page

The Incident Command System (ICS) was developed in the 1970s following a series of catastrophic wildfires in California. The problem wasn't a lack of resources or brave firefighters; it was a breakdown in "command and control." Multiple agencies arrived at the same fire with different communication protocols, overlapping authorities, and no unified leadership.

According to the National Wildfire Coordinating Group (NWCG), the incident commander is defined as:

"The individual responsible for all incident activities, including the development of strategies and tactics and the ordering and the release of resources. The IC has overall authority and responsibility for conducting incident operations and is responsible for the management of all incident operations at the incident site."

In the FEMA/NWCG model, the incident command structure is modular. It scales from a single-engine response to a multi-state disaster. But the core principle remains: the IC is not a "doer." They are a manager of the problem. They do not hold the nozzle; they hold the map.

What Software Kept: The Name. What it Dropped: The System

Most SRE organizations have a document defining the incident commander role. Usually, it lists responsibilities like "sending status updates" and "deciding when to rollback." This is a sanitized, corporate version of the role.

What we dropped was the "System" part of the Incident Command System. In a fireground environment, the IC operates within a strict hierarchy with clear communication paths. In software, we often default to a "flat" structure during a crisis. We mistakenly believe that more eyes on the problem lead to a faster resolution. In reality, without the underlying ICS doctrine, more people simply create more noise, higher cognitive load for the IC, and slower decision-making.

Key Takeaway: Adopt the doctrine, not just the title: cap direct reports at 5-7, run formal command transfers, size up before acting, and recognize that in software the commander's scarcest resource is verified diagnosis.

Doctrine Worth Stealing

If we want to reduce our Mean Time to Resolution (MTTR), we should look at the specific parts of the fire service doctrine that are built for human psychology under stress.

Span of Control: 5 to 7

This is the most violated rule in software incident response. In ICS, the rule is strict: no supervisor should have more than five to seven direct reports. Optimally, it is five.

When you have a "bridge" or a Slack channel with 25 people all chiming in, the incident commander is overwhelmed. They are trying to process 25 streams of data simultaneously. According to FEMA, if the span of control is exceeded, the IC must delegate.

In software, this means if you have more than five people involved, you should break into "branches."

The IC talks only to the "leads" of those branches. This preserves the IC’s "working memory" for the big picture.

Transfer of Command: The Briefing Protocol

In the fire service, the arrival of a more senior officer does not automatically mean they take over. There is a formal "Transfer of Command" process.

Software incidents often suffer from "Executive Swooping." A VP joins the call and starts asking questions that were answered 30 minutes ago. In a true incident command structure, the IC remains the IC until a formal briefing occurs and a handoff is announced to the group. The protocol should include:

  1. Current situation (The "Size-up")
  2. Actions taken and their results
  3. Current objectives
  4. Resources assigned

Size-up Before Strategy

A common failure in software is "Action Bias." An engineer sees an error and immediately tries to fix it. In ICS, the IC performs a "Size-up" before any tactics are deployed.

By forcing a Size-up, the IC prevents the team from chasing "ghosts" or applying fixes that have nothing to do with the root cause.

After-Action Review (AAR) as Standard Work

In the fire service, an AAR isn't a "blameless post-mortem" scheduled for next Thursday. It often happens immediately after the incident is stabilized, while the "ground truth" is still fresh. This discipline ensures that the incident command system roles and responsibilities are evaluated: Did the IC maintain the span of control? Were the communications clear?

What Does Not Transfer

While the structure of ICS is brilliant, the domains of firefighting and software engineering have one massive asymmetry: Visibility.

Logistics-Constrained vs. Diagnosis-Constrained

A fireground incident is usually logistics-constrained. You can see the fire. You know where it is and where it is going. The IC's job is to manage scarce resources—engines, water, and personnel—to the right spots.

A software incident is diagnosis-constrained. The system is "invisible." The "fire" is a series of abstract signals in a dashboard. You likely have infinite "resources" (you can spin up a thousand containers), but you don't know where to put them.

Scarcity of Verified Evidence

On a fireground, a captain radios in: "The roof is sagging." That is a verified physical fact. In software, an engineer might say, "I think it’s the database." That is a hypothesis, not a fact.

The incident commander in software faces a unique bottleneck: verified evidence. Their job is less about moving people around and more about filtering out noise to find the one piece of evidence that confirms the root cause.

A Software-Adapted Command Checklist

To transition from a "title" to a "system," your ICs should follow a repeatable cadence.

The First Five Minutes

  1. Declare Command: "I am the Incident Commander. [Name] is the Comms Lead."
  2. Initial Size-up: Write a one-sentence summary of the impact.
  3. Establish the "Bridge": Limit the voice channel/Slack to direct responders only.

Per-Period Cadence (Every 15-20 Minutes)

  1. The Pulse: Request a status update from each branch lead.
  2. The Goal: Set a 15-minute objective (e.g., "Confirm if the last deploy is the cause").
  3. The Update: Send an internal/external status page update.

Closure Criteria

FAQ: Incident Command Roles and Responsibilities

Who becomes the Incident Commander?

According to Atlassian, the IC should be someone trained in the process, not necessarily the most senior engineer. In fact, having your "subject matter expert" (SME) act as the IC is a mistake—you want your SME's hands on the keyboard, not managing the clock.

What are the 5 C's of incident command?

The 5 C's often cited in emergency management are:

  1. Command: Clear authority.
  2. Control: Managing the scope of work.
  3. Communications: Timely, accurate information flow.
  4. Coordination: Ensuring teams don't work at cross-purposes.
  5. Capability: Ensuring the right people are in the right roles.

What is the difference between an IC and a Technical Lead?

The IC manages the incident process and makes the final decision on strategy (e.g., "We are rolling back"). The Technical Lead (or SME) manages the diagnostics. The IC asks "What is the status?"; the Tech Lead answers "We are checking the load balancer."

What is a 200-level Incident Commander?

In the FEMA ICS training hierarchy, ICS-200 is "Basic Incident Command for Initial Response." It focuses on the management of small-to-medium incidents. In software terms, this is an engineer capable of running a "standard" P1/P0 incident before it escalates into a multi-day company-wide crisis (which would be 300 or 400 level).

Why This Matters Now

The move toward Incident Command System roles in software isn't just about being "orderly." It's a response to the increasing complexity of distributed systems. As systems become more opaque, the human element—how we communicate and make decisions—becomes the primary driver of MTTR.

A common pitfall is assuming that the IC can "do it all." As Uday on X recently noted, the reality of 3 AM debugging is often a lonely struggle against fragmented logs and stale dashboards. When we fail to provide our ICs with structured data, we force them to break the "Span of Control" rule just to gather basic information.

Sources & Further Reading

Moving Toward Evidence-Based Command

The primary reason ICS works in the physical world is that the commander receives structured, verified situation reports instead of raw noise. They aren't staring at every flickering light; they are listening to filtered, summarized intelligence from the front lines.

This is where the software version of ICS often breaks down. Our "front line" is a mountain of telemetry that takes a human twenty minutes to parse. This forces the IC to dive into the logs, abandoning their post to become a "doer."

Operate was built to play that reporting role for the whole stack. By acting as a self-hosted AI SRE, Operate watches production and performs the initial "Size-up" that doctrine demands. It provides the incident commander with context, root-cause analysis, and independent verification—delivering evidence-backed diagnosis directly to the human running the call.

The human keeps command, making the strategic decisions, while Operate handles the "invisible" work of gathering evidence. Because it has no write access and proposes only a patch file or PR, it maintains the integrity of the command structure while ensuring the IC’s scarcest resource—truth—is never in short supply.

Ready to scale your incident response with evidence-based diagnosis? Learn how Operate provides context-aware SRE support for your engineering team.

#incident management#SRE#incident commander#ICS doctrine#devops best practices