The OODA Loop -- Observe, Orient, Decide, Act
post by Davis_Kingsley · 2025-01-01T08:00:27.979Z · LW · GW · 2 commentsContents
What are OODA Loops? Basic Definition Example: Unknown Object in the Road A Note on Orientation More Advanced Illustration Applications of the OODA Framework OODA Loops In Competition Getting Inside their OODA Loop OODA in the Business World OODA Loops Without Competition "OODA Failure Analysis" - a technique Final Thoughts None 2 comments
United States Air Force Colonel John Boyd was a fighter pilot and military strategist who developed several important strategic theories. While serving as a jet fighter instructor, he was nicknamed "Forty-Second Boyd" because he had a standing offer that he could go up in his plane and defeat any opponent in a simulated dogfight in forty seconds or less -- and do it starting from an extremely unfavorable position! If he failed, he would owe the challenger $40 -- but purportedly he never failed! Further, he was not only able to accomplish this feat against trainees, but also against various visiting pilots who challenged him.[1]
Boyd's concepts have been credited as instrumental to the United States's dramatic victory in the Persian Gulf War ("Operation Desert Storm"), and his insights into aircraft design have been highly influential as well. Boyd was a very unconventional thinker in some ways and did not always get along well within the system, but was nevertheless able to achieve very impressive results.
While some of Boyd's concepts, like the energy-maneuverability theory, are very specific to air combat, he also had ideas that could be applied much more broadly. Perhaps the most well known of these is his concept of the decision cycle, sometimes known as the OODA loop.
It's worth noting that I would not consider myself some superlative expert in this area. I have done substantial reading on the topic, gone over some of Boyd's old briefing slides, listened to some recorded material from Boyd's presentations, applied some of these concepts in my own life, and taught an experimental class at several CFAR workshops covering these principles; however, I am not a military strategist or aircraft designer, nor have I directly practiced this in high-level business strategy or an equivalent area. Take what I have to say here with a grain of salt!
What are OODA Loops?
Basic Definition
OODA is an acronym that stands for Observe, Orient, Decide, Act; the idea is that in order to make a decision, one goes through these steps.
In the Observe step, one gathers information about the situation around them. In Boyd's original context of fighter aircraft operations, we can imagine a pilot looking out the canopy, checking instruments, listening to radio communications, etc.[2]
In the Orient step, one takes the information gathered in the Observe step, integrates it with one's preexisting models, and uses that to compose a mental model of the current situation and one's own role in it. This is the most important and also most complicated step, and it is based in large part on things that have occurred outside the context of the specific situation you may be analyzing -- your training, experience, preexisting mental models, "priors", etc. are important here!
In the Decide step, one takes the model of the situation from the Orient step and decides what to do as a result.
Finally, in the Act step, one actually implements the decision.
Now, this is called the OODA loop -- after you have completed this cycle, you loop back to the Observe step as you see the results of your action and how the situation has changed, then go through this process again! In fact, one can in principle go through many of these loops in the context of a single situation. Let's look at a basic example of what this might look like in an "everyday" sort of scenario.
Example: Unknown Object in the Road
Let's take the example of a driver who makes a turn or moves around a bend in the road and then sees something unknown in the middle of the road ahead. We might model the driver's thoughts in such a scenario as something like this:
Initial Loop:
Observe: There is an uncertain object in the road ahead.
Orient: Based on my experience driving and encountering scenarios like this before, this might be a hazard in the road or it might be innocuous. I could potentially keep going at full speed, continue ahead but slow down, or stop.
Decide: I will slow down, giving me more time to observe what's going on.
Act: <driver slows down>
Second Loop:
Observe: Closing with the object, I see that it appears to be a plastic grocery bag stuck on the road and blowing in the wind.
Orient: This seems like it is not a hazard to me or my car, nor is it something worth investigating further.
Decide: I will accelerate back to normal pace and drive on.
Act: <driver accelerates and moves on>
It's worth noticing that much of what goes on here is implicit. One might have gone through both of these loops and carried out the associated actions in just a second or two. Similarly, it's unlikely that someone will think through these steps as "formally" as described here. You do not have to think through these processes in explicit detail!
A Note on Orientation
You may have noticed that the "orient" step in the above example brought in a lot of implicit information from other contexts -- the driver's experience, the fact that running over a plastic bag will not harm the car, and so on. This is true! In general, the orientation process is the most complicated and detailed part of the loop.
More Advanced Illustration
Now that we have that basic concept down, it is important to note that the OODA loop is not as linear as this model presents. On the real world one is often making observations while these other processes are also going on -- the driver doesn't close his or her eyes and stop looking at the road while deciding what to do next, for instance!
I want to flag that this is a very simplified presentation of the OODA loop concept, and that Boyd's original briefing "The Essence of Winning and Losing" presented a significantly more detailed version of this cycle. I consider the simplification here relevantly useful but want to be very clear that it is not all the OODA concept has to offer!
In fact, there are many different factors that feed into different elements of the OODA loop. This post is intended to be relatively basic so I will not go into them in great detail here, but I think it is worth looking at Boyd's own diagram showing the more expanded loop:
This image is from "The Essence of Winning and Losing", a briefing Boyd gave in the '90s to various military figures. Note that there are several steps that flow backwards into different components of the loop, and the much more complicated and detailed view of the Orient step in particular.
Applications of the OODA Framework
OODA Loops In Competition
The OODA loop was originally developed in the context of adversarial conflict or competition -- air-to-air combat -- and while it has other applications these are perhaps the most "natural".
Getting Inside their OODA Loop
One insight that the OODA framework leads to is that if you can go through your decision cycles faster than the opponent, you can gain a substantial advantage. By the time the adversary finishes their decision cycle, you may have already taken actions that change the situation, leaving them to either react improperly to conditions that no longer exist -- or perhaps to go back and start reorienting etc., potentially leading to decision paralysis. This is sometimes referred to as being "inside their OODA loop", phrasing which as I understand it originates with Boyd himself.
Basic military tactics, such as ambushes, can be conceptualized in terms of the OODA loop -- by carrying out an ambush and attacking enemies that are not initially aware of what's going on, one can initiate the conflict while already oriented to the situation, while your targets are not yet oriented to a battle, hence catching the enemy off guard and delaying their response.[3]
I remember applying the OODA loop in the context of a video game called Friends vs. Friends, which combines first-person shooter mechanics with a hand of cards you can play to dramatically change the situation -- playing a card might give you a more powerful weapon, make your opponent's head larger and easier to hit, give you bonus health, or even transport both you and your opponent to a new map! However, the opponent sees what card you have played. One thing I realized by applying the OODA framework was that playing some especially powerful cards at the last possible moment was a good way to get inside the opponent's OODA loop; while "by default" people (including me!) often played cards earlier in the round, this gives opponents more time to react.
For example, if I played a card that gave me a shotgun (in this game a very powerful close-range weapon but bad at longer range) right at the start of the round, the opponent might know I had that and "play around" it by trying to set up longer-ranged engagements. But if instead I played the shotgun card when I was already right next to the opponent, this opportunity to counter would be diminished!
However, the most dramatic card effect that benefited from this was a card called "Weapon Swap", which trades your weapon with that of the opponent. This is already a very powerful card because it allows you to potentially trade a weak weapon for an opponent's powerful one. I also found it strong in that it can quickly reverse the tactical situation; in general in Friends vs. Friends, if I have a weapon that has the advantage at long distance I will try to keep the opponent back, while if I have a weapon that has the advantage at close distance I will try to close in. The Weapon Swap card allows you to suddenly reverse this dynamic -- for instance, if I have a sniper rifle (one of the best long-range weapons) and my opponent is rushing me with a shotgun (one of the best close-range weapons), and right when they're about to reach me I swap our weapons, the opponent now perhaps needs to do the exact opposite of what they were doing before, desperately retreating instead of charging in!
In the OODA framework, by holding onto this card and using it to quickly reverse what weapons we have equipped, I am forcing the opponent to very rapidly go through an OODA loop -- observe that I've used the card, orient to the fact that our weapons have been swapped, decide how to respond, carry out that response -- and very often they can't do it in time, either panicking and freezing up or continuing to carry out a plan that is now directly counterproductive![4]
OODA in the Business World
Similarly, one can apply this model to business decisions. The OODA concept can relevantly show how startup companies can in some cases successfully compete with more established businesses.
Let's say that a smart engineer at a small startup and a smart engineer at a big company notice a new opportunity at the same time. At the startup, at least in principle the whole organization could pivot to focus on this opportunity (assuming it seems promising enough) within a few days. At the large company, the engineer might meet with their manager, who might then bring something up at a higher level meeting, which then might go to a strategy board, which might then request some people do a pilot program, which (if it goes well) might then be passed up to higher executives for evaluation... and each of those steps might well take multiple weeks! In fact, "weeks" is perhaps optimistic for some!
In other words, by the time that the big company has gotten through its complicated decision cycle, the small startup might well have run through multiple full OODA loops involving testing new ideas, seeing how customers react, and so on. This can be a major advantage for the smaller, more agile group!
A friend of mine from college now runs a startup company that offers an API allowing air carriers to make much quicker changes to their offerings. For complicated bureaucratic reasons, doing basic A/B tests of web sales at airlines using previous systems would often take months or even years to implement, and my friend's company offers a system that can enable much more rapid decisions. One can perhaps easily see why it would be a very major business advantage to be able to test out new product or web sales ideas multiple times faster than one's competitors -- your OODA loop has suddenly become much, much quicker!
(Important Note: there is more to getting inside an opponent's OODA loop than just speed and surprise, but I need to study and practice this aspect more before I feel comfortable writing it up in detail. I'll hopefully have more on this later!)
OODA Loops Without Competition
This idea of "getting inside their OODA loop" -- while interesting and helpful -- is not the only area where Boyd's OODA principles can be applied! In fact, thinking about improving the OODA loop can be helpful even in scenarios where one does not necessarily have any direct competitor at all.
One might, for instance, consider how to make your own decision cycle faster and better even without external adversaries pressuring you. One interesting example of this was when Lightcone was recently renovating their campus. I remember noticing that they were willing to pay a premium in order to get decision-critical information faster in order to clear relevant bottlenecks -- for example, when considering a certain aspect of their project that required an external specialist to evaluate (I believe a plumber or electrician but might be misremembering?), the Lightcone team was willing to pay extra to get someone who could come that day in order to get the critical information they needed faster.
This sort of action can be conceptualized in an OODA framework -- in this case, the key issue in the process is the need for specialist observation and orientation, which the main team cannot really provide. By putting a high premium on getting that specialist input quickly, one can get through this (otherwise bottlenecked) step and move on to the rest of the project quickly. However, the rest of the loop has to be able to handle it -- if we imagine a scenario where, despite getting the specialist's evaluation as quickly as possible, the team doesn't meet to discuss things further until another month, the haste to get that critical information doesn't seem to make very much sense!
"OODA Failure Analysis" - a technique
One technique that I developed is something I call "OODA Failure Analysis" -- this technique uses the OODA framework as a method of analyzing things that have gone poorly in scenarios one encounters in one's own life.
When teaching my OODA class at CFAR workshops, I often ask participants to come up with a list of several things that have gone wrong for them recently, ranging from minor issues -- "I missed the train last week and was late for work" works fine here -- to more serious problems.
If you want to apply this technique here, please actually do that now. This is not a joke, and you will probably get more out of the post if you do. List ten things, actually write them down on a piece of paper or a document on your computer or something. Don't vaguely have four things in your head, actually write down ten.
Then, I have them analyze each of the different situations they came up with in terms of where in the OODA loop something went wrong.
In other words, did this go wrong because of bad observation, bad orientation, bad decisions, or bad actions? Here are some quick examples:
- Alice's team develops a major product without first checking to see if it's something people actually want -- after a year and a half of development, the product works great, but it turns out there isn't much of any demand. (I would consider this an observation failure -- failure to observe critical information leads to lots of wasted time.)
- Bob gets into extended conflicts at work, where he argues at length with higher-ups about the direction of various projects and initiatives. Even though his arguments are often good, he makes little headway and ultimately leaves the company. Bob bemoans that he was just treating his manager as a peer -- why wasn't she willing to take him seriously? (I would consider this an orientation failure -- Bob conceptualized his role in the system improperly and thus used interaction patterns that weren't likely to succeed.)[5]
- Cathy is training for a Magic: the Gathering tournament. She knows what she's capable of, has a good sense of what the "meta" (popular/standard strategies used by other players at the time) looks like, and ends up having to choose between four or five different decks that she thinks will be viable before the event. She picks one that she thinks will be the most advantageous, even though it's something she's unfamiliar with -- but she's confident she can practice enough to make up for that in time. When the time comes, her meta read is accurate but the less familiar deck underperforms for her, and she wishes she'd gone with a different option. (I would consider this a decision failure -- Cathy had good observations and orientation to the situation, but ultimately made the wrong choice from her list of options.[6]
- Dan has a good understanding of an open market for laser-cut game pieces, a good understanding of his capabilities to fill that need, and a good plan for products that he thinks will do very well. However, for mysterious reasons he ends up not executing on the plan, and a few years later, Dan notices other companies are now producing the type of thing that he'd thought of. This is the first time anything like this has ever happened to him. (I would consider this an act failure - Dan had good observation, orientation, and a good decision, but fell down on execution. If this was a distinct pattern across many events, though there might be an orientation issue in terms of not modeling one's own capabilities accurately...)
In general, a failure at an early step of the loop can often "cascade downwards", so if you're unsure I would tend to favor reporting a failure at an earlier part of the process. Also, since decision can flow pretty directly from orientation, you may find these two similar enough that you want to group them as one; I'm undecided on whether to make that change to this technique "more formally" and probably need to test it with more participants to see!
If you want to apply this technique here, please actually classify the items on your list now. Write something down next to them, don't vaguely do it in your head.
In some cases, doing this exercise can help one notice quite distinct patterns in where things seem to go wrong -- patterns which can potentially quite help one prioritize what areas of one's own processes might need improvement!
For example, if you find yourself thinking "huh, it seems like a recurring theme in things that go wrong for me is that I keep going into situations without gathering enough information first", that could be very useful feedback as to which part of your process you might want to spend some more time on!
Also, even if you don't determine a clear pattern from a bunch of examples, I think thinking about things and classifying them like this can help build fluency with the OODA model of the decision cycle as a whole.
Final Thoughts
I have more thoughts on OODA, Boyd, and strategic thinking in general, but this post is already perhaps getting too long for an introduction -- hopefully, this will prove a useful introduction to the decision cycle or OODA Loop, and I will perhaps follow it up with more! I've found it a very interesting and at times fruitful area of study.
- ^
He had a somewhat "trick" maneuver that let him do this, but it still worked.
- ^
Boyd originally called this step "Sensing" rather than "Observing", but the name "SODA Loop" seemed rather unserious and had to change.
- ^
Interestingly enough, some military counter-ambush tactics involve reacting to an ambush by attacking very quickly and aggressively into the ambush zone, hopefully catching the ambushers by surprise and forcing them to be the ones reorienting to a new situation!
- ^
Much like in the counterambush scenario described above, the best response to the Weapon Swap card is perhaps to play your own Weapon Swap card, putting the shoe back on the opponent's foot -- now they are the ones who have to react fast!
- ^
Boyd himself got into lots of conflicts with higher-ups, but was often able to use his strategic knowledge to cleverly outmaneuver them!
- ^
You could perhaps argue that this is actually orientation failure though, with the argument being something like "she should have known she didn't have enough practice time and cut that from the list" -- see the upcoming caveat re: grouping decision and orientation.
2 comments
Comments sorted by top scores.
comment by Raemon · 2025-01-01T18:07:05.668Z · LW(p) · GW(p)
Great writeup.
- Alice's team develops a major product without first checking to see if it's something people actually want -- after a year and a half of development, the product works great, but it turns out there isn't much of any demand. (I would consider this an observation failure -- failure to observe critical information leads to lots of wasted time.)
FYI I'd classify this more as a decision failure. They really would have had to take different actions in order to get this data, so this was more at the point when they were like "do I start building this product, or do I find some random representative users and see what they think of the idea?."
comment by Raemon · 2025-01-01T18:05:43.362Z · LW(p) · GW(p)
Also, since decision can flow pretty directly from orientation, you may find these two similar enough that you want to group them as one; I'm undecided on whether to make that change to this technique "more formally" and probably need to test it with more participants to see!
I actually normally combine/conflate Observe and Orient.
I think the actual takeaway here is: any two adjacent steps can kind of blend into each other.
You might be in a microloop where you're observing and orienting (and then maybe looking for more observations and then orienting on the new ones).
Then, when you're eventually like "okay I have enough observations", you may be in a loop where you're evaluating decisions, and then looking at your confused model and trying to wrangle the information into a form that's useful for decisionmaking, then look at your decision options again, be dissatisfied with your current ability to make-sense-of-things, and do more orienting.
Then eventually you're in a state where you know how to think about the situation, and you pretty much know what the options are, but as you start thinking about "Acting", your brain starts to see the consequences of each decision in near mode, which changes your guesses about which actions are best.
Then, as you start acting in earnest, each action comes with some immediate observations.
But, you can't really move from "Observe" to "Decide" without having gone through at least a little bit of an orient step on how to classify your observations.