From OODA to Reviewable Decisions: Make Fast Decisions You Can Learn From

Decisions that recur (a price to set, a source to keep, a threshold to change) are made inside a loop: you look, you interpret, you choose, you act, and the result becomes the next thing you look at. Colonel John Boyd, a military strategist, described this as the OODA loop: observe, orient, decide, act. His claim was that the side that cycles through the loop faster than the other, while keeping its picture of the situation accurate, gains the advantage.

That is a useful idea for any team that acts on data. It also has a trap: “faster” is only good if each pass teaches you something. A team that decides quickly and remembers nothing repeats its mistakes quickly. This article is about the small amount of record-keeping that makes a fast loop a learning loop.

The loop, briefly

• Observe: take in information: the data, the news, the changes since last time.
• Orient: make sense of it. This is the step Boyd cared about most. Your experience, your assumptions, what you expect and what you did last time all shape the interpretation. It is where bias enters.
• Decide: choose among the options.
• Act: do it, and watch what happens, which feeds the next observation.

The usual four-box circle is a simplification of Boyd’s own diagrams, which include feedback and shortcuts between steps; Frans Osinga’s book is the best account of the full idea. For practical purposes, remember two things. Orientation is where most errors start. And the loop only improves if its steps leave a trace.

Why outcomes alone teach badly

After a decision, we naturally look at the result and judge the decision by it. That is a poor teacher for two reasons.

First, results are partly luck. A good decision made with a 70% chance of success fails three times in ten; a poor one made with a 20% chance succeeds one time in five. Judging each decision by its single outcome would teach you to imitate the lucky ones (Outcome Bias).

Second, memory rewrites itself. Once you know how things turned out, it feels as though you saw it coming, and your recollection of what you thought drifts toward the outcome (Hindsight Bias). By the review meeting, nobody remembers that the plan rested on a shaky assumption.

The remedy for both is the same: write down what you knew and expected before the outcome.

The decision record

A decision record is a short note made at the time of the decision (Decision Record). It does not need to be long. Five lines are enough:

1. What we saw, with the version or date of the data. (“Competitor price fell 10%; snapshot of 09:00.”)
2. What we assumed. (“It is a promotion: the same thing happened twice before and recovered within three days.”)
3. What we chose, and the options we rejected.
4. What we expect, as a number or a probability where possible. (“We lose under 2 points of share; 70% confident.”)
5. When we will look again, and what would change our mind. (“On Thursday; if the drop is still there.”)

Orientation, the step most prone to error, is now written down, so it can be examined and tested.

The review

On the review date, compare the outcome with the record, not with your memory.

• Was the assumption right? (Was it a promotion?)
• Was the expectation right? (Did we lose less than two points?)
• Was the confidence about right? Collect your “70% confident” calls over time and check whether about 70% of them came true (Calibration, Brier Score). If your 70% calls come true only half the time, you have learned something precise about yourself, which no single outcome could have shown.

Notice what the review does not do: it does not grade the decision by the outcome. A bad outcome from a sound process leads to “unlucky, keep the process”; a good outcome from a weak process leads to “lucky, fix the process”.

Making it light enough to survive

Teams drop records that cost too much. A few habits keep the cost low:

• A template with five fields, as above, in the place where the decision is made.
• Automatic context. Let the system fill in the data version and the time; people write only what the system cannot.
• Append, don’t edit. If the decision changes, write a new record that supersedes the old one (Append-only Ledger). The old one is what makes the review fair.
• A pre-mortem for big decisions. Before a large commitment, imagine it has failed and list why; turn the best answers into early-warning signs and write them into the record (Pre-mortem).
• Review in batches. Once a week, look at the records that have reached their review date; it takes minutes.

What you get

Speed and learning: the loop runs as fast as before, but every pass adds to a shared memory of what was seen, believed and expected. After a few months the records show where your orientation is reliably off, which assumptions keep failing, and how well your confidence matches reality. That is the advantage Boyd was after: not only deciding faster, but getting less wrong each time.