The Fighter Pilot's Guide to Software Strategy
AI companies are operating in arguably the most hotly contested market in human history. Earth shattering venture rounds incenting and empowering the brightest minds in the world in a winner take most (if not all!) race to the singularity. Amidst this battlefield, I find my thoughts returning to a little known fighter pilot from Pennsylvania who's contributions to strategy have come to rival those of Napoleon and Sun Tzu.
Colonel John Boyd.
If you've never heard of him, you're not alone. Today however, his work is taught at some of the top business schools and law schools, let alone military academies. His strategic frameworks—originally designed for aerial combat—have been adapted to everything from litigation to sports, to manufacturing. And they're exactly what we need in today's hyper-competitive software environment.
Don't Get Hosed
In a dogfight 30,000 feet above the ground, pulling multiple Gs and making split-second decisions, fighter pilots don't have time for committee meetings or perfect solutions. The situation is to fast paced, and too dangerous for careful and deliberate planning.
Sound familiar? That's the reality of building companies in 2025.
But here's the thing most founders get wrong: The winner isn't who makes the best decisions. It's who makes (and executes) the most non-lethal, non-catastrophic decisions the fastest.
This truth is often conveyed by the meme "you can just build things".
This isn't button-mashing your way to victory. It's about rapidly executing a series of relatively good moves without crashing into the ground. Let me break down how this applies to your codebase and your company.
The OODA Loop: Your Competitive Framework
Boyd's most famous contribution is the OODA loop—a decision cycle consisting of four elements:
- Observe
- Orient
- Decide
- Act
At first glance, this might seem trivial – it basically represents what we all do naturally all day every day. However, the framework's power lies in understanding that whoever can cycle through this loop faster than their opponents gains an insurmountable advantage. By optimizing each of these steps in your business, you set yourself up for victory.
Observe: Are You Flying Blind?
For a fighter pilot, observation comes through their eyes, ears, and instruments. For your software company, it might include:
- Telemetry from your production systems
- User behavior metrics
- Customer feedback loops
- Market intelligence
Right now, many of us are flying blind. We have eyes and ears, but our heads-up display isn't properly configured. We're missing crucial data or, worse, drowning in too much of the wrong data.
The first step in outmaneuvering your competition is building robust observability. Do you have dashboards that show you what matters? Can you see in real-time how your systems are performing? Are you capturing the right user behaviors?
Without this, you're a pilot with malfunctioning instruments.
Orient: Making Sense of the Chaos
Observation is just data collection. Orientation is where you turn that data into understanding.
In software, this means:
- Interpreting metrics dashboards
- Contextualizing user feedback
- Understanding competitive moves
- Processing market trends
This is where most engineering organizations fail. They collect terabytes of logs but lack the processes to extract meaningful insights. They have NPS scores but no systematic way to understand the "why" behind customer satisfaction or dissatisfaction.
Orientation isn't just about having data—it's about having frameworks to transform that data into situational awareness.
Decide: Disagree and Commit
Decision-making in fast-paced environments isn't about consensus. It's about velocity.
Here's where "disagree and commit" (popularized by Amazon) becomes essential. You don't need everyone to agree—you need everyone to move forward once a decision is made, and you need to make it quickly.
Some principles I've found effective:
- Time-box decisions
- Define clear decision owners
- Create frameworks for when to escalate vs. decide locally
- Accept that some decisions will be wrong and build processes to detect and correct them quickly
Remember: a good decision now is better than a perfect decision later.
Act: Your Engineering Maneuverability
This is where the rubber meets the road. How quickly can your team execute on decisions?
The speed of your action phase depends on:
- The quality of your codebase
- Your CI/CD pipeline
- Deployment processes
- Team communication patterns
- Architecture decisions
If your competitor can ship a feature in two days that takes you two months, you're already dead—you just don't know it yet.
Energy Maneuverability Theory: Why Tech Debt Matters
During the Cold War, Boyd was troubled by evidence suggesting Soviet MiGs were outperforming American jets. Using thermodynamics, he mathematically proved this was true and developed Energy Maneuverability (EM) Theory—a framework that revolutionized aircraft design and directly led to the F-15 and F-16 fighter jet programs.
EM Theory is about how quickly aircraft can change energy states in varying conditions. For software, it's about how quickly your codebase can adapt to changing requirements.
Let me give you a concrete example: In the early internet days, YC founder Paul Graham's company Viaweb dominated the online store builder market, eventually selling to Yahoo for $49 million. In his essay "Beating the Averages," Graham attributes their success to the use of Lisp.
He's both right and wrong.
It wasn't Lisp itself that gave them the advantage. Instead It was the highly composable patterns idiomatic to Lisp that gave them their edge. This philosophy of building systems from small, simple, highly composable pieces that can be combined recursively, has roots in the East Coast software scene, and is perhaps best exemplified by UNIX. Graham's competitors weren't just hindered by their language choice of Java but by the brittle, unmaneuverable code architecture that accompanies its code philosophy.
As Graham notes in his essay "Beating the Averages," their development cycle was "so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release." Their competitors must have felt like Viaweb had some kind of secret weapon—they were simply able to develop software faster than anyone thought possible.
Applying This To Your Codebase
Composability is the key to maneuverability. Here's what that means in practice:
- Modular architecture: Components that can be swapped, modified, or upgraded independently
- Clean interfaces: Clear boundaries between systems
- Functional patterns: Minimizing side effects and state
- Domain-driven design: Aligning code structures with business reality
Building for composability takes more time upfront. It requires more thought and discipline. But it gives your code a longer shelf life and allows for rapid adaptation as requirements change.
How to Win
Here's what winning looks like in practice:
- Observe: Implement comprehensive telemetry and feedback loops
- Orient: Build systems to derive actionable insights from your data
- Decide: Create lightweight decision-making processes that favor speed over consensus
- Act: Develop a highly composable codebase that can rapidly adapt to changing requirements
The team that cycles through this loop fastest—not perfectly, but fastest—will win even against competitors with 100x the resources.
Remember Colonel Boyd's wisdom: Victory doesn't belong to the biggest or strongest. It belongs to the most adaptable.
Are you building your software company like an F-22 or like a commercial airliner? One can turn on a dime at supersonic speeds. The other needs 20 minutes to change course.
In today's market, I know which one I'd rather be flying.
This blog was written by Andrin Foster, Head of Engineering at Cline.
Follow us @cline for more insights into the future of development.
