Should government own the technical baseline?

GFE — which is government furnished equipment — many times has a negative connotation to it. You would think that anytime the government is furnishing something for you it is not the best thing in the world. But from a technology perspective, when you look at the weapon systems themselves, there’s not much that differentiates them. It doesn’t matter whether it’s a tank, airplane, missile, or OPFOR, about 85% of that tech stack in that [software?] environment is the same.

 

What the government has been doing over the course of many years is staffing these requirements on these individual programs and paying a competent prime contractor to execute that platform for that mission-specific need. But what you realize is that the mission systems are identical. There is the potential for the government to be experts on their own tech stack and share that across platforms — mainly because it accelerates programs, it’s cost effective, and it massively reduces risk because you know it works since it worked on other systems.

That was Major Rob Slaughter, Director of DoD’s PlatformOne, on The Convergence podcast. And relatedly, here’s Nicholas Chaillan, DoD’s Chief Software Officer, on the Constellations Podcast:

We cannot succeed without industry, but we also don’t want to completely outsource all talent and all knowledge to industry without having proper oversight and understanding of the decisions… And so, I think it’s all about the right mix: you don’t want to be a majority of airmen quarters and you don’t want to be a majority of the entire industry team with no airmen baked in. So we’re trying to be in the 90%, 10%, 80-20 range, where 80% will be the industry partners and 20% will be government people, whether it’s, civilians or military. But that gives us the flexibility we need and the oversight, we need to make sure we make the right decisions.

I thought the 80-20 rule was an interesting way to think about it, and roughly corresponds to historical norms from the bureau and arsenal days of old. And I’ll give one more view from a very different perspective, Bryan McGrath on the Midrats podcast:

We decided we would pay industry to do integration and to do functions that were previously functions of the government. I am an ideological conservative to my bones. I am a free-marketer to my bones. I believe the United States military needs to protect and sustain those things, it doesn’t necessarily have to practice them.

 

There are certain functions that the government ought to be doing — the taxpayers ought to be paying the government to do — overseeing technical specifications, technical progress, technical innovation in shipbuilding was one of those things. We kind of walked away from that. There are a lot less people walking around at the Navy yard than there used to be. And I think that’s a shame.

 

And as we think about how to limber up in this new era of great power competition, we need to make sure that the organization we have is up to the tasks we ask of it… We devastated the workforce that wrote contracts, so that growth work identified during ship repair availabilities could be spec’d, costed, and the shipyard could be turned on to get that done.

In the Air Force, this term “owning the technical baseline” is characterized by a 2016 report from the National Academy of Sciences, and further explained by MITRE here. There is some notion of increased government rigor in program decisions, but I hear numerous definitions — often relating to their own context.

For example, Rob Slaughter and Nicholas Chaillan were talking about government orchestration of enterprise software tools. I say orchestration because DoD won’t build its own cloud infrastructure, it will buy and configure it from AWS, Azure, etc., and it won’t create its own deployment process from scratch, but leverage open source like Kubernetes. Government, however, will run these efforts and provide them as enterprise tools for traditional defense programs which are their “customers.” While success relies on program adoption, it has the potential for order of magnitude efficiencies.

Bryan McGrath was talking about shipbuilding, and here perhaps you have a similar model from the past. The bureau of ships historically owned a lot of shipyard infrastructure, but never to my knowledge did ship construction in-house. It was always contracted and supervised. [Update: The Navy did construct ships in public yards with public employees, such as at Mare Island, Philadelphia, Bremerton, and Brooklyn.] Rickover in particular preferred the GOCO arrangement to keep a closer eye on construction and insisted on making critical engineering decisions.

In general, the Navy workforce of the past was generously staffed. A 1970s appropriation hearing indicated that 34% of R&D funds stayed in-house to the US Navy, which excludes consulting support for “onstation work.”* For comparison, the US Army R&D chief in 1954 felt that 25%-35% of R&D should be done organically.

Here’s a few things I hear justifying this phrase increased government participation:

• Commercial companies never outsource core competencies
• Though companies are protected by limited liability, insurance, etc., DoD cannot defer mission risk onto anyone else and cannot hold companies responsible
• DoD cannot achieve modular open systems architecture using a contract, but has to participate in decision-making
• Common tech stacks accelerate development and reduces duplication
• DoD pays primes 20 or 30% to manage subs, and loses access to directly talking with subcontractor
• Government cannot evaluate contractor performance without having the experience of development themselves
• Many applications needed in DoD don’t require top coding talent, but do require detailed knowledge of operations and business rules
• Government staff is much happier doing hands on engineering compared to evaluating contractor PowerPoints

And here’s some takes on what it could mean to “own the technical baseline”:

• It doesn’t mean in-sourcing work, it means creating an architecture that maintains competition and avoids being locked into an OEM
• It means government personnel can talk on the same level as industry in terms of technology
• It means government performs product development and augments its staff with contracted labor
• It means government gets in the middle of integration decisions using modular and short duration contracts
• It means government develops certain components and sets interface standards
• It means government delivers enterprise solutions based on commercial technologies

I still am not sure what to make of all this, but I think DoD needs a rigorous conversation on this topic that gets people to use common language around alternative frameworks. Comments and suggestions are welcome!

*“DEPARTMENT OF DEFENSE APPROPRIATIONS FOR 1970.” (1969). HEARINGS BEFORE A SUBCOMMITTEE OF THE COMMITTEE ON APPROPRIATIONS HOUSE OF REPRESENTATIVES NINETY-FIRST CONGRESS FIRST SESSION, PART 4 RESEARCH, DEVELOPMENT, TEST, AND EVALUATION, 421 and 73.