I was pleased to speak with Navy Lieutenant Sean Lavelle on the Acquisition Talk podcast. He is the founder and lead of the iLoc development team, which rapidly deploys valuable software capabilities to the Navy’s P-8 fleet. During the episode, Sean describes how P-8 aviators took it upon themselves to code new applications that could solve hard problems with software rather than pencil and paper. One application reduced reporting errors by 90 percent.
Sean provides a compelling vision of the future where operators also take on duties as software developers or product managers. This doesn’t require everyone to have coding skills. The P-8A’s organic software team only has six rotating developers. Sean argues it is better to have many users involved in defining the business logic with a small team of software developers rather than a large software team with little access to user input. The result is a continuous process where knowledge from the military operators can quickly get embodied in software and deployed to the entire fleet. Sean calls this “software-defined tactics,” and it’s a compelling concept indeed.
One of the many benefits is that it decreases the burden of training as operators are constantly involved in small changes. This is in contrast to the large and infrequent software drops from contractors, where increased capability often comes at the expense of increased complexity. It usually takes 3 or 4 years, for example, to train a P-8 tactical coordinator. However, with the iLoc tools, a trainee of 6 months can reach a level of proficiency that used to take two or more years. Agile in-house software development vastly decreases complexity at the same time in generates new capabilities, allowing the US military to scale much more rapidly in the event of conflict with a great power.
Podcast annotations
Here are a few good short quotes:
Our intuition in the military is often to slow everything down to the slowest component so we walk the whole process in sync.
And:
I think there is some advantage to not being reliant on exquisite ways of deploying software. In a phase two warfare where networks are being degrade and attacked, I think having less technically complex ways of delivering software is an advantage.
And:
We’re about doing stuff, not presenting stuff.
There was a ton to learn from Sean throughout the episode that can’t be excerpted, so listen to the whole thing! But I want to dive into a rather long quote from the very end for discussion because it is so insightful. First, recall that software-defined tactics is where military operators take their knowledge and code it into software applications using (1) continuous delivery, (2) informed evolution, and (3) the prioritization of teams. Here is Sean:
If I could touch on something more future-looking and speculative — software-defined tactics, in-house software development, tacticians making software — these are things that are improving our military capability today. Collectively they also make up a vision of what the military needs to maintain dominance in the next 20, 30, 40 years. As it becomes clear that autonomy and unmanned platforms are a necessary feature of our future force — I worked a fair amount in the machine learning space and there’s no magic algorithm that can produce the autonomous weapons we will need to keep America and her interest secure in the coming decades — at best, deep learning techniques will help automate some of the observation step in to OODA loop, but you still need software-defined tactics to orient the machine what it needs to do — we need written code, traditional algorithms that do the software-defined tactics that encapsulate the corporate knowledge, the hard-won business logic that human operators have sweat and blood to earn…
Right now, operators operate the platform. Warfare development centers collect data and devise tactics. Acquisition managers buy the software that the warfare development centers say the operational guys need. And then contractors build that software. When you take the human out of the platform, and everything you do hinges on that software-defined tactics working well, and you need to rapidly change those tactics to keep pace with the treats, I don’t think you can rely on that drawn out process to buy that at all. I think all four of those entities need to be much more tightly coupled.
I think that looks like moving the software-defined tactics from the warfare development centers to the operational units. Moving the software development work from acquisitions organizations to the warfare development centers. Moving the software infrastructure work that enables the software development from the outside contractors to the acquisitions entities. Then having the contractors work on the really heavy infrastructure work, and the initial deployment of major platforms, and the more exquisite research.
I think the work we’re doing in the P-8 community isn’t geared to any grand plan to bring that vision to fruition, but I do think carefully about documenting the work so that future defense professionals will have a sort of playbook when it comes time to field those platforms. I think the organizational openness and trust we have in the US military — the lowest ranking member of the team — is really a necessary component to making this organization work and I think that gives us a real competitive and sustainable advantage over our less open adversaries in the future. So I think we do well to lean into that sort of thing.
I think there is a great deal of wisdom in what Sean said. I’d like to try to break down a few things.
AI/ML and the OODA Loop
Sean says AI/ML will only solve the “observation” part of the OODA loop. Computer vision, for example, recognizes objects from an optical sensor. I would add that AI/ML can also automate the “decide” and “act” parts of the OODA loop, such as activating a weapon.
The harder leap, however, is “orientation.” As we’re always told, an algorithm doesn’t have a concept of what a cat is in the real world even if it can usually identify a cat picture — and so it can make silly mistakes when presented with something unfamiliar.
Orientation is so important in the OODA loop that John Boyd called it “the big O“. It relies on mental models which Boyd found to be necessarily incomplete by reference to Godel, Heisenberg, and entropy. So we in the real world will be constantly surprised and be forced to synthesize new mental models. These models are important not just for organizing human work flows in warfighting and business, but also defining the parameters of what AI/ML is optimizing for.
Organizational design
Sean depicts four interacting organizations:
- Military operations
- Warfare development centers
- Acquisition organizations
- Defense contractors
Right now, there is a rather drawn-out linear process of what Sean described. Furthermore, the standing policy has basically been to outsource all acquisition to contractors. While somethings make sense to outsource, such as very complex systems which can be rather well-defined like a bomber aircraft, not everything should be put on a contract. Software is ripe for in-housing because requirements are ill-defined/iterative while the technology is rather ubiquitous/inexpensive. Until recently, iLoc delivered capability without budget or “software factory” tooling.
In my interpretation, Sean’s vision has military operators constantly defining their real-world knowledge into tactics that in many cases can be embodied in software. While much of iLoc development was done by these operators, the bulk of the software coding should move to the warfare development centers. Having been operators themselves, they will be closely connected to the operators and can rapidly deploy low-level applications.
The above will be enabled by the acquisition organizations (e.g., tech labs, program executive offices, system commands) which do two things: (1) provide in-house enterprise tools that enable software development and continuous deployment (e.g., Air Force devsecops pipeline), and (2) contract with industry for platforms, building infrastructure, deep tech R&D, etc.
Contractors will still have a very important role in defense acquisition, but the way I see Sean’s vision is to bring back the strong in-house capabilities of the Army arsenal and Navy bureau days, where perhaps 20-30 percent of real development for lower level components and systems engineering was done in-house. That allowed them to better communicate requirements to industry — in effect be a better buyer.
Great Power Competition
Sean’s emphasis on effectiveness and robustness over efficiency is important in the era of Great Power Competition. One aspect of that is agile development and continuous deployment of new capability — the ability to be adaptive to changing environments. This requires delegation of authority in many cases. Tactics delegated down to operators. Software development down to warfare centers. Program decision-making to acquisition offices. All this requires investment in the doctrine of mission command. Trust and openness is a valuable part of our liberal institutions that makes the United States dynamic and innovative.
Another aspect is the ability to scale up quickly by surging people and equipment fast. Software-defined tactics helps us get better applications faster, which can reduce training requirements and improve outcomes. Software is making our lives easier and more productive in all sorts of ways. This should translate to military operators as well. Proficiency can be achieved faster when software already embodies the collective wisdom. While I don’t think this translates to scaling hardware in a jiff, over time more of those problems will be solved using software.
Thanks Lt. Sean Lavelle!
I’d like to thank Lt. Sean Lavelle for joining me on the Acquisition Talk podcast. I’d also like to give a shout out to CDR Michael Kamas and CDR Jennifer Cragg for their support. I highly recommend that you read Sean’s articles in War on the Rocks — Fixing the Navy’s Software and A Solution to the US Military’s Scaling Problem — and in USNI Blog — The Navy’s Kessel Run, Presence vs. Posture, An Integrated Approach to Peer Competition, and Guiding Honor with Evidence.
Leave a Reply