The Incident Manager's OS: OODA × RACI × Incident Commander

Speed alone isn’t enough. A fast team without clear roles is just organized noise — tasks duplicating, decisions stalling, everyone looking at everyone else while the incident escalates.

The OODA Loop sets the rhythm. You need two more layers to make it work: role clarity and decision ownership.

Think of this as an operating system for your incident response. Every OS manages three things — process scheduling (tempo), resource allocation (roles), and system calls (decisions) — so applications don’t have to reinvent the wheel. The Incident Manager’s OS does the same for crisis response. It is the shared foundation that handles the three things that break in every major incident:

1. No predictable tempo — some phases drag while others get skipped
2. No clear roles — people guess who does what, or worse, everyone does the same thing
3. No single decider — decisions get deferred, debated, or never made

Without the OS, every incident becomes a unique scramble. The same questions — who gathers data, who decides the path, who calls the vendor — get answered on the fly, differently each time, wasting precious minutes while the incident spreads.

The OS answers them before the crisis hits:

What happens if you miss one. Skip OODA and you will have clear roles but no rhythm — assigned owners working at different speeds on different things. Skip RACI and you get speed but role confusion — the “everyone Observes but nobody Decides” trap. Skip the IC and you have structure but no authority — consensus replaces decision-making, costing minutes the incident uses to spread.

Layer 1: OODA as the Clock

If you’ve been following this series, you know the rhythm already. Observe → Orient → Decide → Act, in roughly 15-minute cycles ¹.

The problem: OODA describes the flow but not the cast. Who gathers which data? Who synthesizes? Who decides? That’s where Layer 2 comes in.

Layer 2: RACI as the Cast

RACI (Responsible, Accountable, Consulted, Informed) defines who does what. The critical insight: each OODA phase has a different RACI assignment. Who leads during Orient is different from who leads during Act.

What this tells you:

• Observe is a team sport — everyone collects data, the IC owns completeness
• Orient and Decide are the IC’s moments — they lead both, the Tech Lead and SMEs validate
• Act is distributed — assigned responders execute, the IC oversees, Comms stays informed

This prevents the “who should call the vendor?” debate. The RACI matrix already answered that before the incident started.

Layer 3: The Incident Commander as the Air Traffic Controller

The IC is the air traffic controller, not a pilot. They don’t troubleshoot, don’t touch dashboards, and don’t handle comms.

The IC role is hard because it asks your best engineer to stop being useful in the technical sense. A senior engineer who jumps into debugging during a crisis has abandoned their actual job: keeping the team cycling faster than the incident.

A Walkthrough: The P1 at 3 AM

Here’s what this OS looks like in practice — a real P1 response with all three layers firing at once.

Your monitoring fires. Payment API error rate hits 40%.

Building the OS

You do not have to roll out all three layers at once. In practice, the build order is the reverse of the theory: you need an Incident Commander first (someone must own the clock), then the rhythm (OODA is useless without someone driving it), then the role map (RACI formalises what the first two layers revealed).

Week 1: Install the IC role. Pick one person per shift. They keep the clock and make decisions. They do not touch consoles.

Week 2: Add the OODA rhythm. Every 15 minutes, the IC asks: “What do we know now that we didn’t know 15 minutes ago?” ² Pin the phase to the war room channel.

Week 3: Formalize with RACI. Build the OODA-by-phase matrix with your actual team. Publish it. Review after every incident.

Common Mistakes

1. IC doubles as Tech Lead — The IC debugging while the incident escalates. Fix: split roles from minute zero.
2. RACI as a static document — Built once, never updated. Fix: review after every major incident.
3. No scribe — Post-mortem relies on “best memory.” Fix: assign a Scribe in the first cycle, every time.
4. Soft IC — Calls for consensus instead of decisions. Fix: a wrong decision executed now beats a perfect decision too late.

The One-Page Card

┌────────────────────────────────────────────────────────────┐
│                 THE INCIDENT MANAGER'S OS                  │
├────────────────────────────────────────────────────────────┤
│                                                            │
│  LAYER 1: OODA                                             │
│  T+0 to T+5   OBSERVE    — Raw data. No analysis.          │
│  T+5 to T+10  ORIENT     — Synthesize. Form hypotheses.    │
│  T+10 to T+15 DECIDE     — IC picks the path.              │
│  T+15 onward  ACT        — Execute. Verify. Repeat.        │
│                                                            │
│  LAYER 2: RACI                                             │
│  OBSERVE  → All R · IC A · SMEs C · — I                    │
│  ORIENT   → IC R+A · TL C · All responders I               │
│  DECIDE   → IC R+A · TL C · All responders, Comms I        │
│  ACT      → Resp. R · IC A · Comms I                       │
│                                                            │
│  LAYER 3: INCIDENT COMMANDER                               │
│  DOES:   Rhythm · Decisions · Shields                      │
│  AVOID:  Consoles · Troubleshooting · Comms                │
│                                                            │
│  RULES: Don't skip Orient · One A per task                 │
│  IC decides · Scribe always · Every 15 min: ask "What do   │
│  we know now that we didn't know 15 minutes ago?"          │
└────────────────────────────────────────────────────────────┘

Key Takeaways

1. Three layers, not one. OODA gives speed. RACI gives clarity. The IC gives ownership. Each needs the other two.
2. RACI changes per OODA phase. Who leads during Orient is different from during Act.
3. The IC does not troubleshoot. The hardest part is convincing your best engineers to stop debugging during a crisis.
4. Build before the crisis. Run tabletop drills so roles are muscle memory by the time a real P1 hits.

Further Reading

• Your Incident Response is Stuck on Observe — The first post in this series: how the OODA Loop transforms incident response from reactive scrambling into structured decision-making
• When a Cyber Crisis Hits, Know Your OODA Loops — IBM X-Force on applying OODA to real incident response
• Incident Commander Training — PagerDuty’s open-source IC guide (the industry standard)
• Managing Incidents — Google SRE Book chapter on incident management best practices
• RACI Chart: What It Is & How to Use It — Atlassian’s practical RACI guide with templates
• The OODA Loop: A Practical Guide — StrategyU’s deep dive into Boyd’s full model, not just the simplified circle

References