The recent article about Kessel Run’s transition to a new government-led, vendor-managed model raises important questions about the future of defense software development. As one of Kessel Run’s co-founders, I want to set the record straight on what I believe worked, what didn’t, and why it’s important to put differences aside and focus on solutions to ensure its continued success.
Kessel Run Was Always About Outcomes
What we know as Kessel Run today came together to solve a specific problem: replace the Air Operations Center weapon system. For many of us, our “why” was always about more than building software. We observed that outdated software limited military effectiveness, sometimes with life-or-death consequences. What we ultimately built was a new way for the Air Force to deliver and sustain software, continuously. That required changing how we handled people, process, and technology. Some suggest this current transition to contractor-led development is a rejection of the Kessel Run model. That misses the point. Kessel Run was never about a specific staffing model or methodology. Instead, it was about achieving outcomes with culture-changing processes.
The hybrid government-contractor teams that defined its early days were necessary because the Air Force lacked internal expertise to lead modern software development—something many government agencies and military operations continue to struggle with today. Pairing one-to-one with people on the culture, process, and tech resulted in integrated systems because everyone was working with the same culture, using the same processes, on the same tech stacks.
As we scaled, we knew we’d need to evolve toward a model that allowed vendors to take more of the execution responsibility. But that shift requires government contracting offices sufficiently enabled to write the contracts and manage the work.
What’s Changing and What Needs to Stay the Same
I’ve long supported shifting to vendor-executed, outcomes-based contracts. That was always part of the acquisition strategy. I know because I wrote it. I respect Kessel Run’s current leadership for making the pivot. The key now is executing this transition well.
The real challenge is not the model, it’s the bureaucracy. Slow, entrenched processes have long hindered defense software development. The infighting over different approaches is merely a distraction.
A major concern is whether the Air Force has invested enough in developing its people. Empowerment without enablement is just neglect. This applies to software development and procurement. If the acquisition workforce isn’t equipped to write the contracts, run effective competitions, and manage execution, shifting responsibility to vendors will not fix the problem. It will only mask it until contracts come up for recompete and ultimately, cultural enablement is lost.
Writing agile-friendly contracts, getting the right vendors to bid for them, overseeing development with technical competence, and maintaining a culture of continuous delivery are critical. If those pieces aren’t in place, this transition risks becoming a return to the old way of doing business, where rigid requirements and slow procurement cycles lead to costly, outdated, and ineffective software.
Additionally, cost-cutting measures like reducing blended labor rates are alarming. Kessel Run’s technical challenges aren’t simpler today than six years ago. Expecting lower-cost labor to deliver the same high-quality results is unrealistic. If “best value” contract awards over emphasize cost or cannot distinguish real technical merit, then these types of acquisition strategies will fail.
The Real Risk
Another misconception is that Kessel Run was about organic software development within the Air Force. Early on, we pitched the idea of building a “squadron of coders,” but high turnover due to the nature of military assignments made it impossible to build a sustainable in-house development team. Less than one year in, we had already moved toward vendor contracts for talent to fill out government-led teams. The approach ensured continuity while maintaining a tight feedback loop with users for inherently government decisions.
That tight feedback loop is the real “secret sauce” of Kessel Run. User-centered design only works if real software is continuously delivered to real users in real production environments. But that’s impossible without a solid application platform with continuous Authorization to Operate (cATO). The deterioration of RMF-focused cATO across DoD in recent years is a major concern. So is the boondoggle of GOTS application platforms that became a huge distraction for DoD “software factories”. If Kessel Run loses its ability to deliver updates to the field on demand, it will become just another slow-moving government program. The decision to use a COTS platform and a path to prod enabled by continuous RMF to achieve continuous delivery was the right one, and any deviation is a huge risk.
Focus on Real Solutions
Kessel Run’s mission was never about a specific organizational structure. It has always been about ensuring warfighters have the best software when and where their critical missions demand. That mission must continue—regardless of who is writing the code.
For any software factory’s government-led, contractor-managed strategy to succeed, there are a few key considerations:
- Government acquisition leaders must be enabled to manage software development. This means writing contracts focused on outcomes and ensuring program managers understand modern development practices–because you can’t manage what you don’t understand.
- The Air Force must continue to invest in culture as an integrator. Kessel Run’s success was built on rapid learning and then doing what works instead of defaulting to waterfall. Future success depends on the cultural enablement built over the past eight years. Leaders can’t effectively lead software teams if they’ve never successfully delivered software just as hacking bureaucracy is impossible without understanding how it works.
- Continuous delivery must remain a priority. If software updates can’t reach the field rapidly, the agility that made organizations like Kessel Run successful will disappear. Ongoing authorization is not a shortcut; it requires continuous application of the structured but adaptable NIST RMF for high-quality software with reduced risk.
- The government must think beyond this contract cycle. The first vendor under this model may do well, particularly if it employs people who helped start and scale the program. The incumbent at Kessel Run, for instance, unleashed extremely competent people who have up to eight years of Kessel Run context and lessons learned. But in the absence of personnel who understand the process and tech that made Kessel Run successful, the entire effort would, in my opinion, unravel. What if they lose the follow on to a lower bidder with nice writing? I worry that it is not an acquisition strategy that’s winning right now, just unleashed people. Very specific people. Which is to say: people matter. So does being able to hold them accountable. Long-term sustainability that accounts for that must be built into the acquisition strategy now.
Fight the Bureaucracy, Not Each Other
Kessel Run has accomplished incredible things, even while fighting against bureaucratic resistance. Even during challenging times, I’d still put it up against any traditional program. And I remain optimistic that they can deliver outcomes and mission impact.
The real fight isn’t between different software development approaches or personnel models. It’s against the slow, outdated bureaucratic processes that make all of this harder than it needs to be. Instead of debating whether we should move to vendor-executed models, we should be focused on making them work. The old way wasn’t working and as the co-founder who wrote the acquisition strategy, I can tell you, it was never meant to be “The Way”. The outcomes were all that ever mattered. Whatever the best way to achieve them is… this is the way.
Iterate. Improve. Move forward. That’s how Kessel Run was built and it’s the only way to ensure future success in the ecosystem.
