Five steps to build technology for the warfighter
Structural changes to enhance force adaptation
Software for the military has “Big R” Requirements and “little r” requirements.
Big R Requirements have traditionally been the guiding foundation for U.S. military software procurement until very recently. They are formal Requirements that any software must meet, written by program sponsors and program managers designed to align technology with mission needs. JTRS — the Army’s $17 billion failed attempt to create a universal radio — included mandated requirements that resulted in such technical complexity that the entire project collapsed.
Little r requirements, on the other hand, represent the actual users’ “jobs to be done.”
Program sponsors aren’t using technology, meaning Big R requirements are disconnected from the users of the technology, and building software without close user input is antithetical to modern software development best practices more-or-less perfected by the private sector. This is the crux of the principle-agent problem for ministries and departments of defense everywhere.
The Pentagon’s intent is good. When leadership says “We need a tool that will help our warfighters achieve X outcome,” these program managers write an aggressively detailed outline of what Requirements any tools must meet in order to achieve X.
Even well-intentioned processes can backfire, and in practice, the Pentagon’s traditional software procurement methodology is rife with issues. Specifically:
A static list of Requirements eliminates the possibility for iterative product development based on feedback from users.
The people who are procuring the technology are disconnected from the people using it.
The Big R Requirements-driven process focuses not on professionally solving warfighters’ problems, but on procuring technologies that align with a proscriptive solution. It’s a process optimized for procedural correctness, not product correctness.
The Department of War has made changes in the past few months that are nominally positive.
They’ve done away with the Joint Capabilities Integration and Development System (JCIDS) process. Services can now determine their own requirements to solve the problems its servicemembers face.
A new year-of funding tool — meaning that when technology is needed, it can be fielded and deployed — is also good.
The Army’s FUZE program, which will enable the Army to “invest small amounts of money in buying existing technology and quickly unload what doesn’t work, rather than spending years developing the perfect product only to find it obsolete once it’s ready for fielding.”
The Pentagon’s proclamation about Portfolio Acquisition Executives (PAEs), which will consolidate portfolios by reorganizing existing Program Executive Officers (PEOs) should give all military branches FUZE-like flexibility. These PAEs have been told to tie “compensation to capability delivery time, competition, and mission outcomes.”
Secretary Hegseth has mandated the Software Acquisition Pathway (SWP) as “the preferred pathway for all software development components of business and weapons systems,” meaning the Department should align military software procurement with industry best practices by ensuring users are integral to product development.
The Pentagon wants to operate like the private sector: Rather than starting with a laundry list of Big R Requirements, modern software companies build an MVP, or minimum viable product. The MVP is the barest-of-bones software tool to address a problem users have. To improve their software, they deploy it with users, collecting their feedback to make iterative improvements based on real-world applications of technology.
User feedback is the little r requirements that gets you to product correctness.
This approach — sometimes called Agile, but better understood as user-centered and problem-driven development — keeps the people who use the technology at the heart of software build and deployment. It works because it ensures technology features and functionality are closely aligned with the people who need to use it.
However, Agile is a means to an end. The process of ensuring technology is built and iterated upon based on user needs, requirements, and feedback means the technology is always adapting as user needs change.
For commercial technology vendors, software adaptability drives business health. For the U.S. military, force and technological adaptability is life-or-death.
One need look no further than Ukraine to see the pace at which the battlespace changes, in large part because of the introduction of new technologies in war. If a force cannot adapt to meet the changing nature of conflict, if the technology supporting that force is not flexible, lives will be lost. Ultimately, how the Department of War approaches building, procuring, deploying, and iterating on technology has a direct impact on the efficacy of the warfighter.
This measure vs counter-measure dynamic is not new — tank armor led to shape charges and TOW missile arrays, which led to explosive reactive armor, which led to tandem-charge warheads, top-attack, and electronic counter measures. What is new is that other countries have proven capable of adapting faster than we can, and that is a function of the processes and structures of defense organizations.
I know this firsthand; I served in the U.S. Army’s Special Forces. I also know there is a veritable chasm between a leader or a Department articulating policy and that policy being implemented.
With that in mind, here are five concrete recommendations for the Department of War to apply user-centered software development to military operations.
Normalize user collaboration: Contract language should specify that vendors must make the user part of the build, not just the test. Every software program should require documented feedback sessions with intended end users.
Flexible funding from the legislature: With the creation of FUZE and PAEs, funding flexibility is clearly a priority. However, Congress must pre-authorize funding pools to allow each branch of the military to experiment with technology and units need to be culturally empowered to take advantage of Departmental reorganization. Bottom’s up and top down.
(Re-)Decentralize purchasing power: Efforts to introduce more distributed purchasing power rapidly become centralized — the USAF’s Squadron Innovation Fund, for example, was originally designed to give commanders and Airmen direct control over funding only for it to consolidate into centralized marketplaces. Each command should have the ability to wield a flexible budget to procure, not simply identify, technology that meets their needs — and it needs to stay that way. SOCEUR has different needs than AFMC. They should be able to buy what’s best for their users.
Socialize flexible security frameworks: Many highly regulated industries set high-level standards for safety and security and empower industry to meet those standards in different ways. By providing heuristics — is it a U.S. owned company, does software encrypt data in transit, do systems use multi-factor authentication — the Pentagon can effectively define what “good” looks like without stifling innovation with overly proscriptive guidance on the “how.”
Measure success differently: Compliance-based metrics need to go. We should measure success by impact on the mission and the user, tying vendor incentives to user satisfaction, technology adoption rates, and efficiency at solving user programs.
Remember this simple, immutable truth: The U.S. military procures technology for the warfighter.
Warfighters don’t experience much risk if a piece of technology they like is noncompliant with programmatic processes and Big R requirements. A deployed technology that fails to meet warfighter needs represents fundamental risk: it’s life and death.
The Pentagon, then, must fully align its technology procurement and deployment process with the needs of the warfighter; empower groups of individuals lower down the chain of command to make meaningful decisions, and; equip them with the tools they need to follow through on their decisions, like flexible funding and security heuristics.
When technology is closer to the needs of the warfighter, the individual is safer, more lethal, and more ready. Anything less should be unacceptable to all of us.