Written By Jon Duke, Head of Aviation at Airbox Systems.
Jon is a former military air traffic controller and pilot with two decades of experience in aviation, where the OODA loop was a fundamental component of his profession. As a search and rescue pilot, Jon operated in some situations similar to those described in this series. His time as an Air Traffic Controller and instructing new pilots allowed him to see the cockpit from different perspectives, and led him to where he is now. He is passionate about helping overcome the threats faced by mission-critical aviators, by bridging the gap between life-saving technology and the people who use it.
In our last post, we explored strategies to reduce the hidden mental load of incident response, the constant "friction" caused by countless micro-decisions, ambiguous radio reports, and the need to chase information. But even with a perfectly efficient, low-friction process, a traditional response is still sequential.
This "one-step-at-a-time" model is the next great bottleneck. A crew must still arrive before they can Orient. A logistics team must still receive a request before they can Act. Because the OODA loop is fractal, a commander's high-level loop is forced to wait for these nested loops to complete in sequence. The problem is, while the team is stuck in this process, the incident is escalating in parallel.
This post explores the powerful principles that finally break this sequential model and solve the problem of time
The first major problem created by a sequential model is the individual sequential bottleneck. A traditional, one-step-at-a-time OODA loop forces dangerous delays between its stages. The most obvious example is a crew's Act phase (driving to the scene) being completely decoupled from the live Observe and Orient phases of the incident itself.
This forced delay is a critical threat. It creates two failure modes on arrival:
These failure modes are all symptoms of a sequential process. The solution is to enable Concurrency—the ability to overlap OODA stages and drastically reduce the loop's total time.
A Common Operational Picture (COP) is the engine that makes this possible. Instead of relying on a static brief, it "pushes" the live, evolving ground truth to the crew in their vehicle. This couples their "blind" Act phase (driving) with a live Observe phase. They can see the incident unfolding in real-time—watching icons move, seeing hazard areas drawn, and receiving updates. This allows them to Orient and re-orient continuously while still en route, ensuring their final Orientation is current.
This overlap directly neutralises the threats of both inappropriate action and situational shock on arrival, saving time and reducing risk.
The second sequential bottleneck is created by the OODA loop's fractal nature. A high-level loop (like a commander's) is forced to wait for a nested, lower-level loop (like a frontline crew's) to complete its own cycle before it can even begin its next observation. This tethers the entire team's tempo to a rigid, one-at-a-time chain of dependencies.
This forced waiting creates a critical failure mode: the "reactive scramble." A support team (like logistics or a specialised unit) sits idle, forced to wait for a frontline crew to run their entire OODA loop to identify a need and send a radio request. Only then can the support team begin its OODA loop from scratch, guaranteeing a critical delay.
This problem is solved by Asynchronicity: the ability for these different fractal loops to run in parallel. A Common Operational Picture enables this by allowing the support team to Observe the frontline team's Act phase in real-time (their position, their status, their resource levels). This allows the support team to run their own Observe and Orient loops concurrently. They can anticipate a need (like a low air supply) and begin their own Act phase, preparing a resupply, before the frontline team has even made the request.
This breaks the sequential dependency, collapses the timeline, and ensures the supporting action is appropriate because it was based on calm orientation, not a rushed reaction.
These two principles, Concurrency and Asynchronicity, represent a fundamental shift in incident response. They are the specific solutions to the sequential bottlenecks that throttle a team's tempo. Concurrency solves the individual problem, ensuring responders arrive at the critical moment oriented and ready to act. Asynchronicity solves the team problem, breaking the reactive chain of dependencies and allowing the entire team to think and act in parallel.
Together, they are the key to moving a response from a slow, one-step-at-a-time process to a fast, collaborative, and proactive operation. But this isn't just a minor efficiency gain. In our final post, we will explore the massive compounding advantage this new way of working creates, and how it's the ultimate key to winning the margins and breaking an incident's chain reaction.