A few years ago, the P-8 community faced an emergent tactical problem. Crews found that a sensor critical to the mission they were executing was reporting incorrect information. Immediately, the acquisitions community sprung into action to figure out what was causing the problem. They isolated the issue and devised a workaround. While the fix corrected the erroneous sensor information, it unfortunately caused delays. Crews would have to decide between latency and reliability, a decision with cascading tactical implications. Training a force of more than 1,200 personnel across 140 crews to properly make this decision would have been a formidable challenge.
The P-8 community had an alternative option, though. The community’s warfare development center—The Maritime Patrol and Reconnaissance Weapons School (MPRWS)— had a resident software development team. That team had built and maintained several applications that already aided with deciding how to employ the sensor in various contexts. This team of active-duty personnel, cross-trained as software developers, updated their applications to incorporate the new procedures, field-tested them, and shipped them to the fleet in a day.
Rather than undergo laborious training and fight hard-won tactical intuitions, crews only had to select a new option in their decision aid software.
It would be difficult to overstate the agility gained by employing warfare-qualified officers and enlisted service members to build and update applications such as these for the fleet. The MPRWS Software Development Team has produced more than 50 tools under similar circumstances in recent years. This ecosystem of applications includes tools that guide tactical decision-making, make it easier to efficiently manage squadrons, and reduce the time sailors spend on monotonous tasks. They have saved thousands of man-hours, increased lethality across all P-8 mission areas, and improved the lives of sailors.
Levels of Software Complexity
In the universe of problems facing naval units that software can solve, about 10 percent require deeply complex applications built by large teams of professionals. These are primarily safety-critical systems such as flight computers, weapon-control software, and integrated platform mission systems. The other 90 percent can best be built by warfighters cross-trained as software developers. We call these individuals warfighter-coders.
For example, take employing air-launched antisurface missiles. The integrated combat system that communicates with the weapon and ensures safe release is tremendously complex and requires dedicated software professionals to build and maintain. However, one or two warfighter-coders could build supporting applications to increase the effectiveness of the more complex system.
One example might be an application that helps build an optimal attack plan. This application could build a probabilistic assessment of the enemy’s composition given available information. It could use that assessment to determine the defensive capabilities of the force. And then it could build a layered attack plan with launch times, altitudes, and locations for the various U.S. forces to maximize the odds an attack will break through those defenses. It could build automated tasking messages to be sent to each of the supporting units, as well.
Another application might do a similar optimization at the operational level of war. It could take intelligence assessments of enemy locations and run simulations to determine the optimal weapon distribution throughout the battlespace, which could inform logisticians as they attempt to feed the right weapons to the right forces at the right time.
A final application could use post-mission data from training attacks to build automated report cards for operators that include detailed visualizations they can learn from. It could build data-driven profiles for each warfighter to enable their training cadre to provide more tailored instruction. And it could automate the post-mission paperwork that always accompanies military training.
All of these applications are simple optimizations to make a complex capability more effective. Without them, training syllabi have to be lengthened and repetitive training increased to ensure warfighters can execute manual workarounds. Just like better training meant an F-14 flown by an American was more lethal than one flown by an Iranian, better supporting applications allow sailors to use the systems the Navy buys from industry more effectively. They are the glue between training and acquisitions that make training more accessible and materiel more lethal.
Unfortunately, the Navy’s current personnel and acquisitions systems are incapable of delivering these kinds of applications without herculean efforts by fleet operators and program managers. Changing this could make the difference in tomorrow’s fight.
Why Warfighter-Coders and Not Industry?
Speed is everything. Even fast acquisition projects, such as Small Business Innovation Requests (SBIRs), add too much time to the development process. A typical SBIR requires two months to write and release, three months to select performers, four months for performers to create a Phase I plan and acquaint themselves with the problem, three months to down-select to Phase II performers, and six months for delivery of a final product. Eighteen months later, the government either will have a functional product or determine that it was not a great idea after all. This process is lightning fast in the world of government acquisitions but exceptionally slow anywhere else.
When a warfighter-coder wants to build an application, he or she spends a few days solidifying the idea with their peers in a design-thinking process, a couple of days building a minimum viable product (MVP), and then another few days testing it with their peers. At its longest, this process takes about a month, or 18 times faster than a SBIR. If the MVP tests the assumptions that underpinned the idea, the warfighter-coder can learn whether or not their idea was sound. Then, he or she can either continue to build the application in an iterative manner or pivot to another idea.
Since they do not need to negotiate contracts before working or spend large amounts of time trying to understand the problem, warfighter-coders can deliver software faster than any external vendor could. This is the difference between providing dozens of practical applications in 18 months and having one application that might be useful.
Scaling
The question is not whether experienced warfighters cross-trained as software developers can add value to the Navy. The Air Force, the Army, the Marine Corps, and the Navy’s P-8 community all have proven that they can. The question is how to take advantage of this insight in a way that works for the Navy, its particular operational contexts, and its traditions.
The Navy historically achieves the most success when it takes an iterative approach to significant changes. The Navy developed the Aegis Combat System by building a little, testing a little, and learning a lot with each iteration. Naval aviation started as just a few officers and a humble scouting mission, slowly growing into the large role it served during World War II.
With this history in mind, the Navy should take action to leverage the digital talent already in its ranks. Doing so requires building the stepping stones of a career in which officers and enlisted sailors can fight their platforms and then use their hard-earned expertise to build lethality-enhancing software. One possible answer is a modest investment in a software development team at Carrier Strike Group Four or Fifteen. These units serve to train and assess the other operational carrier strike groups. A software development team at either unit would observe common tactical problems across strike groups, build applications that help solve the issues, and then evaluate whether they are helping in successive training events.
This team would consist nominally of four to six warfighter-programmers. They would rotate in groups of two, traveling to deployed strike groups or observing COMPTUEX events for one-month detachments to find problems and build MVP applications to solve them. Working full time, these two-person teams could build one or two applications solving different problems during each one-month detachment. With validated solutions in hand, they would return to their home station to build out their MVPs into fully supported applications over two months. The Navy’s Black Pearl DevSecOps platform would aid this effort significantly. After completing their two months at home, the unit would detach to another deployed unit to start the process again. In a typical year, they would produce about 20 lethality-enhancing applications for the fleet.
When a new individual joins this unit, they would serve as the junior component of the pair. After completing four detachments and proving themselves competent, they could rotate to a different pair as the senior member. This on-the-job training, prove-it approach fits well within the Navy’s Personnel Qualification System culture.
Potential problems this team could tackle within the first month of creation include reducing inefficiencies in the air plan generation process, enabling carrier strike groups to plan better wartime navigation routes that increase survivability, or illuminating material deficiencies on carrier-based squadrons to predict aircraft availability.
There is no shortage of personnel in the Navy who could productively serve in this unit. Twenty-five percent of Naval Academy midshipmen graduate with majors that require some programming competency, meaning there likely are thousands of officers with the requisite skills to contribute. The unit’s sea-duty status would allow talented officers from any community to spend time there without undue career risk. It is hard to think of a more broadening experience than solving problems for every type of unit in the Navy. In the summer months, midshipmen interns could augment each pair. This would infuse new talent into the unit and expose midshipmen to the problems they might solve once they graduate.
If this model proves successful, the next step would be to expand the team significantly or create similar teams at the various fleet Warfare Development Centers. The effect would be the same with either option: significantly more high-quality software to enable the fleet’s success.
Next Steps
The Navy can implement this experiment immediately. It first needs to allocate six sea-duty billets at either Carrier Strike Group Four or Fifteen, advertise those billets to junior officers and enlisted service members, secure a small travel budget, and partner with Black Pearl for DevSecOps support. The inaugural personnel would then need to identify operational units that can host them for one month at a time, familiarize themselves with their initial toolset, and start building impactful software.
The Navy is embarking on a journey to build a more unmanned and autonomous future. As the Navy travels further down that path, having tactical software infused with warfighter experience will provide a decisive edge in combat. To keep these platforms effective in dynamic environments, the Navy will need a corps of uniformed software developers who can adjust their tactics, explain their algorithms to senior commanders, and take responsibility for battlefield actions. Like special operators, this corps will not be rapidly mass-producible. The Navy must take small steps now to ensure we are ready for the future.
