Real success starts with mission outcomes: the human or system behaviors that produce mission impact. While every government acquisition strategy sets out to accomplish mission impact, the reality is that most federal contracts measure success by resources, activities, and outputs in the form of contract deliverables. In the govtech community, we’re at a time where we can push for speed and drive towards doctrine designed for mission command.
Mission command pairs centralized intent with decentralized execution to achieve outcomes. It rests on shared context and trust, where commanders set the intent, and the teams closest to the problem decide how to meet it. The military already trusts this model for its elite operators, and high-performing software development teams deserve the same trust. Give a team the mission and let them build the right software with the users who depend on it, without routing every decision back through the enterprise for months of review.
But layering decentralized execution onto an unchanged command structure isn’t enough. Policy has to clear the way for defense organizations to use accelerated delivery architectures and tools built on end-user feedback, which lowers risk and improves mission outcomes.
Speed Doesn’t Create Risk. It Mitigates It.
Warfighters’ needs evolve with the pace of the mission, but too often they’re stuck waiting months, sometimes the better part of a year, for software that’s outdated by the time it arrives. Waiting is its own risk.
When software releases are constrained to quarterly, or twice a year, untested changes pile up. So, when something finally breaks, it breaks big, and tracing it back through everything that changed keeps the new capabilities out of operators’ hands even longer.
Many organizations still believe longer production cycles mean better security. But frequent, smaller releases shorten the time it takes to detect and fix a break. Teams that ship weekly resolve small issues as part of the standard workflow, rather than letting them stack into rare, high-stakes events that halt the mission.
Continuous delivery builds resilience and confidence by building a system and team designed to absorb and correct risks without missing a step.
Reducing the Delivery Gap Between Users and Providers
Faster, safer software delivery still falls short of operational success unless you design it for the intended domain with the people using it. Software has to be intuitive and fit how people actually work, especially during stressful operations. Plenty of warfighters still enter mission-critical data into interfaces that look like Windows 95, running on legacy backends most engineers today have never seen.
The disconnect starts with the layers of functional representation between the users and the people building their software. Requirements development falls to headquarters staff, often former operators now removed from daily, mission-facing work. They aren’t the problem; they’re doing their job inside a flawed system design. Every layer between user and provider creates drift between what a program office is required to deliver and what would actually move the mission.
An Opportunity to Catch Up
A 2025 Pentagon memo directed the department to acquire and field software faster. For the first time, the guidance gives leaders explicit policy to prioritize speed over cost. Leaders who take that as broad license to act, rather than waiting for explicit permission, are the ones moving mission capability forward and reducing mission risk
These conversations take center stage at Prodacity 2026, where leaders across government and industry make the case for autonomy within clear limits over tightly controlled delivery. As mission complexity grows, doctrine and delivery have to move together.
This shift extends the software factory movement that started with Kessel Run in 2017, which pushed DoD Instruction 5000.87 into existence and established software as something you buy and field differently from a jet or a ship. Governance and policy are matching the speed-to-outcomes case that movement proved, and that progress is real.
Outcomes-based contracting turns this into practice. The most forward-leaning acquisition leaders now write the mission results they expect straight into the contract. When a team can put a mission outcome in front of users in months, not years, a growth board can fund the next capability because the data shows it will move the mission, not because a requirement locked it in a year ago.
More work remains. The system still incentivizes procurement offices to spend their budget and sign clean contracts, without mission impact top of mind. That change will be the hardest. Shifting that mission focus from the budget to outcomes must happen program by program, and it means understanding the mission metrics and evaluating them more often through growth boards and metered funding. It is more work, but it ties the incentives to improving the operational mission for warfighters.
The author, Max Reele, is the VP of Delivery at Rise8. A recently retired U.S. Air Force officer, Max has over two decades of experience in government technology delivery, including leadership roles at the Defense Innovation Unit, as a Materiel Leader at Kessel Run, and as a founder of the BESPIN Software Factory.