OODA Loop

The idea

John Boyd, a US Air Force colonel and strategist, described how people and organisations cope with a changing, uncertain world as a loop: observe what is happening, orient to it, decide on a course of action and act, then observe the results and go round again. He developed the idea across his briefings and drew it as a sketch only once, in "The Essence of Winning and Losing", whose last version dates from January 1996.

The popular version is four boxes in a circle. Boyd's sketch is richer. Orientation sits at the centre: genetic heritage, cultural traditions, previous experience, new information, and analysis and synthesis all interact there. Orientation shapes what we notice, which options we consider and how we act, often through implicit guidance and control rather than explicit decisions. Feedback from decisions and actions flows back into observation. Boyd's labels are telling: the decision is a hypothesis and the action is a test.

Boyd's competitive point was that an actor who can get inside an opponent's loop, acting before the other side has reoriented, leaves the opponent responding to a situation that no longer exists.

Why it works

Orientation decides what you see. Two teams can look at the same dashboard and reach opposite conclusions, because their models and experience filter the data. Improving orientation often matters more than collecting more data.

Tempo compounds. A team that completes many small loops learns faster than one that completes a few large ones, and each loop corrects the errors of the last.

Treating decisions as hypotheses keeps them correctable. If the action is a test, you plan how to observe its result, rather than declaring victory at the decision.

Where it applies

• Incident response, where the loop is explicit: gather signals, form a working theory, choose a mitigation, act, and check whether it helped.
• Competitive and platform strategy, where the question is how quickly the organisation can sense a market shift and change its roadmap.
• Delivery feedback, where telemetry, small releases and experiments shorten the time from idea to evidence.
• Architecture reviews, to ask how a design affects the speed of the organisation's loop, not just its throughput.

How to apply

1. Map your loop. For a recurring decision, write down how you observe, who orients, who decides and how action happens, and time each stage.
2. Find the slowest stage. It is often orientation, waiting for the right people to agree what the data means, or action, waiting for a release window.
3. Invest in observation that feeds orientation. Good telemetry, customer signals and shared context, not more reports.
4. Challenge your orientation. Ask which assumptions or past experiences might be misleading you, and invite people with different views.
5. Make actions small and observable. Design changes so their effect can be seen quickly and reversed if the hypothesis was wrong.

Example scenario

A retailer's checkout errors spiked during a sale. The on-call team had an orientation built on past incidents, all caused by the database, so they spent forty minutes tuning queries while errors continued. Each fix took a full deployment to try.

In the review, the architects traced the loop rather than the root cause alone. They added tracing across the payment provider, gave incident commanders a feature flag to switch payment routes, and made "what else could explain this?" a standard step. In the next incident the team ruled out the database within minutes and switched routes, completing several loops in the time one used to take.

Questions to ask

When not to use it

• Stable, well-understood problems, where a known procedure beats improvising a loop.
• Irreversible decisions, where speed should give way to careful analysis before acting.

How it misleads you