When Software Factories Build Factories Instead of Software
The Kessel Run PRIME RFI
A few weeks ago, Kessel Run released its PRIME RFI on Sam.gov. There has been a lot of buzz about this both leading up to the release and since. After reading through the requirements, I can’t help but feel we’re watching a software factory transform back into the very acquisition model it was designed to disrupt.
The Disappointing Reality
I found it disappointing when I began to read through the requirements. For starters, the RFI reads like an old school major acquisition rather than a call for industry feedback on the future of Air Force software delivery.
Take this example: “The vendor shall provision and support all specified hardware assets required for project operations.”
This at first sounds like harmless government acquisition language, but it reads less like software-as-a-servie and more like hardware-as-a-line-item. The document contains 195 “shall” statements, complete with rationale that hark back to my days as a systems engineering doing requirements traceability in DOORS.
Remember:
How We Got Here
“The Kessel Run” is a nod to Hans Solo and his Millennium Falcom being able to complete a smuggling route extremely close to a black hole cluster, bending the space-time continuum, making the journey in under 12 parsecs.
The metaphor was perfect: bend the rules, compress time, deliver the impossible.
The Kessel Run Software Factory associated with Hanscom AFB in Massachusetts was created to move software through the pipeline to production faster than ever before. It became the poster child for what could be a new way of delivering software in the DoD.
I spoke with Bryon Kroger earlier this year about Kessel Run when I was writing “Breaking the Sabotage Cycle” for Gene Kim’s IT Revolution Leadership Journal. He mentioned:
When Kessel Run started, it focused entirely on mission software — building above the value line, buying everything below it. That focus produced the first operational apps in under four months.
But somewhere along the way, the mission blurred. The factory started building factories, platforms, and infrastructure and not outcomes.
This summer’s Kessel Run post-mortem revealed similar themes. As Bryon calls out in his recent Defense Scoop article, these organizations slipped into “Innovation Theater.” In other words, they were performing the rituals of innovation without delivering the results. The outcomes.
Reading Between the Lines of the PRIME RFI
All organizations go through cycles of success and then change. Success begets success and then it grows, both in its funding and its demands. And with growth comes new ways of needing to do things. As someone who came from the industry side of the Defense Industrial Base, producing and transforming software, I understand how difficult it can be to manage success and maintain control over a growing organization.
But the PRIME RFI screams JCIDS, even through the Software Acquisition Pathway was supposed to kill that very approach. Just last month, Breaking Defense reported the JCIDS was being reformed, if not eliminated, yet here we are with requirements that would make a 1990s acquisition professional feel right at home.
If Kessel Run was truly following the agile processes identified in the Software Acquisition Pathway, there would be feedback on a Capability Needs Statement focused on outcomes, not infrastructure requirements.
I’m not sure what operator may be thinking, “Man, I hope someone acquires the infrastructure for the application I hope to use someday.”
That would be like going to the Apple Store with a list of requirements that include: “The vendor shall acquire the hardware necessary to create a phone capable of sending and receiving calls.” Apple doesn’t sell you infrastructure, they sell you outcomes.
Why this Matters
While “Innovation Theater” is harmful, dressing up JCIDS and calling it “Agile” is equally destructive. The Capability Needs Statement is meant to open the conversation with end users to say, “I need something that helps me do my job better, faster, more effectively.” It’s not meant to prescribe the solution.
The tragedy here isn’t just that Kessel Run has lost its way, it’s that its transformation back into traditional acquisition sends a chilling message to every other software factory and innovation hub in the DoW: Eventually, the bureaucracy wins.
The Path Forward: Three Hard Truths
1. Measure Mission Impact, Not Infrastructure
Stop counting servers, platforms, and pipelines. Start counting missions enabled, decisions accelerated, and lives saved. If you can’t trace your work directly to a warfighter or operator outcome, you’re building the wrong thing.
2. Kill the Committees, Empower the Teams
As I wrote the “Breaking the Sabotage Cycle,” we’re following the 1944 OSS sabotage manual to the letter: forming committees, demanding perfect paperwork, and advocating caution. The teams closest to the mission know what they need. Let them build it.
3. Accept that Some Things Must Die (Kill Your Pretties)
The hardest truth is that sometimes the most innovative thing an organization can do is recognize when it’s become the problem it was meant to solve. If Kessel Run can’t return to its mission-first roots, perhaps it’s time to sunset it and let something new emerge.
A Final Thought
The original Kessel Run was about taking risks, breaking rules, and achieving the impossible. Han Solo didn’t file 195 “shall” statements before making his run. He didn’t provision infrastructure (he wasn’t even that positive that the Millennium Falcon would survive). He delivered an outcome.
I’m not sure that the Air Force needs another traditional acquisition vehicle dressed in agile clothing. It needs software capabilities that helps the organization win. If the PRIME RFI represents Kessel Run’s future, then we’re not watching a software factory evolve, we’re watching it fossilize.
The question isn’t whether Kessel Run can provision infrastructure, it’s whether it can still deliver the impossible.
But here’s the thing about the defense acquisition community: We’re remarkably good at proving doubters wrong when we remember why we started. The original Kessel Run team didn’t set out to build a factory, they set out to solve problems.
Maybe it’s time to remember that.