Applying Elon's Algorithm to the DoD
Enhance efficiency and productivity to strengthen our national security.
As longtime champions of reforming the defense bureaucracy to enable speed and agility, the recent resurgence of Elon Musk’s algorithm sparked an interest for a Substack post for how to apply it to the DoD, particularly in acquisition.
Todd Harrison recently published Will Musk’s Algorithm reduce military inefficiency—or increase risk? which was an interesting take. We took a different approach.
A summary from Grok
Elon Musk's algorithm is a methodology designed to enhance efficiency and productivity, particularly in manufacturing and problem-solving scenarios.
Question Every Requirement.
Delete Unnecessary Parts or Processes.
Simplify and Optimize.
Accelerate Cycle Time.
Automate.
This algorithm reflects Musk's approach to first principles thinking, where challenging assumptions and simplifying complex issues down to their basic truths leads to innovation and efficiency. It's applied across his companies to drive production, reduce costs, and accelerate learning and implementation cycles.
The following includes a Grok summary of each element along with our views on how to apply them within the defense enterprise.
Question Every Requirement
Musk emphasizes the importance of questioning each requirement, identifying the individual who made it, and not accepting requirements from departments without understanding their origin. This step is about ensuring that each requirement is necessary and understood.
Within the DoD, most acquisition programs start with detailed and prioritized needs documented by the Joint Capabilities Integration and Development System (JCIDS) run by the Joint Staff and Service requirements organizations. These are traditionally captured in an Initial Capabilities Document (ICD) to capture high level capability gaps. Then in parallel with the early phases of an acquisition program, they are used to inform an analysis of alternatives, support maturation of critical technologies, and develop an acquisition strategy to reduce risk, and eventually to staff a more detailed Capability Development Document (CDD). CDDs can take two+ years to capture and approve Key Performance Parameters (KPPs) and Key System Attributes (KSAs) along with Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, Facilities, and Policy (DOTMLPF-P) impacts.
From there, the acquisition community develops a System Requirements Document to include in a request for proposal and codify the requirements for a development contract. This process is the genesis for why it takes over a decade to deliver major systems. This also applies to simple things like a handgun where the Army spent a decade and $500M to capture the requirements alone for a new handgun for soldiers. Elon’s algorithm begs us to assess how informed and flexible the current process is.
How much are they informed by technology maturity, intelligence reports on current and projected adversary capabilities, and what industry can develop and produce? The answer varies by program of course but in general there is some level of technology readiness assessment, threat intelligence and market research that supports a program’s acquisition strategy. However, too often these are static (done once and rarely updated), are overly specific or overly generalized or executed in a pro forma manner (done to check a box). The reality is that today, while there is a strong bias on planning, there is also an expediency to get to contract award that results in a focus on low-value activities (like conducting numerous reviews) and sacrificing high-value planning (like having ongoing dialogue with multiple industry partners and assessing potential requirement tradeoffs with users in a disciplined and collaborative way).
How do requirements change in response to real-world events? When programs use the normal acquisition route (now termed the Major Capability Acquisition pathway), they are required to get an Acquisition Program Baseline approved that documents program cost, schedule and performance goals. For large programs, this information is reported to Congress and any deviations must be reported and corrected. This presents a major barrier to changing anything in the program plan once approved including requirements. While it is possible to update a CDD, it is incredibly hard, lengthy and bureaucratic. More often, programs just proceed on course until major issues are revealed that can no longer be ignored. This is despite the fact that acquisition history has shown that the last 10-20% of requirements may drive 50% of the total cost or schedule.
Why not just change the requirements on contract? One might think that if it is so challenging to change JCIDS-level requirements, why not change the lower-level ones on contract. The answer is that it should be easy to modify contract requirements (in the SRD) if they are identified as overly burdensome and maybe no longer have as much value as originally imagined. However, there is a process that decomposes all high-level requirements into system ones that provides a lot of flexibility to engineers on the program to “derive” system level needs from higher ones. Changing a lower level requirement can be challenging if it is viewed as important to meeting a higher-level one (even if this might be the opinion of one small group). Often these documents are managed by third parties (such a support contractors or FFRDC) that have more stake in being conservative than in helping to accelerate capability delivery.
The unsatisfactory answers to these questions is why we have advocated for building a 60-80% solution that can be delivered years earlier then regularly iterated upon to address more advanced needs or to respond to new threats. This is where the Middle Tier of Acquisition pathway comes into play by enabling rapid prototyping and rapid fielding and by being exempt in law from JCIDS. Similarly, the Software Acquisition Pathway allows for a high level document to capture high-level capabilities needed, with any lower-level ones managed via dynamic backlogs with active engagements with end users and developers.
Ideally, we must institute a model whereby commercial solutions or defense unique capabilities developed by companies are sold as commercial items to meet operational capability needs. Industry has mature product development processes and equally deep insights into the tradespace of system performance (cost, schedule, complexity), and how to maintain and upgrade them over their lifecycle. Instead of operating major weapon systems for 30-50 years, we can design systems to perform for half those timelines at lower costs and iterate on new systems with the latest technologies to meet the future operational environments.
Real-World Example (from Douglas Schwartz)
When developing the Tesla Model 3, Musk and his team challenged the conventional car manufacturing process. They questioned the need for multiple buttons and controls, ultimately simplifying the interior to a single touchscreen interface. This not only reduced complexity but also created a unique selling point for the vehicle.
Delete Unnecessary Parts or Processes
This involves removing any part or process that doesn't add significant value. Musk suggests that you might need to add some back later, but if you don't need to add back at least 10% of what was deleted, you probably didn't remove enough.
The DoD is subject to a vast mountain of laws, policies, and regulations. Title X is 1,200 pages of federal law that governs the DoD. The DoD is also subject to the Federal Acquisition Regulation (FAR) and Defense Federal Acquisition Regulation Supplement (DFARS) these combine to another 2,000 pages. There are dozens of DOD directives, instructions, and manuals governing defense acquisition that add another 1,000 pages. Finally, the DoD’s Financial Management Regulation (FMR) is nearly 7,400 pages!
The endless statutes, policies, regulations, processes, reviews, and certifications that govern DoD acquisitions, requirements, and budgets poses a great risk to our national security. The DoD, with Congress, OMB, and industry must aggressively question each “requirement” in these laws, policies, and regulations and aggressively delete those of little value. This deregulation will drastically cut costs and increase speed and scale of delivery.
As we’ve championed for years, the defense acquisition enterprise must prioritize speed of delivery. It should measure the time from program initiation (approved initial requirements or leadership direction to pursue) to initial and full operational capability. It must continuously streamline processes and policies to enable greater speed. We must apply lessons from WWII as articulated in Freedom’s Forge to reboot the Arsenal of Democracy. Congress gave the DoD novel acquisition and contracting pathways to enable greater speed and agility. The Middle Tier of Acquisition, Software Acquisition Pathway, Other Transaction Authority, and Commercial Solutions Openings have shown success that we should leverage to the fullest extent, when appropriate. However, some in the Pentagon and Congressional staff have sabotaged these approaches by subjecting them to heavy burdensome requirements and oversight designed for the billion-dollar weapon systems. The delete button should be the key used most on DoD keyboards this year.
Our colleague Dan Ward published some great work in this space. He has Trimming exercise as part of an Innovation Toolkit. Teams will iteratively remove unnecessary elements from a design using a structured approach to reducing complexity to produce a more elegant, streamlined final product, process, or organization.
He also published a book, The Simplicity Cycle, on finding the optimal balance between complexity and simplicity to improve the goodness of system designs.
Real-World Example (from Douglas Schwartz)
At SpaceX, Musk applied this principle to rocket design. Traditional rockets were often discarded after a single use, making space travel extremely expensive. By eliminating the need to build a new rocket for each launch through the development of reusable boosters, SpaceX dramatically reduced the cost of space missions.
Simplify and Optimize
After removing unnecessary elements, the focus shifts to simplifying what remains and optimizing those processes or parts for efficiency. Musk warns against optimizing something that shouldn't exist in the first place.
This mindset applies to weapon systems and DoD processes. The DoD and industry design extremely complex weapon systems. The added operational performance comes at significant cost, time, and risk. An F-35, B-21, or Columbia submarine will outperform any rival system and most countermeasures. Yet with increased costs (both initial and long-term) comes decreased quantities. Technical issues, supply chains, or combat losses will have an outsized impact on the Joint Force’s combat power. The world’s best drones can’t outperform these major weapon systems yet can offer increased mass at lower costs. Industry can produce thousands of drones in the time and with the costs to produce tens of these complex weapon systems. To meet the many mission sets required, DoD requires a high/low mix to maximize operational impact yet we continue to bias for the most extreme edge cases in our programs of record instead of prioritizing adaptability and optionality.
Most current and future systems should embrace simplicity as a key design factor. Doing so enables production speed and scale, reduces costs and risks, both in initial production along with lifecycle sustainment and supply chains.
“Too much of the time, the government tells people exactly what to do and exactly how to do it. It issues highly prescriptive requirements for schools, teachers, hospitals, and employers, at an absurd level of detail, rather than just describing a general goal and letting human beings use their own creativity and initiative to get there.
In a nutshell: Fewer rules and more common sense.”
The DoD transformed the standard acquisition process, after decades of use, into the Adaptive Acquisition Framework with six dynamic acquisition pathways. Congress explicitly exempted the newest pathways - MTA and SWP - to be exempt from the most egregious bureaucratic elements to enable speed and agility. Yet the bureaucracy in the Pentagon and some Congressional committees regularly sabotage them by adding layers of reporting, reviews, and certifications. Congress established a commission to reform the antiquated PPBE system. Yet the DoD and Congress will likely only implement a fraction of the reforms over the next few years, with the boldest reforms being set aside. Finally, Congress has driven requirements reforms, which the DoD is working, yet will likely not generate bold reforms to transform JCIDS for the modern era.
The next administration must take bold steps to simplify and optimize the three major enterprise processes - requirements, budget, and acquisition. If an entire board or oversight layer were removed, what would be the impact, both positive and negative? If the DoD eliminated many documents and reviews, how would the enterprise adapt?
The DoD must shift from managing over a thousand individual acquisition programs, each with separate budget accounts and requirements documents to a portfolio model. One that focuses on broader sets of capabilities required for the major operational mission areas. A new set of structures, processes, and empowered authorities to establish clear operational needs, flexible budgets within portfolios, and an array of program offices, S&T organizations, and industry focused on regularly delivering capabilities. They must actively engage users, testers, and futures organizations to continuously iterate on products, services, and DOTMLPF-P employment of these capabilities.
Real-World Example (from Douglas Schwartz)
The design of the Tesla Cybertruck exemplifies this principle. Its angular, minimalist design not only creates a unique aesthetic but also simplifies manufacturing. The use of flat panels and a stainless steel exoskeleton reduces the need for complex stamping processes and paint shops, potentially lowering production costs and improving durability.
Accelerate Cycle Time
This step is about speeding up the remaining processes. However, this should only be done after the first three steps to ensure you're not hastening unnecessary or unoptimized tasks.
After transforming the enterprise processes by eliminating the bureaucratic elements and/or taking a clean sheet novel approach, the next focus is on continuous improvement. A critical element is measuring what matters, to include time to navigate the major processes and the mission impact for each capability delivered. A large, complex weapon system will navigate the enterprise processes differently than the simpler, mass-produced systems. A software intensive system will iterate differently than a hardware intensive system. A commercial acquisition will differ from a new development system. Acquiring a capability-as-a-Service will differ from product acquisition. Measuring each of these across the department will help identify elements of the cycle time.
Process owners can then focus energy on identifying programs and organizations that navigate faster than others. It will identify barriers to speed to address as well as best practices to scale. The DoD should regularly report these measures across the department for increased visibility and to drive a culture of speed of delivery. Continuous process improvement requires teams to work with key stakeholder groups to identify more efficient means to achieve desired outcomes. There needs to be a mix of objective outsiders, including change management professionals to work closely with those involved in the key processes to accelerate cycle times.
Real-World Example (from Douglas Schwartz)
At Tesla, Musk has pushed for rapid iteration in both software and hardware. The company’s over-the-air software updates allow for quick deployment of new features and bug fixes, significantly accelerating the improvement cycle compared to traditional automotive update processes.
Automate
Automation comes as the final step. Musk learned from his experiences at Tesla factories that automating too early can lead to inefficiencies if not all previous steps have been addressed. Automation should enhance a well-optimized and simplified process.
The DoD has struggled mightily with implementing defense business systems to harness IT solutions for improved operations. Yet this massive enterprise has many areas that are ripe for automation. Far too much information and decision making are done via Power Point decks, staff packages, emails, and endless reviews. Free DoD requirements, budgets, and acquisition strategies from the PDFs and integrate them into online knowledge platforms. One that many can contribute to, based on their roles and send out alerts to key stakeholders for approvals, progress, and changes.
Envision a digital first enterprise to manage requirements, budgets, and acquisition. Don’t simply automated the current broken processes, but design from the ground up. How do strategic operational needs map down to individual capability elements? How do we resource them within the current and projected budgets? What strategies could we employ, leveraging an array of acquisition and contracting strategies? How can we source this from commercial or defense solutions? With over a thousand other capabilities in the digital system to learn from, how can we harness AI to rapidly develop strategies, empower humans to make decisions, and then guide the capability through the acquisition lifecycle in the most efficient and effective manner to achieve the desired outcomes within the available resources.
Real-World Example (from Douglas Schwartz)
At Tesla’s Gigafactories, Musk has pushed for extreme levels of automation in the production process. While this approach has faced challenges, it has also led to innovations in manufacturing efficiency. The company’s “Alien Dreadnought” concept aims to create a fully automated production line, dramatically reducing labor costs and increasing output.
Join the thousands of subscribers to get our weekly recaps and thought pieces. Paid subscribers also get budget and legislative analysis and are valued supporters of our work.
Interesting piece, though I think one key element Musk's rules do not have to engage that Harrison speaks to is that of trust.
There is bipartisan agreement on the urgency of the present defense reform challenge. Specifically, there is far less controversy on the argument that increased acquisition capacity will aid in deterring controversy than there was about the Iraq war post-2006 or the like.
However, the United States is polarized in ways that exceed the post-Cold War period pre-2016 period, which my past self might have often found a somewhat jaw-dropping statement.
Musk was operating with supportive shareholders and private capital. We're operating in a trust but verify environment. I think offering alternate means to earn trust is going to be critical for any defense reforms. To me for achieving trust in the defense-unique space, competition is more of a watchword than commercial. (Though of course commercial approaches are often a way to achieve competition in addition to offering a range of benefits of scale from commercial industry.) Faster cycle times and an emphasis on prototypes can also make it easier to earn trust along the way, but I think Harrison really captures the ways reform could founder if process reforms don't have new ways of earning trust replacing the old.
Excellent piece!