The OODA Loop Model: How Great Engineering Managers Identify and Respond to Challenges

One of the many responsibilities of any great engineering leader or manager is that of making decisions. In terms of how to best do that, there are many decision-making models, including the OODA loop model.

The OODA loop

While it might sound like a kids’ whimsical game, the OODA loop is an excellent tool for engineering managers and leaders in general. The theory was created by Colonel John Boyd, a military strategist in the United States Air Force.

The OODA acronym stands for observe – orient – decide – act cycle, a decision-making process commonly used both in the business world and outside it.

It was created to win military battles by leveraging agility and quick decision-making. Professionals in many fields use it: law, business, military, but also in software development, and cybersecurity.

The world of software development is highly competitive, and getting the head start or moving quicker than the competition could make the difference between profitability or collapse. The creator of the OODA loop and his partners learned to use time as a formidable weapon. Later, these military leaders started businesses that continued to refine these techniques. 

The OODA loop theory focuses on using available energies to get out alive and win the battle. In the business world, this means leveraging available strengths and advantages to make better decisions faster. It also means getting better at thinking critically, assessing, anticipating, and minimizing risks. For some, the word “strategizing” conjures up mental images of heavily caffeinated, yet bored people locking themselves in the boardroom for hours. For others, it comes alive as conscious, deliberate, and calculated moves in their everyday operations. You’ve probably guessed which approach translates into success.

Every department has some tools in the box that help leaders with their decisions. Sales have CRMs, Marketing has Web Analytics, and Software Development has Git Analytics. Git Analytics tools, such as Waydev, Pluralsight Flow, formerly Gitprime, and Code Climate Velocity are built to help engineering leaders make better decisions by providing them with data. Leveraging that data efficiently will help engineering leaders gain the upper hand over their competitors, increasing the velocity of the organization and driving productivity up.

What it means to be agile

Agility is seen as the ability to change direction quickly in reaction to changes in the environment or context. It is an outcome of using the OODA principles, and it is crucial whenever ambiguity, confusion, and changes in the environment can lead to disorientation and panic. In military scenarios, the way one responds to panic, disorientation, low morale, and lack of cohesion will decide between winning the battle or losing it. All parties involved are vulnerable to such scenarios. This is where time comes into play – if one side can move faster (be more agile) than its opponents, victory will be possible.

This applies to business just as well as a military battle – it’s what smart, strategic companies do, not only survive but to thrive. This allowed Honda to dismantle Yamaha’s aggressive attempts to take over the market in the early 80s. At the time, Yamaha was aiming to become the leader in the industry but failed to turn that ambition into reality. Honda responded by using all of its resources to make fast decisions and changes. This translated into quicker operating rhythms, which enabled the company to churn out many more products than its competitor quicker. 

Honda used decision cycle time to create new products, learn from customers’ reactions, and continually refine them to best suit the needs and wishes of the public. There is no reason why the type of strategy Honda used could not be applied to technology products like a new SaaS tool or the next fintech giant. As an engineering leader, gauging the velocity of your engineering teams without any tools is difficult. Git Analytics tools help you gauge the velocity of your engineering teams by measuring each step of the cycle time. 

The four elements of the OODA loop

Any side (an individual, an army, or an organization) involved in a conflict (personal, military, or business-related) needs to be engaged in four essential activities:

Observation

This refers to taking thorough notice of the current environment – of their own position, that of their opponent, and their allies. The physical and mental state of all parties also needs careful observation. Actively seeking and absorbing all details of the situation is crucial. For a company, this usually means a lot of data gathering – as much data as available at the time. Engineering leaders can let Git Analytics tools do the data gathering for them. The Project Timeline feature is a great starting point for the observation stage.

Orientation

This is probably the most crucial step. It involves a process of bringing together one’s genetic heritage, cultural background, and all previously acquired knowledge and experiences. The unique blend of wisdom and cross-referencing abilities help one reach a conclusion regarding the situation. For organizations, this step is where situational models can be created, ideally using machine learning to limit bias and define imagined outcomes. Whether the results of the orientation match reality (and how well they do that) or not, it depends on the quality of the observation. 

Decision 

For individuals, this step happens almost simultaneously with orientation. While processing all gathered data internally, one reaches a conclusion, and “intuitively” knows what to do next. What Colonel Boyd meant by “intuition” is actually the result of all previously acquired knowledge and experiences and not some esoteric spiritual concept. For organizations, decisions will be made by taking into account all situational models created after observation and orientation. Once a decision is made, leaders need to inform and keep teams focused on the agreed roadmap. 

Action

This stage includes steps to implement the roadmap and any adjustments that need to be made along the way. It could also involve a testing phase at the beginning (such as A/B testing). The important point is that we should constantly be looking for mismatches when we observe and orient ourselves. During the action stage, engineering managers can spot any unusual activity or outliers using Git Analytics tools, which are designed to detect unhealthy work patterns in engineering work. 

Any sign that our conclusion doesn’t match the reality is extremely valuable. This will lead to adjusting the roadmap, and increasing chances to success – hopefully before competitors do the same.

Thinking back to the example of Honda versus Yamaha, what allowed Honda to succeed was the speed with which it moved through OODA loops. They were better at testing scenarios, developing products, gathering and learning from feedback, making changes, and coming up with better products.

In only a year and a half, Honda brought 113 to the market (replacing their initial 60) while their competitor only came up with 37. It was all possible because Honda was more abrupt and unpredictable, better able to change its orientation. In other words, it had more agility, and it executed OODA loops quicker than its opponent. 

Agility is different than speed – speed increases momentum and makes actions or direction more predictable. What was even more impressive was that the quicker the loops got, the more panicked and paralyzed the other side became. The opponent was left with confusion and ambiguity that interfered with its ability to make rational decisions. 

What leaders need to be aware of

According to the creator of the OODA loop, successful strategies are also dependent on a few prerequisites that define and challenge leadership.

Culture matters

Competitors can copy everything you do – your products, your marketing strategies, etc. but can’t replicate your culture. A healthy and thriving internal culture can build unity and mutual trust between team members. This is incredibly rare but also tremendously important – it is the (not-so) secret ingredient of successful companies.

Trust is born when experiences are shared, especially challenging ones.

Spending two intense months working overtime as a team to meet a deadline or fix a crucial problem will probably leave you feeling a lot closer. It then allows for a sort of “intuition” that gets built on intense training and simulations done by the team. This intuition is then used is all subsequent decision-making and actions. 

Communications between members become quicker and more effective, less prone to misunderstanding. After working with each other for a while and having built mutual trust, teammates “intuitively” know what the other feels or thinks without having to put it in clarifying words. They start to read cues and get a sense of the situation much faster.

For these reasons, it leads to quicker OODA loops. Individual initiative is also born out of trust – if a manager needs to approve at every step, team members will feel controlled instead of feeling empowered. This kills creativity, autonomy, and responsibility. In the words of London School of Business researcher Charles Handy, “Trust gives people a sense of belonging. When people feel they’re active members of their work community – not merely hired help – they become interested in the company’s future and willingly dedicate their time and talent.”

Git Analytics tools' features help engineering managers to enrich their communications with actual data, thus, running more effective communication and less disruptive meetings. Daily stand-ups narratives are supported by actual data, using the Work Log that displays a map of engineering activities. Using the Developer Summary, engineering managers can review individual historical outputs in One-to-Ones, so they can be mapped to the impact on the team’s objectives, and tied back to goals and expectations. Doing this creates a sense of clarity that boosts team members’ motivation.

Leadership is based on an implicit “contract” between managers and their teams

This maximizes individual contribution based on each individual’s understanding of the overall mission. Simply put, instead of telling people what to do, leaders should help them understand and agree on the overall mission. This will allow team members to independently respond to the challenges at hand, based on the shared understanding of the mission, the training, challenges, and successes experienced as a team. When based on a shared agreement, team members’ levels of responsibility increase significantly. Morale, dedication, and implicit communication also increase, speeding up OODA loops. 

Remember, however, that a valid contract also implies negotiation of its terms. Therefore, a manager slapping a tough responsibility on someone in their team without having a proper conversation beforehand does not count as establishing a contract. Clearly and honestly stating the problem of what is being asked is essential – do you need them to step in and fix code bugs for the next three months or just to get some features ready by next week? Allowing time for clarifying questions and comments is also part of the process. In the end, you have a contract only if the person agrees to the terms jointly discussed and agreed on. 

Teams need focus and direction 

This refers to having a common understanding of the priorities at hand and what each team or organization member should be doing to support it. Flexibility and individual initiatives are part of this – when the focus is clear, individuals can and should be allowed to make judgments, adjust efforts, and manage themselves instead of constantly relying on others to tell them what to do. 

One of the typical ways to get people to focus is to develop clear goals like increasing sales by 30% or cutting costs by 15%. The problem with this type of goals is that they usually lack context and fail to get people’s buy-in. Since you’re cutting costs, how did you conclude that it should be 15% – why not less or more?

For Toyota, the guiding principle was simple – shortening the time it took to go from order to delivery. This was simple enough to guide decisions made by all types of employees. 

One problem that engineering leaders used to face is that engineering work lacked performance metrics. Therefore, it prevented them from setting SMART goals. Git Analytics tools developed code and code review metrics that enable measuring the engineering work, thus setting goals, and getting people’s buy-in. Do you have anything like that in your company or team – a general goal that empowers team members to support it and work towards it?

In conclusion, an OODA loop moves an individual or group through observation of developing situations, analysis of scenarios, choosing a course of action, and acting according to the resulting roadmap.

For the creator of the OODA loop theory, these elements aren’t necessarily consecutive, clearly defined steps – they tend to flow into one another. 

• Photo source: https://blog.stratasan.com/measuring-success-physician-relations
• https://global.yamaha-motor.com/jp/news/2016/1005/collaboration.html
• https://blog.trello.com/huddles-design-critique-framework-for-teams
• https://www.hospitalitymagazine.com.au/the-art-of-negotiation/
• https://penji.co/5-ways-to-set-goals/

Previously published at https://waydev.co/ooda-agile-data-driven/