Your Incident Response is Stuck on Observe — Keith Kee KW
Keith Kee KW

Your Incident Response is Stuck on Observe

6 min read
ooda-loop incident-response mental-models decision-making

How I stopped running faster and started cycling smarter

I used to think a good incident response was about speed. Faster alerts. Faster diagnosis. Faster rollbacks. More dashboards. More eyes on the screen.

I was wrong. Speed without shared Orientation isn’t speed — it’s organized chaos.

The framework that changed how I run incident response came from a Korean War fighter pilot.

The OODA Loop: More Than Four Steps in a Circle

John Boyd was a US Air Force colonel who noticed something strange. His F-86 Sabre pilots were consistently beating superior Soviet MiG-15s. The MiG was faster, could turn tighter, and climbed better. On paper, it should have won every engagement.

What the F-86 had was a wider canopy (better visibility) and hydraulic flight controls (faster stick inputs). The pilot could see more, and act on what he saw, faster. Boyd distilled this into the OODA Loop 1:

                  ┌────────────┐
                  │  Observe   │
                  │ (gather    │
                  │  raw data) │
                  └────┬───────┘
                       │
                  ┌────▼─────┐
          ┌───────│  Orient  │◄──────┐
          │       │(synthesis│       │
          │       │ mental   │       │
          │       │  model)  │       │
          │       └────┬─────┘       │
          │            │             │
          │       ┌────▼─────┐       │
          │       │  Decide  │       │
          │       │(select   │       │
          │       │ action)  │       │
          │       └────┬─────┘       │
          │            │             │
          │       ┌────▼─────┐       │
          └───────│   Act    │───────┘
                  │(execute) │
                  └──────────┘
  1. Observe — Gather raw data from the environment. No analysis, no interpretation. Just facts.
  2. Orient — Synthesize observations into a shared mental model. Identify patterns, form hypotheses, classify severity. Boyd called this the most critical phase. 1
  3. Decide — Select a course of action. The Incident Commander makes the call, not the committee.
  4. Act — Execute the decision with visibility, then immediately observe the effects to feed the next cycle.

Boyd’s actual framework — refined over two decades — has a critical detail most people miss: every feedback loop flows through Orientation. Not Observe. Not Decide. Orientation 2.

If your team’s Orientation is wrong, every Decision and Action that follows will be wrong too. And you’ll never know, because you’ll be too busy looking for more data.

OODA vs. PDCA: Why One Fits Incident Response Better

Dimension OODA Loop PDCA Cycle
Commitment style Late commitment (adapt as you go) Early commitment (plan first)
Designed for Competitive, unfolding environments Quality improvement, stable processes
Handling uncertainty Acts with incomplete information Requires data before acting
Center of gravity Orientation (shared mental model) Planning (up-front analysis)
Best fit Incident response, crisis, war rooms Process improvement, manufacturing

The Problem: Most Teams Are Just Observing

Watch any major incident response unfold. The pattern is always the same:

  1. Alert fires
  2. Someone posts: “Is anyone else seeing this?”
  3. Multiple people start gathering data independently
  4. Someone posts: “Payment API is returning 503s”
  5. Someone else: “Database CPU is at 95%”
  6. Someone else: “We had a deployment 20 minutes ago”
  7. Silence
  8. More data gathering
  9. Finally: “Should we roll back?”
  10. Debate. More data gathering.

The team is cycling through Observe → Observe → Observe → Observe.

The incident, meanwhile, is degrading services, spreading impact, and compounding customer damage. It’s cycling through its loop faster than you’re cycling through yours.

You’re losing because no one is doing the hard work of Orientation.

What Shared Orientation Actually Looks Like

Here’s what a structured OODA rhythm looks like in practice:

Cycle 1 (T+0 to T+15):     Cycle 2 (T+15 to T+30):
Observe ─► Orient           Observe ─► Orient
    ▲          │                ▲          │
    │     Decide                │     Decide
    │          │                │          │
    └── Act ───┘                └── Act ───┘
         │                           │
         └────── feeds next ─────────┘

T+0 to T+5 — Observe. Everyone posts raw data to a single channel. No analysis. No “I think.” Just facts: “Payment API 503 since 14:32. Database CPU at 95%. Deployment v2.4.1 pushed at 14:15.”

T+5 to T+10 — Orient. The Incident Commander synthesizes. “Here’s what I’m hearing. Three observations point to database. One points to network. We’re going with the database hypothesis this cycle.” Hypotheses get posted visibly. Debates happen here.

T+10 to T+15 — Decide. The IC makes the call. Not by committee. “Alice: fail over to standby. Bob: monitor success rates. Charlie: post status update.”

T+15 onward — Act + immediate re-Observe. Actions are executed with visibility. Effects are monitored immediately. New observations feed the next cycle.

Every 15 minutes, repeat. Each cycle faster and more informed than the last.

Best Practices for Running the OODA Incident Rhythm

  • Pre-define roles. Incident Commander, Responders, Communicator, Scribe. Everyone knows their OODA phase focus before the alert fires.
  • Pre-build playbooks. Familiar failure patterns (database outage, API degradation, auth failure) let your team use Boyd’s Implicit Guidance and Control — flowing directly from Orient to Act without explicit deliberation 3.
  • Use a shared surface. A single Slack channel, war room board, or incident management tool where observations, hypotheses, decisions, and actions are all visible in real time.
  • Timebox relentlessly. The IC owns the clock. If Orient takes 10 minutes, Decide gets 5. No phase expands beyond its budget.

Where Most Teams Trip Up

I’ve seen the same six pitfalls everywhere I’ve worked:

# Pitfall Symptom Fix
1 The Observe Trap “Let’s wait for more data.” IC enforces the timebox. Boyd’s loop is designed for incomplete information.
2 The Orient War “I think it’s the database.” “No, it’s the network.” Post both hypotheses. Let evidence decide. IC breaks ties.
3 The Decide Vacuum Everyone looks at everyone else. That’s why the IC role exists. Make sure someone owns the call.
4 ACT-and-Forget Actions executed but nobody checks results. Every action must be followed by explicit observation.
5 The Solo OODA One senior person does all four phases alone. Distribute the phases across the team. Hero mode isn’t scalable.
6 Skipping the Post-Mortem Incident resolved, everyone moves on. The post-incident review is how you build better playbooks — closing the loop for next time.

The One-Question Test

Next time you’re in a war room, ask yourself: is your team cycling through OODA, or just Observing really fast?

If everyone is gathering data and nobody is synthesizing — if the IC hasn’t declared a hypothesis, if decisions are deferred for “more information” — you’re stuck in the Observe trap.

The fix isn’t faster alerts or more dashboards. It’s a structured rhythm. A shared Orientation. An IC who owns the clock and makes the call.

Because you can’t get inside the incident’s loop if your team doesn’t even know where it’s going.

Key Takeaways

  1. Orientation is everything. Speed without shared understanding is noise. Invest the first 10 minutes in building a shared mental model.
  2. Enforce the rhythm. Timebox each OODA phase. T+5 Observe, T+10 Orient, T+15 Decide. No phase overruns.
  3. Distribute the loop. The IC Orients and Decides. Responders Observe and Act. No one person does all four phases.
  4. Build playbooks for speed. Known patterns let your team flow from Orient to Act directly — Boyd’s Implicit Guidance and Control.
  5. Review every incident. The post-mortem feeds better Orientation for the next one.

Further Reading

If you enjoyed this, you might also like:

  • The OODA Loop — Full deep dive into Boyd’s original model and its applications across military, business, and cybersecurity
  • Mental Models for Engineering Leaders — A toolkit of thinking frameworks for technical decision-making
  • Second-Level Thinking — Why the best decisions trace the chain of consequences, not just the first effect

References

  1. Boyd, John R. (1995). The Essence of Winning and Losing. Five-slide briefing containing Boyd’s only published diagram of the OODA Loop. ↩︎ ↩︎

  2. Boyd, John R. (1976). Destruction and Creation. U.S. Army Command and General Staff College. Core epistemological argument underpinning the OODA framework. ↩︎

  3. Richards, Chet (2004). Certain to Win: The Strategy of John Boyd Applied to Business. Explores Implicit Guidance and Control as a mechanism for accelerating decision cycles. ↩︎