We are in the early stages of a generational defense cycle that requires unconventional thinking and tools. The invasion of Ukraine highlights this evolution: comparatively low-cost weapons, from drones to precision artillery, are leveraging cutting-edge networks, like SpaceX’s Starlink, to redefine battlefields. Meanwhile, a new variable — attritable tech — is emerging. The implications are upending how militaries fight.
Defense innovation has always sparked a helix of action and reaction, where faster evolution means greater success. In World War II, Turing’s codebreakers at Bletchley Park reacted to Nazi cryptographic improvements in a running duel that spanned years. The naval Enigma wasn’t broken once, but dozens of times.
We are in a similar moment today, although the rate and scale of change is accelerated. Consider the lightning speed at which today’s most advanced general computing projects evolve. OpenAI’s GPT-4, which was released a little more than two years after its predecessor, can now ace bar exams and convert sketches to functioning websites — all in a compressed upgrade window that overtook competitors seemingly overnight. As general computing platforms become applicable to a host of defense applications, from programming autonomous behavior to conducting live targeting analysis, sweeping advances in software and other technologies not originally designed for defense have unintentionally compounded computing’s impact on war.
Responding to the paradigm shift requires reengineering the Pentagon’s DNA for a new era. Given that the winner of the next big war will more closely resemble a distributed computer operating at scale — programmatically collecting, sharing, and acting upon data from relatively inexpensive and configurable endpoints, like drones — computing design and organizational principles honed in the tech industry can help provide guidance to meet the challenge.
Here are some ideas for how to do it.
As the Central Intelligence Agency’s Chief Technology Officer Nand Mulchandani pointed out in his essay “Software-Defined Warfare,” cloud computing (and modern application design, overall) ushered in an era where hardware components like servers, storage devices, and networking equipment have become interchangeable and standardized. The transition to treating servers as “cattle” instead of “pets” presaged a reduction in operational complexity, driving lower costs through commoditization. Businesses utilizing cloud resources don’t need to endure long hardware provisioning cycles just to test out new applications or features, or over-purchase hardware for peak workloads that might come just once a year. Businesses adopting cloud native design principles care relatively little about hardware at all — their workloads are packaged as application containers that can run on any virtual machine running Linux.
Modern militaries face a similar competitive landscape, but the consequences are defeat instead of bankruptcy.
For a glimpse of what’s to come, look no further than the Donbas. The Defense Advanced Research Projects Agency’s (DARPA) premonition of “Mosaic Warfare” — saturating an adversary with cheap complexity — has come to life. Modded quadcopters are pairing with artillery to serve as ubiquitous reconnaissance and attack assets at the lowest tactical levels. Sometimes, even drones themselves are the munition, as seen in individual tank strikes and the mass naval attack that heavily damaged the Admiral Makarov, the flagship of Russia’s Black Sea fleet. Drones, air defense systems, and missiles are democratizing lethality in much the same way offshoring, competition, and government subsidies relentlessly commoditized computing hardware and chips. This rapid shift in defense tech has economic implications; cheaper hardware can be deployed en masse.
Why, then, have hardware costs risen so dramatically at the Pentagon? The Air Force’s next-generation bomber, the B-21 Raider, is estimated to cost $700 million per aircraft — a 140x increase in today’s dollars over B-24 Liberators from World War II. Part of the problem is that the Department of Defense (DoD) doesn’t view most platforms as uniform endpoints in a larger network. For a substantial portion of the force, they should.
Quantity will matter in the next war. We will need to mass produce assets at scale — something we haven’t done with next-generation fighter jets or aircraft carriers. If military hardware isn’t commoditized, it won’t be replaceable in depth.
To this end, modern production sites for a commoditized future will look different than legacy facilities that built jets or carriers. They can be smaller. They can be modular. They can be forward deployed. They can use “just-in-time” manufacturing techniques like 3D printing to cut latency. In short, they add a layer of logistical resiliency by decentralizing a military’s industrial footprint.
Relativity Space’s 3D-printed rocket, which flew beyond the maximum dynamic pressure (“Max q”) exerted on the structure during its first launch, offers a preview of the promise of additive manufacturing. The effect may extend beyond typical materials categories too. Companies like Firehawk Aerospace, which 3D prints rocket fuel for solid-propellant rockets, could enable a distributed logistics model that optimizes for rapid, on-site production of fuels with finely tuned propellent grain geometries. Emblematic of the broader sector, Firehawk’s design only uses commonly available chemical materials – a sea change from current processes.
In combat, the Ukrainians are already using 3D printing to manufacture everything from drones to medical equipment. When combined with a transition toward commoditized hardware, they’ve nascently shown how elements of a 21st century force can be rebuilt on the fly, or reconstituted quickly. This regenerative capacity will be critical in other mission environments like the Pacific, where logistics chains could stretch thousands of miles.
The DoD should own the interfaces for its platforms. This prevents vendor lock-in and enables the DoD and external startups to compete within existing programs of record.
In creating the world’s first stealth aircraft prototype, Have Blue, which eventually became the F-117 Nighthawk, Lockheed Martin’s Skunk Works famously re-used F-5 engines, F-111 flight control actuators, an F-16’s flight control computer, a B-52’s inertial navigation system, F-15 servos, and an F-18’s heads-up display. To save time and money, Skunk Works engineers hacked together existing solutions from individual manufacturers. The two Have Blue prototypes came in under budget, at $30 million total — unthinkably inexpensive in today’s prime-dominated defense procurement environment.
What if this was the norm instead of an outlier? In the spirit of Skunk Works, composability incentivizes startup activity. Major weapons projects would become modular platforms. Important subsystems could be independently researched and procured. Smaller teams can leverage existing tools, frameworks, and libraries to reduce development time and costs. Lower barriers to entry fosters more competition. More competition results in better products at lower costs.
There are security considerations to allowing a broader category of actors access to certain programs, but these could be mitigated through a range of measures already in use, such as the testing and certification process (more below).
An “open API” schema could also offer defense tech startups revenue stability. Open standards allow them to compete for a slice of long-term projects in times of budgetary uncertainty. Such opportunities diversify business lines — just as prime contractors have done — giving startups a greater chance of surviving in an industry that bends toward forces of consolidation.
Battlefield data will come in unique forms. Synthetic aperture radar imagery from an F-16 Fighting Falcon will be different from infrared video captured by an AH-64 Apache. Instead of prescribing one standard data format, the DoD needs a robust translation capability for data that doesn’t throttle new breakthroughs. Think of it like a compiler.
DARPA’s STITCHES program is a first step in this direction. STITCHES uses Field and Transform Graphs (FTGs) to link data sets by finding pathways to translate data between systems. Imagine speaking to someone in Arabic through a common friend who speaks French. Translations can use existing pipes (English to French, French to Arabic) to route and translate traffic. They don’t have to be direct (English to Arabic), requiring each actor to change their behavior (learn a new language). By avoiding universal standards, “system of systems” designs accommodate a variety of data sets without imposing inadvertently overbearing requirements that stifle innovation.
This doesn’t mean some overarching commonalities shouldn’t be enforced. There are best practices for many applications. For example, avenues of convergence exist for positional data or video encoding processes, common areas where DoD platforms have extensive real-world experience. But focusing on the translation layer versus a standardization layer takes advantage of our biggest edge: innovative capacity.
Just as iPhones and Teslas receive frequent software upgrades, so will future defense tech hardware. In order to realize the benefits of a software-first system, though, that hardware will need to be tested and certified rapidly. And, for well-informed safety and security factors, any modifications to an existing DoD asset require exhaustive testing and certification prior to implementation.
The challenge is in balancing these processes against the benefits of modern software-enabled platforms that invert the traditional upgrade cadence. Software updates naturally occur on a more continuous basis than rigid hardware timelines. Adjusting to a continuous cycle means re-thinking budgeting rhythms that allocate funding on multi-year schedules guided by hardware updates. Software-first systems provide rapid upgradeability and redeployment, but their benefits are only realized if the testing and certification processes can match their speed.
The DoD should look to startups to help solve this problem. Automating testing is a clear way to cut development and deployment times if quality control thresholds can be maintained. Additionally, the DoD could provide new testing guidelines that delineate between deploying new software and activating embedded capabilities in existing software that should shorten recertification timelines. The procurement process needs a philosophical and operational shift to recognize the value of software not just commensurate with the value of hardware, but exceeding it. From now on, it’s the software that matters, the hardware is often a commodity.
Remote data collection — a skill tech companies have honed to a granular level — allows engineers to fix problems with over-the-air code changes. When the Russians began jamming Starlink satellite communications terminals in Ukraine last year, SpaceX engineers identified the type of jamming and pushed a software upgrade to fix it. SpaceX’s engineers didn’t even have to be present to take action; they diagnosed and remedied the issue from a different continent. This kind of capability is unprecedented in modern war.
Future forces will take programmability a step further. They will use fleets of upgradeable autonomous systems across a spectrum of manned counterparts, resulting in compute-centric networks that fight in fluid, more automated ways. Unmanned systems decouple costs from effects, allowing for “kill webs” instead of “kill chains.”
One implication of this software-first structure is the accelerated pace of tactical change. Iterative cycles will be measured in days, hours, and minutes — not years. This pace mirrors the tech world more than traditional defense procurement timelines driven by DoD’s multi-year Planning, Programming, Budgeting, and Execution (PPBE) process. Moving ahead, militaries that expediently gather, incorporate, and iterate on more and better intelligence will be better positioned to win large-scale conflicts.
Ukrainian missions against high-priority Russian military targets, whether sinking $750 million destroyers like the Moskva or damaging $330 million A-50U AWACS electronic warfare aircraft, have revealed the subtle, but instrumental role these platforms play in modern communications and air defense systems. Prior to its sinking, the Moskva provided a protective radar umbrella for the entire Russian Black Sea fleet.
Attacks like these illuminate the perils of “citadel-centric” strategies, or a reliance on expensive platforms, as Eliot Ackerman, the author and Marine veteran, wrote in the Atlantic last year. The marginal value of sophisticated, centralized systems declines in proportion to an adversary’s defensive capabilities. This isn’t to say they aren’t useful, but it doesn’t require a tremendous leap in logic to see the implications for downstream military strategy: an adversary can collapse an entire network by targeting critical focal points.
The solution may lie in a different systems architecture. Take Starlink. Starlink is difficult to disrupt because it has more than 3,500 satellites in low Earth orbit (LEO), giving ground terminals varied pathways to an array of overhead access points. When combined with a subtle electronic intelligence footprint, high bandwidth, and low latency, it provides a new communications capability that isn’t easily degraded or destroyed. There are too many discrete nodes.
Drones could also contribute to a decentralized architecture. In the next conflict, they will communicate with each other directly, akin to a peer-to-peer computing network. When synchronized with other computing advances, they will learn from each other too, streamlining software layers that aggregate data. An MQ-9 Reaper will go beyond simply conducting remotely operated surveillance. The drone will learn from what it sees and then relay those lessons to other assets — assets that will be expendable, but whose knowledge won’t be. Permanent memory is an output of resilient data networks.
Procurement officers need to be rewarded for taking appropriate risks with startups. In the current system, they are not.
Startups face skewed downside in the Pentagon’s decision matrix. There is no incentive for a forward-looking official to select an untested startup for a new contract. On the other hand, picking incumbent prime contractors is always a safe bet. Even if the project finishes behind schedule and over cost, no one gets fired for adhering to the status quo. And, despite a host of initiatives designed to provide high-risk capital to defense startups, make-or-break program funding is still largely decided by procurement officials within the Pentagon.
The Defense Innovation Unit in FY23 issued $1.3 billion in transition funding in 2022, and just over $200 million in prototype awards — substantial increases from previous years, but less than one percent of the Pentagon’s budget from the FY22 National Defense Authorization Act. Moreover, only four percent of the overall U.S. national security budget is dedicated to innovation. It’s not enough. On a proportional basis, big tech companies are spending three to five times more than the Pentagon on research and development.
The larger challenge is: how can the Pentagon offer a broader and faster pathway for transformational defense startups to access larger contracts? We need a level playing field that lets the best tech emerge. Beyond a certain scale, all leaders of large organizations become capital allocators – priorities get the dollars. But in defense, entire swaths of dollars go to legacy projects and programs that are kept on life-support for far too long. It’s time to reallocate the dollars toward the future.
Integrating computing design principles into the military acquisitions process might sound like a reversion — after all, the Pentagon was instrumental in Silicon Valley’s founding, not vice versa — but computing’s pervasiveness demands an immediate strategy adjustment.
Our willingness to adapt matters. What today is considered asymmetric — drones over dreadnoughts — will become the norm. In fact, it’s a dynamic that plays out frequently in the tech industry when startups with new technology and fewer institutional constraints out execute deep-pocketed incumbents. We need to recalibrate our military procurement and design processes to account for that reality. Rewiring the Pentagon as an ambidextrous organization capable of rapidly fielding innovative tech and still delivering on established programs can help us get there.
Porter Smith is a deal partner at a16z. Prior to joining a16z, he researched autonomous systems for the Defense Innovation Unit and served in the U.S. military for 10 years as an AH-64 Apache and MH-6 Little Bird pilot.
David Ulevitch is a general partner at a16z co-leading the American Dynamism practice. David previously led the Security Business for Cisco Systems and was the founder and CEO of OpenDNS, a cloud-delivered cybersecurity business.
Thanks to Eric Slesinger, Kevin Chlan, Art Morrish, Andy Yakulis, Matt Croce, David Hoyt, Orlando Zambrano, Alex Pruden, Robert Hackett, and Derrick Harris for their invaluable contributions.
* * *
The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.
This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.
Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.