The OODA Loop for Startup Engineering

· 6 min read
decision-making leadership startups strategy

I’ve written before about PDCA as a framework for systematic quality control. PDCA is great when you have time to plan carefully, run controlled experiments, and analyze results. But startups often don’t have that luxury. The market shifts, a competitor launches something, your biggest customer changes their requirements, and suddenly your carefully constructed plan is irrelevant.

For those situations, I’ve found a different framework more useful: John Boyd’s OODA loop.

What Is OODA?

OODA stands for Observe, Orient, Decide, Act. It was developed by Colonel John Boyd, a fighter pilot and military strategist who studied why some pilots consistently won dogfights even when they had inferior aircraft. His conclusion was that the winning pilots weren’t necessarily better at flying. They were faster at processing what was happening and adapting.

Boyd’s insight was that decision-making is a loop, and the speed of that loop matters as much as the quality of any individual decision. A good decision made quickly beats a perfect decision made slowly, because the situation changes while you’re deliberating.

The four stages:

Observe. Gather information about what’s happening right now. Not what you expected to happen. Not what your plan says should be happening. What is actually happening.

Orient. This is the critical step most people skip. Orientation is about making sense of what you observed through the lens of your experience, your mental models, and your understanding of the broader context. It’s where you update your worldview based on new information.

Decide. Choose a course of action based on your updated orientation. This doesn’t need to be the optimal choice. It needs to be a good enough choice made quickly.

Act. Execute the decision and immediately start observing the results, which feeds back into the loop.

The key difference from PDCA is speed and emphasis. PDCA optimizes for thoroughness. OODA optimizes for tempo. In a startup, tempo usually wins.

OODA in Practice: The Feature That Nobody Wanted

Let me give you a concrete example. A few years ago, I was leading a team at a startup and we’d spent three weeks building a reporting dashboard that our CS team said they desperately needed. Classic PDCA approach: we planned it carefully, built it incrementally, tested it thoroughly.

Then we shipped it and nobody used it.

Here’s what an OODA-driven approach would have looked like:

Observe. CS says customers want reporting. But what are customers actually doing? Pull the usage data. Talk to three customers directly. Look at support tickets. Don’t take the second-hand request at face value.

Orient. We would have discovered that customers didn’t want a dashboard. They wanted to export data to their own BI tools. The “reporting” request was being translated through a game of telephone between customers, CS, and product. Our mental model of what “reporting” meant didn’t match the customer’s mental model.

Decide. Build a CSV export button instead of a dashboard. It’s a fraction of the work and actually solves the problem.

Act. Ship the export, then immediately observe whether customers actually use it and whether it resolves the support tickets that motivated the request.

Total time: maybe three days instead of three weeks. And the outcome would have been better.

Applying OODA to Engineering Teams

Here’s how I’ve adapted OODA for engineering team operations:

Observe: Instrument Everything

You can’t observe what you don’t measure. For engineering teams, this means:

  • Usage data on everything you ship. Not just “is it working” but “is anyone using it.” If you ship a feature and nobody touches it for a week, that’s a signal.
  • Cycle time tracking. How long does it take from “we decided to do this” to “it’s in production”? If this number is growing, something is wrong.
  • Customer feedback loops that are as short as possible. The longer the delay between shipping and hearing feedback, the more stale your orientation becomes.

The common failure mode here is observing the wrong things. Vanity metrics, internal metrics that don’t connect to customer value, or metrics that lag so far behind reality that they’re useless for decision-making. If your key metric only updates monthly, your OODA loop can’t run faster than monthly.

Orient: Challenge Your Assumptions

This is the step that separates good teams from great ones. Orientation is about updating your mental model of the world. It requires intellectual honesty and a willingness to admit when your assumptions were wrong.

Some practices that help:

  • Pre-mortems before starting work. “Assume this project fails. Why did it fail?” This forces you to surface assumptions you didn’t know you were making.
  • Regular “what surprised us” retrospectives. Not “what went well, what went poorly” but specifically “what happened that we didn’t expect?” Surprises are where your mental model is wrong.
  • Cross-functional observation. Engineers should talk to customers. Product managers should read the code. Sales should see the usage data. Everyone has a different orientation, and combining them gives you a more accurate picture.

Decide: Bias Toward Reversible Decisions

Jeff Bezos talks about one-way doors vs. two-way doors. Most decisions in a startup are two-way doors: you can walk back through them if they don’t work out. For two-way door decisions, speed matters more than precision.

The practical implication: if a decision is easily reversible, make it fast and move on. Don’t schedule a meeting. Don’t write a design doc. Don’t wait for consensus. Decide and act, then observe the results.

Reserve your careful deliberation for the genuine one-way doors: major architecture choices, hiring decisions, pricing changes, and commitments to customers.

Act: Ship Small, Ship Often

The faster you act, the faster you get back to observing. This is why small, frequent deployments beat big, infrequent releases. Every deployment is an observation opportunity. Every feature flag is a chance to learn.

The antipattern is the “big bang” release where you spend months building in isolation and then ship everything at once. Your OODA loop is essentially paused during that entire build phase. You’re flying blind.

OODA vs. PDCA: When to Use Which

These frameworks aren’t competitors. They’re suited to different situations.

Use PDCA when:

  • The cost of failure is high (healthcare, finance, infrastructure)
  • You have established processes that need optimization
  • The environment is relatively stable
  • You need rigorous evidence before making changes

Use OODA when:

  • The environment is changing faster than you can plan
  • Speed of response matters more than perfection
  • You’re in a competitive situation where tempo is an advantage
  • The cost of inaction is higher than the cost of a wrong decision

Most startups need OODA most of the time. Most enterprises need PDCA most of the time. The tricky part is the transitions: knowing when your startup has matured enough to need more PDCA, or when your enterprise needs to adopt OODA thinking for a new initiative.

The Meta-Loop

A lot of fights are adversarial, so they can be more about making your opponent’s OODA loop slower. In a dogfight, you win by acting in ways that are confusing and unpredictable to the other pilot, forcing them to spend more time in the Orient phase while you’re already Acting.

In a startup context, this translates to competitive advantage through speed. If you can ship, learn, and adapt faster than your competitors, you’re effectively operating inside their decision loop. By the time they’ve analyzed the market and built their response, you’ve already moved on to the next iteration.