• Back


How the Pentagon Can Innovate By Failing And Scaling

In his interim national security strategy, President Biden promised to “shift our emphasis from unneeded legacy platforms and weapons systems to free up resources for investments in the cutting-edge technologies and capabilities that will determine our military and national security advantage in the future. We will streamline the processes for developing, testing, acquiring, deploying, and securing these technologies.”  

In his first policy speech, Secretary of Defense Lloyd Austin sketched a near-term future where " the right mix of technology, operational concepts and capabilities” will “create advantages for us and dilemmas for them” -- them being pacing, like China. The words sound familiar. We’ve begun another cycle in the decades-long quest to turn the Pentagon into the engine of technological change and advancement the way it once was.

Would-be defense innovators need a “hearts and minds” strategy to win over the building, or the new procurement strategies will never truck. Take the “color of money” pilots.  They dissolve budget categories like “research and development” and “operations and maintenance” -- and don’t require mandatory and distracting success triggers for opening up more money, and the innovation community just loves them. They could prove to be a catalyst -- but only if we draw out, and indeed learn, the right lessons from them.

These experiments are based in part on an intuition:  some software can be implemented, tested, revised, patched, and ported far more quickly than some hardware. That’s not because the process of engineering, building, and fielding a core software platform differs so much from building and launching a physical satellite bus. It is simply because a software failure is often more easily fixed than a hardware one. Rapidly fixing an unanticipated problem is at the core of an operationally responsive and threat-aware procurement system.  And the future is full of unanticipated problems. So we need to explicitly acknowledge that because we will almost certainly fail to predict the future, and fail to predict what technology will work, and when,  the Services and Combatant Commands must have flexibility to make adjustments not previously contemplated in our processes. Encouraging commanders to experiment, and then publish reporters about their failures alongside more “color of money” pilots is one way to show others that not getting it right the first time is often the opposite of a harbinger of doom.  Stakeholders, like  Congressional appropriators, the Office of Management and Budget, the DIB, and even the press will need several proofs of concept. Those proofs are critical to get them to allow the Pentagon to experiment with an even more audacious idea: funding hardware and core software infrastructure-- a legacy platform -- using the same budget rules. Why several?  Because innovation requires building into the system the ability to fail and to publicly document such failures so that others might learn.  And innovators need to inoculate the bureaucracy against the idea that a given pilot’s failure is always indicative of the failure of the new process, rather than simply a natural consequence of experimentation.

We need to have paths for prototyping and paths for innovative foundational work -- not everything can or should be a hackathon or a quick pitch.  Our forces require agility and adaptiveness, meaning that we must seek the right balance between moving fast and moving slowly.  When I was in the Infantry, the experienced combat leaders often reminded new arrivals that slow is smooth and smooth is fast. Service chiefs and the folks who run procurement are often a bit jaded. They haven’t seen a procurement prototype that they can mentally hook a more extensive project or initiative around.  When the Defense Innovation Unit stood up in 2015, then-Secretary Ash Carter put on a good show of accepting the Silicon Valley catechism that “failure is an option.” The DIU (then called “DIUx”, with x standing for experimental) was ordered to confront the bureaucracy but from within the Department. Simultaneously, other parts of the Pentagon were trying to impose new accounting rules that would make it harder for many firms to work with the military. Slow forward five years. Even the DIU Director admits that the rest of the building doesn’t tolerate his work - and some large but questionable awards from DIU for ho-hum innovation to darlings of Silicon Valley underscore why.  The Vice Chair of the Joint Chiefs of Staff was impatient at all the “prototyping” and wonders, “how do we buy at scale?”

That question leads us to step two: target the color-of-money pilots at programs that will scale -- and become the common factories -- software or hardware -- that themselves will be the foundation for future acquisitions, program updates, or imaginative iterations. In this way, we can assess these pilots’ success by asking whether they contributed to the enterprise beyond their specific project goals.  By incentivizing programs that incorporate modular design or have uses for other Defense or broader government agencies, the Pentagon will save billions in the long term.  The Pentagon’s special software acquisition team has shown how small experiments can scale. Using the color-of-money principals, it has piloted the process by which two super-large acquisitions -- the missile for the new Ground-Based Strategic Deterrent and the whole-of-DOD command and control system called GCCS-JE -- are being conducted, providing future planners with insights into how single-tub budgeting might conceivably be applied to the lodestars of national defense. Gen. John Hyten, the Vice Chairman of the Joint Chiefs of Staff, suggested this week that the only way the ICBM modernization program moves forward is if the chief contractor, Northrop Grumman, adopts iterative, integrative modeling -- something it can do only if the Pentagon allows it room to experiment.

The trick is to tell the right story so that innovation can be allowed to breathe and earn its way past cultural resistance. We might want to adjust the rules of the narrative. Instead of liability, a term denotes costs, overruns, legal trouble, penalties, and lawyers, use accountability. Require the pilot programs to express their goals in terms of what success looks like after an initial failure; ask them to spell out exactly what total failure would look like. After giving them some room, then hold them accountable for their work based on the terms of reference they provided.

With this approach -- allowing for failure, accountability over liability, steering prototypes towards multi-program use, and rewarding a blend of foundational and more superficial iterative changes -- the senior leadership at the Department of Defense might finally have a solid and pragmatic baseline from which to exercise their imagination.