By 6days · v1.0 · Updated 7/20/2026
Observe, orient, decide, act — and win by cycling faster than the situation changes.
Fill this in for your own situation — a private worksheet only you can see.
When to use
Use it in genuinely competitive, fast-changing situations — an incident, a live negotiation, a competitor's surprise move, a crisis. It suits environments where information is incomplete by nature and waiting for completeness means losing.
When not to use
Avoid it for decisions that are expensive to reverse and slow-moving: a factory site or a pension scheme does not want tempo, it wants analysis. It is widely misread as 'decide fast', which drops the orient step and produces speed without judgement. It also has little to say where there is no adversary and no clock.
In fast-moving situations the quality of a decision decays with time. A team gathers information, builds consensus, and commits — and by the time it acts, the situation has moved and the decision addresses a world that no longer exists. Meanwhile a less careful competitor has already acted three times, learned from each, and is operating against a picture of reality that is simply more current than yours.
The OODA loop describes decision-making as a continuous cycle: observe what is happening, orient by making sense of it against your models and experience, decide on a course, act, then observe the results and go again. Its central claim is comparative — in a contest, whoever cycles faster and more accurately accumulates an advantage, because their opponent is perpetually responding to a stale picture. Orientation is the pivot and the part most often skipped: it is where prior beliefs distort what the observations mean, and a fast loop feeding a broken orientation just produces confident errors at speed.
Framework by 6days on 6days — https://6days.apexaion.ai/framework/ooda-loop
An ordered process with 4 phases.
Gather what is actually happening — raw signals, unfiltered.
Make sense of it, and challenge the frame you are imposing.
Commit to a course while information is still incomplete.
Execute so the action itself teaches you something, then loop.
Gather what is actually happening — raw signals, not the summary someone assembled to support a position. Most organisations observe through reporting layers that have already discarded the anomalies, which are precisely the observations that matter.
Interpret the observations against your models, and deliberately ask what frame you are imposing and what it might be hiding. This is the step that determines everything downstream and the one under time pressure that gets skipped. A fast wrong orientation is worse than a slow right one.
Commit to a course knowing you do not have everything. Waiting for certainty is itself a decision — usually the worst one available, because it hands the tempo to whoever is willing to move.
Execute in a way that generates information. A well-chosen action resolves uncertainty as well as making progress, which means the next observation step starts from a better place than the last.
Feed results straight back into observation, and treat cycle time as a metric in its own right. The advantage does not come from any single pass; it comes from the rate.
Worked example
During a partial outage, one team convenes a call to establish full root cause before acting. Another observes that errors are concentrated in one region, orients on a recent config change to that region's load balancer, decides to roll it back despite not having proven causation, and acts within nine minutes. The rollback resolves it — and had it not, the negative result would itself have eliminated the leading hypothesis. The first team is still on the call, assembling a complete picture of a situation that the second team has already ended.
The loop was developed by John Boyd, a United States Air Force colonel and military strategist, from the 1970s onward, initially to explain air combat outcomes and later generalised into a broader theory of competition and adaptation. Boyd published little formally, working mainly through briefings, so the model circulates through interpreters — and popular versions often flatten the orientation stage he considered central.
Related ways to think about this.
Strip a problem back to what must be true, then rebuild — instead of copying what exists.
Use when Use it when an industry's costs or practices have been stable for a long time without obvious justification, when you are entering a field as an outsider and lack the incumbents' assumptions, or when repeated incremental attempts have all failed and the problem may be framed wrongly.
Avoid when Avoid it for routine decisions — it is slow, effortful, and analogy is right most of the time. It is also a common vehicle for arrogance: reasoning from first principles while lacking domain knowledge tends to rediscover why the convention exists, expensively. If experts cannot explain why a practice exists, that is worth investigating; if they can, listen.
Ask how this fails, not how it succeeds — the failure list is shorter and more honest.
Use when Use it before committing to a plan that is expensive to reverse, when a team has become uniformly enthusiastic and you suspect the optimism is social rather than evidential, and in any decision where avoiding a catastrophic downside matters more than optimising the upside.
Avoid when Avoid it as a general operating posture — a culture that only inverts becomes paralysed and treats every idea as a hazard. It is weaker in genuinely novel territory where the failure modes are unknown rather than unspoken. And it will not generate a strategy: it removes ways to lose, which is not the same as finding a way to win.
Separate urgent from important, and notice how much of your week serves neither.
Use when Use it when you are busy but not progressing, when a team is permanently reactive, or during a periodic review of where a role's time actually goes. It works well as a recurring habit rather than a one-off, and it is a useful device for a manager and report to look at a workload together without it becoming personal.
Avoid when Avoid it where you have little real autonomy — telling someone to delegate work they cannot delegate is just a way of blaming them for their constraints. It handles individual tasks better than long collaborative efforts, and it has nothing to say about work that is important to someone else and not to you, which is most of what makes a job hard. It also assumes you can tell importance from urgency, which is exactly the skill people struggling with this tend to lack.
