Mark Mandeles on system design principles

In this episode of Acquisition Talk, I speak with Mark Mandeles about a wide range of topics in defense management. Mark has had a fascinating career and has written numerous books and articles including The Development of the B-52 and Jet Propulsion, and, Military Transformation Past and Present.

Mark talks with me about how military organization impacted the innovation process, why it is impossible to predict the growth of scientific knowledge, how the B-52 development turned out to be a stunning success, the role of strong technical managers in a process-oriented culture, how the Air Force promised business efficiency to gain its independence, and much more.

He also describes some big problems with the systems program office concept, as well as other aspects of the defense management process as laid out in the 5000 series regulations. Mark argues that traditional notions of business efficiency are ill-equipped to handle uncertainty. He recommends and provides examples of an alternative concept based on system design principles.

Mark is a fantastic resource for thinking about complexity in defense management, and has been a constant source of inspiration to me. He has posted much of his writing online for free, including the B-52 Development book, Systems Design and Project Management Principles, and Needs and Opportunities in US Naval History which we discuss on the program.

Commentary on the conversation.

I asked Mark to describe how the Americans viewed defense management after World War II. He said that the Air Force was able to separate itself from the “messy” Army because it promised to bring business efficiencies to defense management. Here’s part of his excellent response:

Big business and their managers were seen as extremely competent. Government officials, for example, were not seen as competent…

I remember talking to General Bryce Poe from the Air Force who told me an anecdote about businessmen from leading American aircraft companies acting as if they were the font of all knowledge. And Bryce Poe responded ‘Hey wait a minute, I’ve got more aircraft, more different types of aircraft, more bases, any number of other factors that render this judgement of their singular superiority questionable.’

This applied in 1950. Certainly this did not apply in 1945.

I think that this was an important point. In my view, the Department of Defense is a very different institution than are market firms. It is far larger, more diversified, and could perhaps be described as more of an ecosystem or economy unto itself than it is a firm. The DOD must thus be weary of “business efficiency” because it must explore disruptive technologies as well as technologies that sustain current ways of doing things.

In the market, two firms may invest in conflicting views of technology or consumer demand. This turns out to be efficient because we cannot know ahead of time who is right. If we did, then any conflicting resource allocation is irrational.

Armen Alchian recognized that profitable firms were those selected by the environment — there is no profit maximizing procedure, but those firms who survived acted as if they were efficient, even if random noise in the environment could have led to a different set of winners and losers.

The DOD needs a similar method of exploring requirements which may conflict each other in terms of technical or military feasibility. These were not the arguments I made in the podcast, but nevertheless, Mark quickly identified the influence on my thinking:

Your arguments are very similar to the kinds of arguments made by Burton Klein, William Meckling, and the others were making at RAND. RAND in the 50s did a number of tremendous studies on research and development, looking at the importance of multiple competing efforts, to produce knowledge through the competition of the design teams and the production staff.

Those things were at variance with the logic and the assumptions behind the program management office, where the program manager was the repository of all knowledge relevant to that program and that the program manager could schedule and program out discoveries.

Here’s more:

What you’re talking about with the notion of the program office is the introduction of the efficiency concept into development decision making. I see that as a tremendous error. It’s a tremendous error of organization and design. This problem relates to the problem of Karl Popper… the efforts to organize for efficiency means that you have to assume that you can plan that you will know something in the future.

It’s a subtle but important idea that you cannot predict technological growth. And yet the entire scheduling of a technology project is precisely what we’re attempting in an Integrated Baseline Review of an development contract. We may know a lot about the physical aspects of materials, but it doesn’t invalidate the trail-and-error method. Cost growth is but one reflection of this planning uncertainty.

I asked Mark whether there was a better way of approaching technology development then setting up a project office and putting some guy in charge to go get the thing. He advocates a set of system design principles:

Open architecture, modular design, standard interfaces, high technology level readiness components, operational testing, and deadlines for the completion of work….

Those system design principles were designed to deal with uncertainty. They were designed to deal with an innovating enemy. And it was designed to work at a level of the budget and stay within that budget…

In doing so, you can make great rapid progress, and in fact, I think it was possible to go within the enemy’s OODA loop — the observe, orient, decide, and act conceptual framework proposed by Colonel John Boyd.

I think the part about being designed for uncertainty, and designed to deal with an innovating enemy, is incredibly important. I like how Mark related it to the Boyd’s OODA loop. I’ll add something here by relating it to Edward Luttwak’s Logic of Paradox.

Luttwak found that traditional business efficiency was wrong for making weapon systems such as aircraft or even components like radars. Any single system is limited in its performance, and can be countermeasured by the enemy. Attempts to achieve economies of scale by producing many quantities of the same system is dangerous in the face of an innovative enemy.

The system design principles help us field new equipment quickly to perform new missions and counter our enemy’s systems. This cannot be done with decade long development cycles. Mark provided an excellent example.

In his time at the Office of Force Transformation, Mark supported the WolfPack project which provided a battlefield networking suite for Army vehicles. Its major competitor was he infamous Future Combat Systems (FCS) program, which was supposed to be $32 billion and was cancelled after far more than $1 billion was spent. Mark tells us how WolfPack was able to deliver 3 prototypes within 6 years, and received “rave reviews” for a tiny fraction of the cost sunk into its non-functioning competitor, FCS.

Here’s a little more about the system design principles:

Well if you expect that you’re going to do several iterations of a particular project, and you understand that the development process is largely a recombination of existing components, then you can exploit the rapid development of knowledge within the general market. You’re not focusing on… basic knowledge. You’re applying knowledge that is existing and being developed.

Mark also explained how the Navy was better able during the interwar years to shift itself from battleships to aircraft carriers, while the Army did not experiment with new concepts in tank formation and communication. Mark explains the role of organizational design. He concludes:

The Navy was more conscientious in developing these ideas than was the Army.

Here’s a teaser:

Eric: It doesn’t seem like that General Staff model really made its way into the Navy, which was a bit more pluralistic [than the War Department]. Is that right?

Mark: It’s consistent with the general argument there there are a couple of minute corrections to make…

And a related bit:

Mark: What Hammond shows is that the model of the General Staff that [Secretary of War Elihu] Root applied was not a good copy of what the Germans were doing.

Mark goes on to describe some ways that US Army misapplied the Prussian model of the General Staff. An additional point that I think I picked up from Hammond’s book some time ago was the idea that the original Prussian General Staff had two concurrent lines of authority through the commander and the chief of staff. In the American model, the chief of staff is an “alter ego” to the commander and thus was not intended to conflict with the principle of unity of command. However, in practice that conflict frequently arose.

I’d like to thank Mark Mandeles for joining me on Acquisition Talk. As we learn in the episode, he has adapted a wide-range of insights, including those from his university professors Martin Landau and Todd LaPorte, as well as Vincent and Eleanor Ostrom, and expanded on them in an effort to advance defense management. I’ll be releasing the second part of my conversation with Mark in the next few days. Here’s my first question in that one: