The US. Air Force is quietly proving that software development is a warfighting enabler. Kessel Run, the Air Force’s “software factory,” is a testament to what happens when you empower servicemembers to innovate and build their own tools. Growing from concept to two thousand airmen, government civilians, and contractors in three years, Kessel Run and its offspring have saved millions of dollars while improving mission effectiveness and established best practices for military software development.
While there have been calls for military software developers for years, the Air Force’s sister services are watching and are now considering whether and how to create similar software and product development teams. This is a significant organizational change and critics have pointed to challenges in developing cyber and space capabilities that could similarly affect software development efforts—that it might have the same difficulty in recruiting and retaining talent that currently plagues the cyber community, for example, or that billet structures and career advancement will be uncertain for these personnel. On an esoteric level, there is less agreement on whether software development needs to be in uniform since it is a capability rather than a new warfighting domain (as space and cyber are).
But the evidence from the Air Force’s experience is clear: uniformed software developers deliver products that are higher-quality and more useful than those from traditional contractors. Further, the ubiquitous nature of software on the digital battlefield requires military leaders to see Kessel Run as a proof of concept that should be scaled across the services, instead of treating it as an isolated initiative.
We recognize that countless entrepreneurs have pitched their ideas as “Uber for X” and failed to deliver the exponential returns implicit in this promise. Duplicating the success of Kessel Run in other services will require more than just the basic ingredients: money, offices, laptops, and people. The real story of Kessel Run is one of good timing, the right people, fortuitous connections, and excellent branding. Learning from the Air Force’s Kessel Run experience provides insights for minimizing risk and maximizing servicemember impact while scaling this capability across the military.
The Origin Story
In late 2016, Air Force Col. Enrique Oti began standing up a team at the Defense Innovation Unit-Experimental (DIUx) in California to develop a command-and-control planning tool. A few months later, in 2017, the Defense Innovation Board toured the Central Command Air Operations Center in Qatar to study how technology was being leveraged to fight the Islamic State. During this visit, board members, including Eric Schmidt, the executive chairman of Google’s parent company, were shocked to see soldiers and airmen manually transcribing data from one digital system into another, inviting human error and inefficient workflows. More unbelievable, they saw Air Force personnel planning air fueler flight missions on white boards, spending hours each day on a process that was creating suboptimal results while being vulnerable to everything from changes in mission planning to simply being erased accidentally.
The board members could not square these observations with the notion that this was the world’s premier twenty-first-century military. The US military had been conducting combat operations in the region for a decade and a half and the annual costs of these inaccuracies totaling over a hundred million dollars of wasted fuel and constrained mission capability—not to mention the cost of the people doing the work. Additionally, Northtrop Grumman was years behind schedule and millions of dollars over budget in delivering a contract intended to modernize air operations centers. Almost immediately, the DIUx director called Col. Oti and told him to pivot to the tanker planning tool.
Around this time, Capt. Bryon Kroger was serving as an acquisitions officer at Hanscom Air Force Base outside of Boston. A targeting officer by training, Capt. Kroger wanted to address shortcomings he experienced while deployed to Afghanistan. Specifically, he found that supporting precision strikes for the most advanced weapons platforms in the world relied on absurd workflows.
During his deployment, as a multi-million-dollar drone tracked the enemy ground vehicles, Capt. Kroger used Google Earth to estimate distance and then crudely time the vehicle’s drive between known points to estimate vehicle speed while also estimating the weapon’s time of flight, drone flight speed, and impact location. This mismatch between sophisticated weapons and unsophisticated planning tools risked any number of problematic outcomes, from civilian casualties to operational failure. Moreover, it was unnecessary: the drone was able to pinpoint the location of the vehicle using its GPS and sensors, but no one had added the additional algorithm to estimate the vehicle’s speed, even though this is required data for an engagement. No one was talking to the users and Capt. Kroger wanted to fix that while modernizing the suite of tools.
In April 2017, Col. Oti, Capt. Kroger, and Lt. Col. Jeremiah Sanders, from the Air Force Air Operations Center (AOC) program office, got approval to stand up an Air Force software development team. In a way, Lt. Col. Sanders represented the customer, and without the customer’s buy-in, there was a real risk that new tools would simply be shelved rather than adopted for use. The AOC program office had its own priorities, but after lengthy and tense negotiations, the three groups agreed to join forces. Under Col. Oti’s project, they were already recruiting and selecting airmen with interest and experience in computer science. Kessel Run partnered with Pivotal Labs to train the airmen and later settled in office space from WeWork through an office management service contract.
The team also made a crucial choice to initially focus on a specific targeting tool rather than trying to boil the ocean with an entire aerial operations system. Less than ninety days later, the team produced its first tool and put it in the hands of real users. Estimating the cost savings of a targeting tool is difficult—what’s the cost of a strike or a miss? However, the tanker planning tool can count savings in planes, hours, and gallons. The tool went live in March 2017 (prior to Kessel Run’s official launch) and immediately improved planning efficiency, allowing the Air Force to use fewer aircraft each day. This saved enough money to pay for the tool and the initial training costs within a few weeks. By then, the team was already on to its next projects.
Lesson 1: Think big, start small, then scale.
Kessel Run’s journey speaks to the power of driving innovation from the tactical level with senior-leader support (and not the inverse). Entrepreneurs and technologists speak often about building a “minimum viable product,” or MVP. This is the prototype that you can put in the hands of a user to begin iterative refinement of design and functionality. As an example, if you’ve never built a car before, you’d be well served to first try to build something that can drive—a go-kart, not a Ferrari. In the context of Kessel Run, both the organization and its products leveraged this model: start small, refine, and scale.
Looking at the organization, instead of establishing a three-thousand-airman software wing, the program began with a very small team, demonstrated effectiveness, and has now grown based on proof of concept. This means that the organization contains only the people and resources needed for existing problems and that new teams (and processes) are created to address needs. Although this approach is initially crude, the refinement process improves quality while minimizing organizational fluff.
This organic growth process differs from a top-down innovation approach that must simultaneously overcome administrative delays, organizational politics, and complex stakeholder management while generating innovative solutions. As we’ve argued previously, building organizations in search of a mission, instead of organizing around a distinct problem, has a high risk of failure. The common consequence of so many competing demands are organizations that compete for budget and relevance, hiding behind grandiose vision statements, while frontline members struggle to understand their roles.
It’s vital to point out here that senior leaders played a critical role, but not in the traditional military mold. Instead of giving orders, Col. Oti effectively “took orders” from his team in the form of addressing the hard problems that blocked their progress towards creating valuable products. He was able to escalate issues and advocate for resources. Selecting leaders based on openness to this inverted organizational chart will be crucial for other services to duplicate this success.
Lesson 2: Software development is a tactical enabler.
At the heart of the Kessel Run origin story is a clear tactical problem that needed solving—the first of many. Across the acquisition spectrum, contractors have struggled to deliver useable products on time. A common refrain is that the military keeps moving the goal posts as requirements change while the product is in a development pipeline or a year or longer. Kessel Run was able to address this more effectively than the existing contractor by developing software using commercial industry best practices, specifically “agile” software development.
In software development, “agile” is not a bastardized military buzzword. Instead, the term refers to a development methodology that uses direct customer feedback to drive development through sprints lasting one to four weeks. Readers familiar with the military’s targeting cycle will find agile software development familiar. After building an MVP, each of these sprints provides value to customers by releasing new code and building the next development iteration around emerging customer needs.
In a military context, agile development has two unique challenges: the users are frequently deployed and their feedback requires understanding a workflow that lacks a civilian equivalent.
Military software developers can work alongside warfighters more easily than contractors, which ensures that resources are spent solving the right problems. Moreover, servicemembers serving as developers can create software that reflects a more nuanced understanding of the use cases and technology interdependencies.
Agile development differs from traditional acquisition approaches since constant feedback loops decrease risk of making the wrong product and the approach focuses on creating immediate customer value. Continuing the car analogy, the “waterfall” method would have independent teams building the engine, frame, wheels, and seats in isolation with a major milestone only coming when the teams test putting them together at the end of the year. Agile development avoids this problem. (Recognizing the challenges of changing industry processes, the Defense Innovation Board has even published a Guide to Detecting Agile BS.)
In broader economic terms, this is a classic make-or-buy problem. The military needs to start making more software, just as it “makes” much of its logistics, maintenance, medical, and even religious products and services. In-sourcing software development also protects against disruptions from civilian contractors. In an extreme example, Google declined to renew its Project Maven contract after employee backlash surrounding the Department of Defense drone project. While we recognize the difference between cutting-edge machine-learning projects and the sort of back-office or productivity tools that Kessel Run’s embedded software developers are creating, the lesson is no less relevant: the competition for digital talent may prevent the Pentagon from ready access to the key enablers needed for time-sensitive capability gaps.
One of the most effective strategies for mitigating these market sensitivities are upskilling campaigns using internal personnel. At one time, basic electronics were a subject for research labs, but the services now have electricians (and even nuclear technicians). As the military masters this training process, they can create a pipeline for internal software developers for active-duty or reserve personnel. This value proposition expands further if leaders use this as a nexus for leveraging teams of reservists that combine private-sector technology talent to challenges active-duty military personnel currently cannot solve. Internal teams that are skilled in agile practices provide an immediate opportunity for reservists to collaborate on software development sprints during consolidated drill periods—creating value for both specific projects and the services’ strategic talent management goals.
Lesson 3: Using organic talent provides asymmetric advantages that contractors cannot replicate.
There is another benefit from integrated software developers that is difficult to quantify. On paper, it’s possible for military units to sign contracts for each tactical application or even open-ended contracts for software-development services. In practice, the time and effort to manage these contracts is overwhelming and instead units punt solving the problem and leave it to frontline workers to overcome. At scale, these decisions accumulate to a massive waste of time and effort. Worse, this creates a culture of mediocrity that accepts the status quo. This is what the Defense Innovation Board could not believe when they toured the Central Command Air Operations Center in 2017.
At the enterprise level, building software capabilities around tactical problem statements ensures institutional investments are matched against warfighter needs. This yields a “pull”-based development model, where investment is connected to real operational needs, instead of hypothetical requirements. It also creates an organic discovery process that identifies the next relevant domain for growth and budget allocations, a more agile approach than the waterfall method used to guide current development strategies.
While Kessel Run partnered with Pivotal Labs for training to get off the ground, using military personnel offers several critical advantages. First, doing so helps to develop products too small for current contracting systems. While technology companies eagerly compete for large projects, like the Pentagon’s $10 billion cloud-computing contract, many technical capability gaps are too small for this model. These “minor” gaps range from individual mission planning applications, like the tanker fueler app, to connecting databases or reporting systems to enhance communication between operational units. At present, servicemembers must overcome these technical problems with laborious and often inaccurate work streams, wasting time and money. Small internal software development teams can address small projects trapped in this “no-man’s land” of problems too small for large companies and too big to be ignored. Done well, outcome products can achieve immediate operational impact and scale across the force—like the $13 million and 1,100 man-hours Kessel Run saves the Air Force each month.
Second, utilizing military personnel accelerates code delivery. Even if a contractor is available, the project is well understood, and developers have the relevant context to solve problems, success is uncertain and can take months to deploy solutions. This exposes servicemembers to risks and vulnerabilities during combat operations, even when they have identified capability gaps. While faster acquisitions can address some of these challenges, it cannot compete with Kessel Run’s responsiveness, using benchmarks like going from concept to MVP in 124 days or deploying updates to production every 11.2 hours. The power of continuous delivery was highlighted in October 2018, when Secretary of the Air Force Heather Wilson reported to Congress that “The use of Agile DevOps methodologies [by Kessel Run] . . . is proving successful and we are able to rapidly deliver cloud native applications that increase operational utility. . . . We believe we have demonstrated the ability to continuously deliver software that adds value to the warfighter.”
Third, a process that leverages uniformed personnel helps shape the development of the next generation of military leadership. Preparing for multi-domain operations requires the Pentagon to develop today’s emerging leaders with the technical experience necessary to navigate a digital battlefield. Internal software development teams can address this challenge by providing experience running teams with digital tools. Kessel Run learned not only that was it possible to develop such talent, but that it was critical that coders and designers were complemented by leaders that could manage technical projects to create operational capabilities.
Since experience leading these projects supports both leader development and operational force requirements, ensuring that emerging leaders have the opportunity to compete for these assignments allows the military to capture value and experience that would be lost if we relied on external contractors. The special-operations community can exploit this opportunity by assigning small unit leaders to bring their nuanced understanding of current operational problems to small development teams, while refining tactics based on software outputs.
It’s Time to Hyperscale
The proliferation of digital technologies has effectively erased the boundaries between “tech” and “non-tech” companies, making software a core dependency for all industries. This trend is highlighted by changes to fields like the automotive industry, which hired three times more computer scientists than mechanical engineers in 2018. The Defense Department is long overdue for making the same pivot and modernizing in a meaningful way.
At present, modernization mainly implies simply updating or replacing platforms: new artillery, new tanks, new helicopters. They want incremental innovation within the twentieth-century paradigm. To truly “win” at modernization, the department must ask (and deliver on) what the future of conflict and a digital-first military will look like. This will require senior leaders (and the organization at large) to overcome blind spots and slaughter sacred cows through deep reforms.
Despite what many see as an overwhelming success, there is still much resistance in other services and communities to seeing software development as a warfighting enabler or role for military personnel. It is very likely that such resistance stems from a lack of understanding about these skills’ centrality to modern operations and how lessons from Kessel Run can propel the Pentagon’s modernization efforts.
The need to correct these misconceptions and make software development an organic capability is vital to success on the modern, multi-domain battlefield. As Kessel Run Project Manager Maj. Matt Nelson’s has put it, these capabilities are needed to “keep up with a data-driven war.”
The US military must be able to sense and respond to the adversary with new code and new algorithms faster than the adversary can develop its own. In other words, you don’t go to war with the software you develop, you go to war with the coders you develop and they ought to be soldiers, sailors, airmen, and Marines. Making software development into a core competency is just one example of this. Kessel Run showed senior Air Force leaders, like Acquisition Executive Will Roper, that “every [weapons] program will eventually have to have an agile software pipeline.” Said differently, the F-35 is not just a fifth-generation fighter jet; it’s a ruggedized, micro–data center that flies.
In the near term, creating teams of uniformed software developers provides the US military with critical enablers that can deploy alongside users to iterate on these tools for combat operations. At present, the lack of billeting and talent management strategies hampers efforts targeting these issues. This is especially acute at the tactical level, where individual manning is often seen as a zero-sum game, making commanders hesitant to lose some of their best soldiers to borrowed military manpower requests. While resolving this issue likely requires enterprise-level policy changes, the Defense Innovation Board’s Workforce Now recommendations provide insightful next steps. One of their recommendations involves creating a Digital Innovation Talent Management program, administered by service personnel chiefs, that provides billets for key digital talent so these individuals can be placed in separate holding pools, thereby eliminating institutional friction.
In the Long term, institutionalizing these skills creates a talent roadmap for future senior leaders to integrate emerging technologies into their strategic plans and maintain technological advantages over near-peer rivals. The need for these skills within the broader force will increase over time, as the complexity of our weapons systems and operational concepts demand levels of technology literacy that our formations often lack. Further, as the technical competence of successive generations increases, the need to harness that talent and solve this problem will rise.
It is critical that software development is perceived as a fundamental skill and enabling capability, or we will fail to manage the complex challenges at the heart of modern warfare.
Maj. Jim Perkins is assigned to the Army Reserve’s 75th Innovation Command in Seattle. He served on active duty for eleven years and now works in national security cloud computing and software development. Previously, he was a Center for a New American Security Brimley Fellow and from 2015 to 2017 was the executive director of the Defense Entrepreneurs Forum. He tweets at @jim_perkins1.
James “Jay” Long is a captain in the Army Reserve, a National Security Innovation Network Startup Innovation Fellow, and an experienced national-security innovator based in New York City.
The views expressed are those of the authors and do not reflect the official position of the United States Military Academy, Department of the Army, or Department of Defense.
Image credit: Jerry Saslav, US Air Force