A top-fuel dragster is faster than a Ferrari.
Until the road turns.
That is the mistake a lot of engineering organizations make with speed. They optimize for straight-line delivery and call it velocity. More tickets. More features. More roadmap items checked off. More output moving through the machine. The industry calls that a feature factory.
Then the market changes, the architecture needs to evolve, a key customer demands something unexpected, or the team hits a system constraint.
Suddenly, the fast team cannot turn.
It was never fast.
It was fragile.
Boyd Measured the Complicated Thing
Before John Boyd became famous for OODA, he worked with mathematician Thomas Christie on Energy-Maneuverability theory. The idea was not just that some fighter aircraft felt more agile than others. The idea was that maneuverability could be measured.
That matters.
Boyd and Christie took something complicated, aerial combat performance, and turned it into a quantitative model. The model related velocity, thrust, drag, weight, altitude, turn rate, and other aircraft characteristics into a way of comparing what a fighter could actually do under specific conditions.
That was the genius. Not vibes. Not preference. Not pilot folklore. Measurement.
The same instinct matters in engineering leadership. I track points per developer-day because I want a signal for team efficiency. It is not perfect. No metric is. But it gives me a way to see whether the system is improving, stalling, or degrading. I use code scorecards for the same reason. They turn fuzzy conversations about code quality into something we can inspect, compare, and improve.
DORA metrics deserve credit for the same move. Deployment frequency, lead time for changes, change failure rate, and time to restore service made software delivery performance visible in a way executives and engineering leaders could discuss. They do not explain everything. They were never supposed to. They give you a lens on a complicated system.
If you refuse to measure complicated things, you do not make them more human. You make them easier to ignore.
Engineering leaders do not need perfect metrics. They need useful ones. Boyd did not reduce air combat to a single spreadsheet and call the job done. He created a way to reason about tradeoffs. That is the point. The metric is not the truth. The metric is a lens that makes the trade visible.
And the trade every engineering leader needs to see is this one: Are you buying speed by spending maneuverability?
Speed Is Not Maneuverability
A dragster is optimized for one thing: explosive straight-line acceleration. In that context, it is astonishing. The car is a monument to thrust, grip, and violence delivered in one direction. A Ferrari is not faster in that narrow sense. It is built for a different problem. It can accelerate, brake, turn, recover, and keep moving when the road changes shape. That is the distinction most velocity conversations miss. Velocity asks how fast the team is moving right now. Maneuverability asks how many good moves the team still has available.
Those are not the same question. A team can be fast in the dragster sense. It can burn through tickets, ship features, and make the roadmap look healthy. It can do all of that while losing the ability to respond to anything that does not fit the current path.
The codebase gets harder to change. The tests get thinner around the areas that matter. Knowledge concentrates around a few people. The release process becomes nervous. Architecture decisions get deferred until they become invisible constraints. Every sprint delivers output, and every sprint quietly removes options. From the outside, that team looks fast. Inside the system, it is becoming less maneuverable. That distinction is not academic. It is the difference between a team that can respond to reality and a team that can only keep executing the plan it already had.
Feature Factories Burn Maneuverability
The feature factory is the organizational version of a dragster.
It is built to move work in one direction. Roadmap item enters. Ticket is created. Story is estimated. Developer implements. QA tests. Feature ships. Then the next feature enters the machine.
That can feel productive. It can even be productive for a while. The danger is that the feature factory treats engineering energy as if it is infinite. It keeps asking what can be squeezed into the sprint, what can be pulled forward, what can be shipped by the date, and what can be deferred until later. Later rarely comes, and technical debt is not just mess. It is spent maneuverability.
Sometimes that spending is correct. You ship the MVP. You defer the ideal abstraction. You hardcode the integration because the customer demo matters. You accept a rough edge because learning from the market is worth more than polish no one may need.
That is not failure. That is a trade.
The problem is not spending energy. The problem is spending energy every sprint and never rebuilding it. The feature factory keeps pulling maneuverability out of the system until the team can only move in the exact shape the codebase already allows.
I saw this explicitly at the healthcare SaaS provider. The team was delivering feature after feature. Every planning conversation was built around who was available for that sprint and how much work they had left to deliver the feature they were currently working on before starting on the next one. By the time I arrived, every feature was getting harder to implement because the technical debt had gone unpaid for too long.
Some of that debt was very concrete. The company had spent real energy on a MongoDB-to-PostgreSQL conversion, hit the difficult part, stopped before it was finished, and created a bridge application to move data between the two systems. That bridge became one of the most common sources of production issues. The organization spent energy and maneuverability on the migration, then never got the maneuverability back.
The reporting side had its own version of the same problem: incomplete data design and missing indexes allowed very large tables to grow in ways that made effective querying difficult, and in some cases brutal.
At my current employer, we had what looked like a small behavior change in a primary customer-facing application. A senior developer worked on it for a month and still could not fully deliver it. When I looked at the code, the problem became obvious: the behavior lived in more than 40 locations, with similar but not identical logic shaped by years of feature additions.
That is what lost maneuverability looks like. The feature factory had not produced one clean place to turn. It had produced 40 small steering inputs scattered across the system, each one slightly different, each one needing to be changed and tested.
Leadership sees the slowdown and asks for more velocity. That is how the trap closes. The team does not need more straight-line speed.
It needs to reclaim maneuverability.
Standards Preserve Options
This is where code standards and clean architecture earn their keep. Composition over inheritance is not academic purity. Dependency injection over inline instantiation is not pattern worship. Consistent boundaries, testable components, small interfaces, and clear conventions are not decorative clean-code rituals.
They preserve options.
When code is composed well, you can replace a part without rewriting the machine around it. When dependencies are injected, you can test behavior without dragging the whole system into the room. When boundaries are consistent, developers know where a change belongs. When standards are explicit, human and AI developers can follow them without reverse-engineering tribal knowledge from whatever pattern happened to be nearby.
That is maneuverability.
The same is true at the team level. You preserve maneuverability by not overcommitting every sprint. You preserve it by knowing actual capacity, not imaginary capacity. You preserve it by leaving room for support, review, incidents, learning, and the work that keeps future work possible.
This is why I care about points per developer-day. Not because story points are holy. They are not. I care because capacity is a real constraint. A team that does not understand its capacity will overcommit by default, and overcommitment is one of the fastest ways to burn maneuverability.
People talk about standards as if they are mostly about taste. They are not.
Good standards make the next move cheaper. Clean architecture makes more future moves available. Tests make decisions safer. Documentation keeps knowledge from becoming hostage to one person’s memory. Cross-training keeps staffing changes from becoming emergencies.
None of that is bureaucracy when it is aimed at preserving the ability to turn. It is stored energy.
Sometimes the Right Move Is to Climb
In an aircraft, altitude is stored energy. A pilot can trade it for speed later. That does not make climbing passive. It can be the move that keeps future moves available.
Engineering has the same pattern.
Sometimes the right move is not another feature. Sometimes the right move is to stabilize the platform, remediate technical debt, improve the deployment path, document the system, add test coverage around the dangerous area, or clean up the post-MVP shortcuts before they become permanent architecture.
That can look slow to a feature factory. It is not slow. It is climbing.
An aircraft high in the sky has potential energy and options. It can trade altitude for speed, dive, turn, recover, and choose from more moves. Close to the ground, the same aircraft has fewer options and less room to recover from a mistake.
Technical debt and broken processes push a team closer to the ground. The team can still move, but every move has less margin. Paying down debt, simplifying the path, and fixing the process are how the team climbs back up and regains maneuverability potential.
Post-MVP work is a perfect example. The MVP exists to learn. Once the learning happens, the next move is not always more scope. Often the next move is to harden what worked, remove what did not, and rebuild enough maneuverability for the next phase.
The same is true after a debt-heavy push. If the team spent energy to hit a meaningful date, acknowledge the trade and rebuild the energy. Pay down the principal. Shore up the foundation. Recover the ability to turn.
Feature factories hate this because it does not look like output. Mature engineering leadership understands that output is not the only asset. Optionality, capacity, trust, code clarity, deployment confidence, and the ability to say yes to a surprise without creating a fire are assets too.
You do not get those assets for free. You build them when you choose to climb.
The Leadership Test
Here is the question I would ask at the end of every sprint, every roadmap push, and every major technical decision:
After this work, does the team have more options or fewer?
If the answer is fewer, the next question is not whether the work was bad. Sometimes spending options is the right call. The next question is whether everyone understands the trade and whether there is a plan to recover.
That is the difference between intentional debt and organizational drift.
A healthy team can spend maneuverability for position and rebuild it afterward. An unhealthy team spends maneuverability without noticing, celebrates output, then struggles when every future change is increasingly expensive.
That is what the feature factory misses. It sees the feature that shipped. It does not see the pivot that became impossible.
So yes, measure velocity. Measure throughput. Measure points per developer-day if that helps you understand whether the delivery system is improving.
But do not stop there. Measure the shape of the code, support load, escaped defects, carried-over work, knowledge concentration, and whether features are getting easier or harder to deliver over time.
Those are maneuverability signals.
A team that can only go fast in one direction is not fast. It is fragile.
The goal is not to move either fast or slow, explicitly. The goal is to stay capable of the needed movement.
Receipts
- Energy-Maneuverability theory. John Boyd, Thomas Christie, and James Gibson’s declassified 1966 report, Energy-Maneuverability, modeled fighter aircraft performance by relating energy state and energy rate to operational maneuverability.
- Specific excess power. E-M theory commonly uses specific excess power, often expressed as
Ps = V((T-D)/W), where velocity, thrust, drag, and weight are related to an aircraft’s ability to gain or lose energy under a maneuver. The formula is summarized in the Energy-Maneuverability theory reference, which cites Boyd, Christie, and Gibson’s 1966 report. - The measurement lesson. The important engineering parallel is not the exact aircraft formula. It is Boyd and Christie’s move from subjective performance arguments to measurable tradeoffs.
- Feature-factory field note. At a healthcare SaaS provider, planning revolved around availability, remaining work, and the next feature in the queue. The team kept delivering, but unpaid technical debt made each new feature harder to implement by the time I arrived. Two concrete debt examples were an unfinished MongoDB-to-PostgreSQL migration that spent maneuverability without recovering it, and reporting tables whose incomplete design and missing indexes made effective querying difficult.
- Forty-location change. At my current employer, a seemingly small behavior change in a primary customer-facing application required touching more than 40 locations because similar logic had evolved in slightly different forms across multiple parts of the system. That is the concrete field example behind the maneuverability argument.
- Feature-factory inference. The claim that feature factories burn maneuverability is my management analogy, not an aircraft-design claim. The software parallel is that repeated output without recovery consumes future options in architecture, capacity, quality, and team knowledge.
- Related essays. This extends The Loop Is the Easy Part, Tech Debt Is a Choice, Not a Failure, The Disciplined Codebase, and Good Code Isn’t Taste. It’s Measurable..