The world is full of good ideas misapplied, so I want to be careful when discussing OODA loops. The OODA loop was created as an idea in the study of war. War is endemic to the way humans are (at least, so far), but it is always, in part or in whole, a tragedy. And characterizing software engineering, business operations or entrepreneurship as a conflict in that vein can create an overly aggressive view of the world. But, I belive, this concept can be adapted to a more civilian setting. The key difference is that, in war, the main conflict is with some adversary, and it is brutal. But in a software project, the conflict is mostly with ourselves and our environment. And if it feels brutal, that’s certainly a red flag!
Observe, Orient, Decide, and Act
OODA stands for Observe, Orient, Decide, and Act. It’s a model of how individuals and organizations take in the world (Observe), form an understanding of it (Orient), pick a strategy to pursue (Decide), and affect their environment (Act). And, as a result of their actions and the passage of time, new observations are available, and the cycle can begin again.
In the case of war, speeding up this cycle for yourself and slowing it down for your adversary allows you a more accurate model of your environment and more optimal decisions than the other side. In the software and product world, our adversaries are mainly ourselves and our environment. We’d typically focus on managing the pace at which our team and its members can run this cycle. We may have adversaries in the form of market competitors, but it’s a lot tougher to affect them directly, especially if you’re a smaller organization.
Col. John Boyd invited the OODA loop and perfected it over many decades. He was a skilled fighter pilot. And, although he didn’t get to do much combat, he did dominate training exercises. He understood how to control his aircraft, and he could out-turn his opponents and surprise them. He helped design the F-15 and, later, as part of the “Fighter Mafia,” created the F-16. Over time, he formalized his ideas of warfare in his classic “Patterns of Conflict” lectures that inspired the Maneuver Warfare doctrine of the Marine Corps. Some say he even went on to influence the “shock and awe” strategy of the first Iraq war. All of his ideas had a common thread, an emphasis on maneuverability and pace of decision making.
OODA Loops Applied
Taking appropriate action quickly is desirable in any domain, so we can keep extending his ideas elsewhere. Clearly, the pace of decision-making also plays a big role in modern agile practices. Practices like two-week cycles, retrospectives, Kanban boards, and so on can be viewed as improving the pace of one or more parts of the OODA loop. And many others have drawn those parallels and written about it.
But, how did Boyd view it? The OODA loop is an interesting model, but how do we apply it? Let’s see how Boyd’s ideas apply to software development. In his lectures, he would focus on four core principles to disrupt an opponent’s decision-making cycle and preserve your own: initiative, variety, rapidity, and harmony. Here is a quote to that effect from his slides for Patterns of Conflict:
“He who is willing and able to take the initiative to exploit variety, rapidity, and harmony as the basis to create as well as adapt to the more indistinct – more irregular – quicker changes of rhythm and pattern, yet shape the focus and direction of effort -— survives and dominates, or contrariwise”
Again, we don’t typically have an opponent in a software development lifecycle. But our decision-making processes are still challenged just by the nature of developing software. Anyone who has tried to develop software can attest to the myriad of ways the cycle can stretch out and produce incorrect orientation and bad decisions. We are often, sadly, our own worst enemies and most potent opponents. So, let’s see how to apply these.
Variety
“Plans are nothing; planning is everything” — Dwight D. Eisenhower
Planning is typically viewed fairly linearly. Imagine a timeline of milestones when you kick off a project. Or even a Gantt chart, with its task dependence, is still fairly linear. Everything is expected to happen in order, with minimal disruption and in a known order. But that’s not a reflection of reality at all. A more accurate plan might be a branching tree of actions that depends on our model of the world at each step. But, I admit, that’s not exactly easy to create or explain to others.
Still, a linear plan is an unlikely path through that infinite tree of possibilities. So, being married to a plan, especially a long one, subjects you to friction. Quickly, your plan and reality diverge. As you observe and orient yourself, you either keep going with a plan that doesn’t fit the situation you’re in or start making decisions and actions that reflect reality but have no long term view. This is especially chaotic when members of your team randomly choose from those two approaches.
Boyd espoused a better approach. That is, to have a greater variety of plans for the most likely scenarios, update your plans frequently, and avoid making overly-detailed plans over a long time. And, of course, make your plans clear and understandable to everyone. Like water running down a hill, your team has to have a general direction but be able to deal with obstacles as they come up. As you’ll see, this dovetails nicely with the other principles.
Rapidity
“Everyone has a plan until they get punched in the face” — Mike Tyson
Boyd thought about rapidity as another piece of the puzzle. You execute quickly, take in the new environment, and plan again. A sort of jagged path towards the goal, where at each step you adjust your course and see how far you can get. From his point of view, if you are iterating fast enough, it doesn’t matter if you’re right at any one point in time.
Bogged Down in Execution
When we create software, we often focus on quality and whether a feature fully meets customer needs. And no doubt quality is of utmost importance. Quality has a benefit and a cost, though. The exact level of quality necessary to release a feature is a topic of great debate, but getting bogged down in execution is a huge and sometimes hidden cost.
Often, the way we view a feature and the way a user or stakeholder views it are quite different. Without a feature release, we tend to focus on the wrong elements. We get stuck thinking “this one thing” will make or break the feature, and we can’t release without it. We think we know, but we don’t really know. Boyd would say, if you can iterate fast enough, the significance of any one change goes way down. So, with that mindset, some of the most important changes you can release aren’t the features themselves, but the development of tooling and safety nets that make you comfortable releasing faster.
Getting There Faster
This is reminiscent of a lot of DevOps practices. Testing, logging, and monitoring are there to let us observe and orient ourselves. They give us signals that something is not working, and we need to act. Including feature creators as a huge part of the operation and deployment of the service gets the observations to the right place fast.
Additionally, deployment pipelines, feature flags, and other such levers let us take a variety of actions when releases go wrong. Yet, that tooling is often neglected, slow, or buggy in many projects. Or, it’s the opposite. We try to maximize test coverage with “junk tests” or maximize the amount of metrics collected. In turn, this can create a brittle pipeline, noise, and busywork that slow us down instead of speeding us up. We forget that the goal is the safety and visibility needed so the team can rapidly iterate on the product.
Harmony
“How is it they live in such harmony, the billions of stars, when most men can barely go a minute without declaring war in their minds?” — Thomas Aquinas
Boyd saw a benefit to “pushing down” the decision-making to smaller groups. Organizations intrinsically have a much slower OODA loop than the smaller groups and individuals within them. Coupling all decision cycles to some main cycle slows all cycles down to the pace of the slowest cycle.
Centralized decision-making is, in a way, a form of distrust. Distrust in the ability of others to make decisions that are equal or better than some central authority. And distrust is a force that tears groups apart.
A Common Outlook
But there is a crucial other element to this decoupling: teams need a common outlook. A “common outlook” is an implicit shared perspective about the world and a common understanding of how things are done. In the military, this is achieved with training and studying common doctrine and tactics. In the software development world, this can come through good hiring and consistent communication of expectations. This kind of communication can be explicit via an official vision statement and company values. This kind of communication can be implicit by the decisions that are made. And, of course, when communication is lacking, inconsistent, or conflicting, that just makes the lack of a common outlook more evident, and dysfunction creeps back in.
When a team has a “common outlook”, they need less communication to achieve a task. With a common outlook, they can be guided by “commander’s intent”, which is a directive that has a “what” and a “why” a thing is to be done rather than the precise steps to achieving it. By not being prescriptive about how things are done, leadership allows the executing team to adapt to the situation as it changes.
Building Trust
This is a highly effective way to lead talented people, too. They’re closer to the action, and they can undoubtedly make better decisions given the right context. Furthermore, organizations that deny that freedom to their members will often lose their top talent.
When trust creates great decisions, then great decisions create trust. This is a virtuous cycle that improves the whole organization. And a vicious destructive cycle when each decision goes poorly and destroys trust. Creating the kind of cycle that pulls apart the enemy’s harmony was a big part of Boyd’s war-fighting doctrine, so avoid waging that sort of war on your own team.
Initiative
“Have taken Trier with two divisions. Do you want me to give it back?” — George S. Patton (on receiving orders to bypass Trier because it will take four divisions to take)
John Boyd is often referred to as a “maverick,” which I believe is code for “pain in the butt”. Boyd was an agitator who had almost as many enemies as he had friends. He fought for what he thought was right. The right way to pilot, the right way to design a jet fighter, the right way to fight a war. And he had enough energy to wear down the people around him and leave a legacy of great ideas and improvements. He embodied a certain form of initiative. I’m sure many of you have had an irritating person like this on your team. And sometimes their initiatives weren’t too good, so what’s up?
What Doesn’t Work
Boyd would say that initiative requires all three elements of variety, rapidity, and harmony to be in place. You need to understand the general direction and contingency plans, processes that enable moving fast, and certainly the trust and understanding of others in your organization. Forcing initiative on an organization that can’t or won’t support it typically generates conflict. Then, one side wins (typically the status quo), and changes are made to prevent further disruptive initiatives.
Taking action when an opportunity presents itself is critical. As a software product team, this could mean taking action with an imperfect plan or design. At the individual level, this could mean keeping your code organized and tested, making sure user experience is clear and fast, and adding necessary monitoring as you see fit without input from others. Some of the best initiatives I’ve experienced have been unsolicited proof-of-concept demos of features or tools that open up a whole class of future possibilities.
Organizations that lack initiative have slow OODA loops. And, those where individuals have to clear their actions with the whole organization are a magnitude slower because they couple their loops with the whole organization. Initiative at all levels forces your team to close their loop faster by taking more actions and providing observations for the next go-around.
Encouraging Initiative
In lean product design, a related idea exists with MVPs (Minimum Viable Products), where a stripped-down version of the final product or feature is released to understand how users will react to it. In design and engineering, we have the concept of “spikes” that give us a time-boxed amount of time to test an idea or answer a question. These all encourage initiative in some way.
But, perhaps the most important to draw from, is the concept of “psychological safety”. Organizations that amplify fear of having an idea being ridiculed, fear of being wrong, and fear of failure, destroy initiative. Rejecting a few bad ideas in a supportive way and enduring a dozen just okay initiatives is worth that one great one.
OODA Loops: A Simple Model with Sophisticated Implications
Developing software always feels like a somewhat unique engineering activity. Unlike other engineering disciplines, our constraints are a lot less grounded in physical reality and more in the abstract. Creating a software product is a lot more about structuring information, dealing with the psychology of the user, and adapting quickly to changing expectations.
Being so abstract and flexible, it’s easy to pull in and adapt ideas from other domains. Many other fields have a strong informational component. And military strategy has a surprisingly similar set of challenges and solutions. John Boyd was not the first to focus so much on the information-action dynamic, but this focus was especially appropriate in the late 20th century. With increasingly sophisticated war machines, military strategists were more and more limited by information than by their weapons. In parallel, software was already well on its way to “eating the world” (and that included its militaries).
The OODA loop is a simple model of gathering information and making decisions, but it has some sophisticated implications. One important element that it prioritizes better than a lot of other “agile” or “lean” framework is distilling the importance of taking action, making and re-making plans and gathering information. It creates clarity that cuts through the noise of all the ceremony that can go along with running and being part of a project. Try applying it to your project and see if it creates some insights for you.