OODA Loop

Overview

The OODA Loop (Observe, Orient, Decide, Act), developed by military strategist Colonel John Boyd, is a framework for rapid decision-making in dynamic, competitive, or time-sensitive situations. The key insight: speed through the loop creates advantage. In competitive scenarios, operating faster than your opponent disrupts their decision-making.

Core Principle: Agility beats perfection. Cycle through OODA faster than the situation changes (or faster than your opponent).

When to Use

Incident response and outages
Competitive market situations
Time-sensitive decisions
Rapidly changing requirements
Crisis management
Debugging under pressure
Any situation requiring quick adaptation

Decision flow:

Situation changing rapidly? → yes → Need quick decisions? → yes → APPLY OODA LOOP
                                                         ↘ no → Standard analysis
                          ↘ no → Deliberate analysis may be better

The Four Phases

1. OBSERVE

Gather information rapidly

What to observe:

Current state of the system/situation
Changes since last observation
External factors and environment
Feedback from previous actions
Competitor/opponent movements

Incident Example:
- Error rates: Spiking 10x normal
- Affected services: API gateway, user service
- Timeline: Started 5 minutes ago
- Recent changes: Deploy 15 min ago
- User reports: "Can't log in"

Observation principles:

Cast wide net initially, narrow as pattern emerges
Don't filter prematurely—gather raw data
Include lagging AND leading indicators
Time-bound: Don't observe forever

2. ORIENT

Make sense of observations

Orientation factors (Boyd's framework):

Cultural traditions: How does our org typically respond?
Genetic heritage: Our built-in biases and tendencies
Previous experience: What have we seen before?
New information: What's different this time?
Analysis/Synthesis: Combining all of the above

Incident Example:
- Pattern matches: Similar to DB connection pool exhaustion last month
- But different: No DB metrics anomaly this time
- Recent deploy touched: Auth service rate limiting
- Hypothesis: Rate limit config too aggressive

Orient is the CRITICAL phase:

This is where mental models apply
Misorientation leads to wrong decisions
Update orientation as new info arrives
Challenge your initial framing

3. DECIDE

Select course of action

Decision characteristics:

Based on current orientation
Acknowledges uncertainty
Identifies what to observe next
Has implicit/explicit hypothesis

Incident Example:
Decision: Roll back auth service deploy
Hypothesis: This will restore normal error rates
Observation plan: Watch error rates for 2 minutes post-rollback
Fallback: If no improvement, investigate DB connections

Decision speed vs. quality tradeoff:

70% confidence now beats 90% confidence too late
Reversible decisions: Bias toward action
Irreversible decisions: Gather more info first
"Good enough" decision executed fast > perfect decision too slow

4. ACT

Execute the decision

Action principles:

Execute decisively
Immediately return to OBSERVE
Don't wait for complete results
Create new observations through action

Incident Example:
Action: kubectl rollback deployment/auth-service
Immediate observe: Error rates, response times
Time limit: 2 minutes to see effect

The loop restarts:

Actions create new situation
New situation requires new observation
Cycle continues until stable state

OODA Loop Speed

Tempo Advantage

Operating inside opponent's loop:

You:     O → O → D → A → O → O → D → A → O ...
Opponent:     O → O → O →  ...  → D → A (too late)

When you complete loops faster:

Your actions change situation before they decide
Their orientation becomes outdated
They react to old information
You maintain initiative

Speed Multipliers

Factor	Effect
Pre-planned responses	Skip D phase for known scenarios
Distributed authority	Parallel loops at different levels
Clear mental models	Faster O (orientation)
Training/practice	Faster execution (A)
Good observability	Faster O (observation)

Speed Killers

Factor	Effect
Waiting for certainty	Loop stalls at O or D
Hierarchical approval	Adds latency to D
Information overload	O phase never completes
Analysis paralysis	Loop stalls at Orient
Perfect solution seeking	D phase never completes

Application Patterns

Incident Response

OBSERVE: Metrics, logs, alerts, user reports
ORIENT:  Match pattern, form hypothesis, assess blast radius
DECIDE:  Mitigation action (rollback, scale, disable)
ACT:     Execute mitigation, immediately observe results
LOOP:    Continue until stable

Competitive Response

OBSERVE: Competitor announcement, market reaction, customer feedback
ORIENT:  Assess threat level, identify our advantages, gaps
DECIDE:  Response strategy (match, differentiate, ignore)
ACT:     Execute response, observe market reaction
LOOP:    Adjust based on effectiveness

Debugging Under Pressure

OBSERVE: Error messages, stack traces, recent changes
ORIENT:  Form hypothesis about cause
DECIDE:  Test most likely hypothesis first
ACT:     Add logging, try fix, or eliminate possibility
LOOP:    Update hypothesis based on results

OODA for Teams

Parallel Loops

Different team members can run loops simultaneously:

SRE:     Infrastructure OODA (scaling, failover)
Dev:     Code OODA (debugging, fixes)
Support: Communication OODA (users, stakeholders)
Lead:    Strategy OODA (coordination, escalation)

Shared Orientation

Teams need synchronized mental models:

Runbooks create shared orientation
Incident channels share observations
Clear roles enable parallel action
Post-incident updates orientation for next time

Verification Checklist

Observing actual current state, not assumptions
Orientation considers multiple hypotheses
Decision is actionable and time-bound
Action creates observable feedback
Loop is actually cycling (not stuck in one phase)
Speed is appropriate to situation urgency

Common Failure Modes

Failure	Symptom	Fix
Observation overload	Can't process all data	Filter to key indicators
Orientation lock	Stuck on one hypothesis	Force alternative framing
Decision paralysis	Waiting for certainty	Set decision deadline
Action without observation	Blind execution	Mandate observe after act
Single loop	Not cycling	Time-box each phase

Key Questions

"What do I observe RIGHT NOW?" (not 5 minutes ago)
"What does this mean? What pattern does it match?"
"What's my best action given current understanding?"
"How will I know if my action worked?"
"Am I cycling fast enough?"

Boyd's Insight

"He who can handle the quickest rate of change survives."

The goal isn't just making decisions—it's making decisions faster than the situation evolves, faster than competitors adapt, faster than problems compound. Speed creates options; delay eliminates them.

thinking-ooda

NPX Install

Tags

SKILL.md Content