A dynamic situation exists with time pressure, incomplete information, and a need for action, where OODA is stronger than structured decision methods.
OODA Loop
Prerequisite
What needs to be finished first
Preparation
What needs to be ready before start
Situation board with four quadrants (Observe, Orient, Decide, Act); access to data sources (dashboards, logs, status channel); timer for loop timeboxing; shared document for decision log; communication channel with all participants.
One lead who runs the loop and makes decisions; one observer with data access who continuously feeds information; two to four additional contributors bringing options and risks; one scribe documenting every loop.
Current status of the situation in two to three sentences; available data sources; decision authority of the lead; known constraints (time window, resources, external dependencies); escalation path when thresholds are crossed.
5-30 min per loop, multiple loops in sequence
Make the four quadrants visible as working space. Feed first observations. Set loop timer to 5-10 min. Rule: after every Act return to Observe; do not remain in one loop. Keep the decision log as a running document with a timestamp per loop.
Core question
The one question this method answers
Which observation, orientation, decision, and action is one step ahead in the current loop, and which follow-up loop comes next?
Flow
Marker: Minute
| Step | Duration | Action | Hint |
|---|---|---|---|
10-2 min Observe | 2 min | Capture current situation: data, signals, actor behavior, own position. Record observations without interpretation in the Observe quadrant. | If Observe already contains conclusions ("the competitor will acquire them"), this belongs in Orient. Keep the separation clean, otherwise bias contaminates the data. |
22-4 min Orient | 2 min | Interpret: what the observations mean against experience, models, and hypotheses. Make options visible and test mental models. | Orient is the most important phase and is often underutilized. Place at least two interpretations of the situation side by side before deciding. |
34-5 min Decide | 1 min | Choose one option. The lead decides, while others contribute risks and alternatives. Document the decision with rationale in the log. | If nobody can decide, OODA stalls. The lead must decide, even under uncertainty. "We wait" is a valid decision but it must be made explicitly. |
45-10 min Act | 5 min | Execute the chosen action. Make the effect observable (telemetry, status update, customer feedback). Prepare for the next loop. | If Act takes longer than 5 min, the action is too large for the loop. Choose a smaller action or reduce loop frequency, but not both. |
510+ min Restart | continuous | After every Act immediately return to Observe. The situation has changed through your action and external movement. A new loop starts. | The longer the team analyzes after Act, the more speed advantage is lost. Loop discipline is core to the method, not speed for its own sake. |
Artifact
What comes out at the end
Decision log with timestamp per loop, including observations, orientation, decision, action, and observed effect. One log per situation with lead and date, archived for lessons learned.
One new log per situation, loops numbered chronologically. In retrospective review the log is used as source. Attach corrections or clarifications at the end, do not overwrite.
- Markdown file in the repo under docs/decisions/ooda-<date>.md
- Confluence page with a table per loop
- Linear- or Jira issue with loop updates in the comment stream
- Slack channel with pinned thread, exported later
ooda-loop-working-template.md
Compact working template for OODA Loop with context, input, output artifacts, and next step.
OODA Loop Working Template
Goal
Iterative decision cycle from Observe, Orient, Decide, and Act for dynamic situations.
Context
When and for what do we use this method?
Input
Which data, observations, decisions, or materials are available?
Execution
Short notes along the runsheet.
Output artifacts
- Situation Assessment:
- Decision Loop:
- Action Updates:
Assumptions and open questions
- ...
Decision / Next step
Owner, date, and success signal.
Example output
Concrete filled scenario, fictional example
ooda-loop-beispiel.md
Concrete filled scenario, fictional example
OODA — Production-Incident DB Failover, 14.05.2026 09:12-09:47
Lead: @sabine. Scribe: @tobias.
Loop 1 (09:12-09:20)
- Observe: 500 rate in order API is at 8%, DB CPU 95%, replica lag 4 min.
- Orient: Replica throughput drops, master load rises. Two interpretations: a) batch job blocks master, b) hardware issue on replica.
- Decide: Prioritize option a) because batch-job log is notable. Stop batch job.
- Act: 09:18 batch job stopped via kubectl.
Loop 2 (09:20-09:30)
- Observe: 500 rate drops to 2%, DB CPU to 70%, replica lag climbs further to 6 min.
- Orient: Master pressure is gone, but replica issue is independent. Possibly hardware or network.
- Decide: Initiate failover to standby replica, keep original replica under watch.
- Act: 09:28 failover via Pgpool, status update to customers.
Loop 3 (09:30-09:47)
- Observe: 500 rate 0%, replica lag 30 s and decreasing, new replica stable.
- Orient: Stabilization reached, original replica requires post-incident investigation.
- Decide: Incident closed, set up postmortem.
- Act: 09:47 incident closed, 5 Whys workshop scheduled for 15.05.
Pitfalls
Recognize symptoms and steer against them
Observe becomes interpretation
Observations contain conclusions ("there is an attack") instead of data ("Login attempts from IP range X at 500/min").
Keep the Observe quadrant strictly data-only. Interpretation belongs in Orient. The coach interrupts if words like "clear" or "obvious" appear in Observe.
Orient is skipped
Team jumps directly from Observe to Decide and the first interpretation becomes the decision, with no alternatives.
Make Orient a mandatory phase with at least two interpretations. Ask: "Which other explanation fits the same data?" If only one interpretation exists, pause the loop.
Loop gets stuck in analysis
Team analyzes for 20 min and does not move to Decide or Act. The situation develops further without own intervention.
Enforce the timer strictly. Better a decision with 60% certainty than 100% certainty too late. Escalate to the next level if the lead cannot decide.
No effect measurement after Act
Next loop starts without data on the previous action; effect is inferred rather than observed.
Define before Act which metric makes effect measurable. Keep telemetry visible in Observe. If the action is not measurable, redefine the action size.
Lead without decision authority
Decide requires escalation and repeated approvals, so the loop stalls and the advantage is lost.
Clarify decision authority before OODA and make it explicit in writing. If the lead is not decision-authorized, appoint a higher-level lead or pre-approve escalation.
Stop criteria
Done signals checkable in under a minute
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.