The Pilot Trap: Why Most Government Innovation Never Ships and How to Fix It
By Bryon Kroger, Founder & CEO, Rise8
Across government, agencies enthusiastically launch innovation labs, software factories, AI task forces, and modernization initiatives. Many generate headlines. Some even produce impressive demos. But very few make the leap from pilot to production to drive mission impact.
The main culprits? An abundance of bureaucracy and modernization efforts optimized for legacy processes instead of outcomes.
I learned this lesson firsthand when I got assigned to Air Force Lifecycle Management Center, and spent every day fighting it as I stood up and scaled Kessel Run, the U.S. Air Force’s software factory. We were trying to solve real operational problems for Warfighters using modern software delivery practices. What became immediately obvious was that the hardest part wasn’t building software, but navigating an ecosystem designed to prevent rapid deployment and direct user feedback.
That type of ecosystem creates what I call the “pilot trap.”
A team receives funding to experiment. They build a prototype. Stakeholders praise the innovation. Shiny slide decks present metrics. Maybe there’s even a successful demo day.
But somewhere between the prototype and production, momentum dies. The feedback loops slow, governance layers multiply, and delivery timelines stretch from days to months, sometimes years.
The pilot becomes another stranded artifact of a system that rewards activity over impact. The once promising concept suffers the same fate as too many other government software programs: gone before it sees the light of day.
Two things drive it, and you can fix both.
Bureaucracy Slows Delivery to a Crawl
Over decades, agencies have accumulated layers of oversight, governance, reporting structures, and procedural safeguards. Individually, many of these processes appear reasonable. Collectively, they create a nearly impenetrable software delivery environment, one where even small changes can take months to approve and deploy.
Modern software development depends on speed, iteration, and rapid feedback, while legacy bureaucratic systems optimize for control and process. This mismatch sits at the center of digital transformation.
The result is that many innovation programs get trapped in procedural quicksand before they ever reach operational scale.
I experienced this after transitioning from intelligence operations into acquisitions and helping launch Kessel Run. The technical challenges were rarely the hardest part. The real challenge was establishing continuous software delivery inside an ecosystem built around sequential approvals and risk avoidance.
The system wasn’t built for the Department of War’s desire to speed software delivery. And that same system is still in place.
Access to Users is Limited or Non-existent
Even software that makes it out of the pilot phase is often doomed once deployed because the people who build solutions are often separated from the people using them. Contractors and developers receive requirements through multiple layers of intermediaries, including committees, oversight offices, acquisition teams, and proxy users who may be far removed from operational reality.
As a result, teams design for alignment with those intermediaries instead of for the operator. Added features satisfy governance bodies and requirements expand to accommodate competing interests until the product is solving for consensus over usability.
I watched what losing that user connection costs. At Kessel Run, I dedicated a large part of our budget to putting our developers and product managers on site with operators, sitting next to the people who would actually use the software. After I left, the various stakeholders decided the travel budget was too high and cut it. That severed the connection with the users. The user-centered design we had built our reputation on collapsed because you cannot design for people you never see.
Designing for consensus instead of the operator is one of the core reasons so many pilots never reach production. The pilot succeeds in a controlled environment with limited expectations and manageable scrutiny. Once a program starts to scale, layers of oversight and competing priorities accumulate around it. The product slowly shifts away from solving user problems and toward satisfying institutional processes, and eventually it fails.
Continuous Delivery is the Key to Solving the Pilot Trap
Continuous software delivery offers a way out of the pilot trap. It shortens the distance between an idea and operational feedback, letting teams validate assumptions in real environments rather than debating hypotheticals in conference rooms.
When deployments happen multiple times per day instead of once every few months, feedback loops accelerate. Teams stop optimizing for approvals and start optimizing for outcomes. Risk gets smaller and easier to manage because changes are incremental.
Most importantly, continuous delivery puts teams back in proximity to the mission. Continuously shipping software only creates value if teams are learning directly from the people using the system. Otherwise, you just produce bad software faster.
The best software teams sit with users, watch them work in their real environment, then iterate on what they see. The closer teams stay to users, the smoother delivery gets because decisions are grounded in operational reality instead of assumptions.
Success Beyond the Pilot Phase
Getting to production isn’t the finish line. The real measure is what happens after deployment. Did users complete workflows faster? Did the software reduce their cognitive load and give them a real mission advantage? Did decision-making improve? Answering these questions tells you whether a capability is producing mission outcomes or adding another layer of complexity to an already overloaded system.
The way I measure this is net value release. If a change provides net value to the mission, ship it. That sounds obvious, but I have watched people refuse to release software that cut an operator’s workflow by 80 percent because it added one manual step that didn’t meet some checklist definition of “done.” Net value to the mission is the bar. Not process compliance.
And here is the part most modernization efforts get backwards: you don’t fix this by deciding to change the culture. You change behavior first. Establish continuous delivery, get teams shipping to real users, and the attitudes and the culture follow. Try it the other way around and nothing moves.
Our flagship education event, Prodacity, is built around this shift. It exists to have honest conversations about what it actually takes to ship software into production inside complex government environments.
Getting out of the pilot trap is just step one. What we ship, and whether it drives mission impact when it matters most, will decide the future of government modernization.
RESOURCES:
Rise8: https://www.rise8.us/
Prodacity 2026: https://www.rise8.us/prodacity/about