French to U.S. on weapons development: How do you work with so many people?!?

Mr. Shapero: They [the French] make good aircraft, and they have also had disasters. But they do it much more cheaply than we do. Spending much more money and trying all our techniques hasn’t saved us from that. If so we might as well do it cheaper.

 

Senator Jordan: You are suggesting that we would do no worse if we had fewer involved?

 

Mr. Shapero: That is right. I honestly believe that we would even do better, because it is difficult to adequately design anything with thousands of people. When we were in France a colleague of mine asked the French engineers, “How do you work with so few people?” The Frenchman threw up his hands and looked at us in amazement and replied, “How do you work with so many?”

 

Having been an engineer and manager in the missile industry, I know that it is hard to accomplish much with so many people. You begin to avoid people and the “system” and try to do things “bootleg” in order to get the job done.

That was the wise Albert Shapero in a 1969 testimony to Congress, “The Military Budget and National Economic Priorities.” Hearings before the subcommittee on economy in government of the Joint Economic Committee, 91st Congress, First Session.

Indeed, back in the 1960s the French developed advanced jet aircraft including the Mirage IV bomber with no more than 85 engineers and draftsman, and a vertical rise fighter with fewer than 30. Defense contractors in the U.S. could scarcely respond to an RFP with at least that many people. Similarly, program offices averaged about 10 government people in France while in the US Air Force it would be hundreds. Total personnel for a European program wouldn’t pass 700, while in the U.S. between 2 and 10 times that amount may be required.

The Dunbar number — representing the number of people an individual can maintain a stable interpersonal relationship — is about 150 to 250 people. When teams get too big, communication becomes exceedingly difficult. Limiting team sizes not only improves coherence and accountability, but makes iterating developments much cheaper. This can lower the consequence of failure and speed up the learning process. That calls for purposely constrained requirements and an incrementalist policy: make decisions as information becomes available.