What can we learn from Eric Schmidt and apply to defense acquisition?

Xerox PARC came out of a similar structure [as Bell Labs]. Xerox at the time was a structural monopoly and not a legal one because they were the only ones building xerographic copiers at the time. They had the ability to build these research centers and during this golden age of research centers; this is where a lot of American science happened, because they had enough money and universities didn’t have it.

Today you wouldn’t have a separate lab on a hill. We’d been through this. In my career, now over 40 years, I tried to set up these research labs and they don’t work when they’re separate. At Google when we did the same thing, we created integrated labs where there’s not much distinction between the research part and the product development part. What you need is the researchers and developers working as a team.

That was Eric Schmidt on Conversations with Tyler.

The discussion goes right to the heart of technology transition and defense acquisition reform. Just this year, Undersecretary of Defense for AT&L split into two undersecretaries.

• USD(Research & Engineering) takes over the technology labs and focuses on innovation. It is limited to studies and prototypes.
• USD(Acquisition & Sustainment) controls everything from full-scale development to production and logistics. It is supposed to be cost conscious.

Splitting one office into two conflicting cultures is essentially doing the opposite of what Eric Schmidt recommends, which is to get “researchers and developers working as a team.” The DOD reorganization may worsen the “valley of death” problem. 

It’s kind of like the problem that Xerox faced. Xerox headquarters on the east coast picked what technologies to develop and market. It had a very different culture than PARC on the west coast, which was more free-wheeling. Of all the amazing disruptive innovations at PARC, Xerox headquarters could only bring itself to pursue laser printers. Here is one account of what happened at Xerox:

They hired the smartest people and built Xerox Palo Alto Research Center. PARC researchers invented the Ethernet, windowed computer applications, screen icons, and laser printers. Of the 10 most important developments in computing, Xerox PARC birthed at least half of them.

And how did Xerox management handle this windfall? They blew it. Choked. Perhaps the biggest screw-up in technology history. Almost every other company in Silicon Valley benefited from PARC’s innovations, but the only one Xerox managed to cash in on is the laser printer.

And that’s because Xerox’s business had been printers. Headquarters had no vision for a future of desktop computers, or whatever it might be. Luckily there were other Silicon Valley companies that saw the potential for disruptive innovation. Unfortunately for the defense monopsony, no such start-up competitors are allowed.

USD(R&E), the innovator, isn’t the one formally picking technological winners and losers. USD(A&S) controls the milestone decision process, though it doesn’t participate in the actual research in traditional S&T budget activities (BAs) 6.1-6.3. The technology labs typically don’t perform on BA 6.4 activities like advanced prototyping. That gets handed off across the valley of death to the system project offices under USD(A&S). Here is the GAO.

The acquisition community, as opposed to the S&T labs, traditionally bears the responsibility of maturing technology through advanced prototyping, which is in contrast to how the companies with whom we met operate.

USD(R&E) controls 18% of the RDT&E account and 7% of investment (includes procurement). USD(R&E) is kind of like PARC in that way, innovative but small and distant.

Milestone Acquisition Process. USD(R&E) performs up until Milestone A. Then, it is handed off to USD(A&S) when it goes into full-scale development (something more than a prototype).

Buried in the conversation, Eric Schmidt elaborates a little on what might bridge the valley of death, because surely, cultures don’t have to be across the continent to conflict with each other:

Often in companies, if you see executives who–because things are happening so quickly–don’t build common knowledge, things go off the rails. The marking people are doing one thing, the sales people are doing another…

In reproducible goods production on the manufacturing line, tasks are easily partitionable and required little communication. Today, intangible investments in software and platform design requires workers to have a clear goal with common knowledge.

For example, tasks in RDT&E are highly interrelated and require a lot of communication between participants. This means you can’t throw money at a problem to solve it. It takes time to on-board the right people and manage their communication.

Yet projects have to scale, which means investing in communication that appears inefficient. Remember, as the number of teammates grow linearly, the interpersonal links grow geometrically. Eric Schmidt said:

… one day I was talking to Larry, and I said, “Larry, we’re building glue people.” And glue people is my term for people who are very very nice, who sit in between two functions, and you don’t need them, but everyone likes them because they carry a person’s bag, and they write memos, and so forth, but you don’t actually need them. They make the system less efficient, if you will. 

This is kind of like what the Army is doing to bridge the valley of death. It has set up “cross-functional teams” that will manage the communication process between the technology labs and the systems project offices. It is similar to the “Task Forces” they had in the 1970s.

The biggest problem for getting technologies out of the prototype phase and into a successful development phase is again, the budget. Let’s say USD(R&E) successfully demonstrated a new prototype and they want to integrate that with sensors, ordnance, and other components to make a production-ready test article. Not only do they have to convince people in USD(A&S), who will be the ones taking it over to manage the rest of the way, they have to wait around for two years until funding is made available.

Two years is a long time.

Now, just because Eric Schmidt recommends integrating research and development (see ambidexterity) doesn’t mean everything needs to be integrated. After all, Google’s development choices are held into account by consumers (or advertisers). 

Who’s holding DOD developments accountable? When a project goes through Milestone B into full-scale development, it is almost impossible to terminate without an act of Congress. It will get produced and fielded. That is why so much scrutiny from 50 or more offices comes down on any project reaching a Milestone. Once funding is authorized, it is built into a long-term plan. All this before we’ve seen a working copy.

The DOD needs to separate its production decisions from its R&D decisions. Only those systems which are fully tested should be considered for production. Development should not be merely a prelude to production. If there is no market to hold the DOD into account, then organizationally separate them. 

USD(R&E) should have purview over 100% of the RDT&E appropriation, not 18% of it. Better yet, appropriate directly to the Program Executive Officers like they did to the technical bureaus of old. The purview of USD(A&S) should start at Procurement, deciding which systems are cost-effective. Better yet, give those authorities to the Combatant Commands like SOCOM and CyberCOM now have. Those choices of available alternatives will hold the developers into account. This was Armen Alchian’s point (here and here).

A couple more things. The technology labs usually have knowledgeable managers with a wide-range of control over projects. Then, before going full-scale, developments get handed over at Milestone B, and more likely before prototyping at Milestone A, where these projects are often assigned to some manager who has little experience in that technical area. Further, the contractor engineers who worked the Bid & Proposals usually don’t follow the project, it is handed off as well. Defense developments will filter though several managers before they get into production. What they inherit was never their idea.

This method of assigning people to projects, whose attributes are decided on by strangers, is probably detrimental. Here is Schmidt on motivation:

The key thing in leadership is how you get people to do things. My father taught me that the best way to get people to do stuff is to have it be their idea. So if you can find a way so that your idea is also their idea then you can go back to working on the people whose idea you don’t agree with. 

The ideal manager doesn’t ever have to do anything because all the people that they work with are self functioning, they’re self-organizing. It’s so obvious what they should do and they love it so much they never have any problems. They solve all their problems. 

Of course that’s not how it really works, but if you can’t motivate people around that then you’re not really giving them a chance to be successful.

Consider one example of how the defense project you work on, or even pioneer, may get bastardized. After Bell’s tilt-rotor aircraft was prototyped in 1981, the DOD added an absurd list of requirements to the project. The lead engineer went to his company VP and told him that “I wasn’t going to do it, that I thought it would be the downfall of the tilt-rotor.” But it was the only game in town.

The DOD committed to 1,040 birds at $41 billion in 1983 before development even started. It was introduced to operations in 2007, buying far fewer aircraft for more money. The true believers blamed the absurdity of the acquisition process for the problems.

You get a feel how the energy from the engineering leaders was getting sapped by the acquisition process. The development of that project, the V-22, lasted more than 20 years. The DOD forced incredible survivability requirements on the the V-22 development, leading to compounding problems, but in the end, they said they’d never put a V-22 in harms way, such as in a contested combat landing. So much for the engineering compromises.

Here’s the last bit. The DOD wants people with certifications, even if those managers with certifications underperform. The DOD looks for credentials and experience rather than bright ideas and enthusiasm.

Here’s Eric Schmidt on Google’s early process of only hiring young people who went to top-tier universities:

It produced people that were both young in business, and that were aggressive and ignorant of what they were doing. They didn’t know what they were doing and made mistakes. Our argument was that in a fast growing company, we need people who can pivot around whatever the new challenge is and we weren’t convinced that the people who had experience, since this was a new field, that that experience would allow them to pivot to new problems.

Not that I recommend only going after elite young students. Innovative people that can pivot come out of state schools and trade schools, and might be young or old. In either case, if workers perform well they should be praised.

A major problem in tech start ups seems to be the scaling issue. You not only need to hire a lot of high quality people fast, but the people that helped you get to where you are might not be the right ones to take you further.

The scaling issue in defense is again, right at Milestone B when you scale up to a fully developed system. The DOD historically overfunds projects right when full-scale development starts. Contractors can’t ramp up staff and get long lead items in. Then, it takes much longer and costs much more.

I recently bought Schmidt’s book, How Google Works. I haven’t opened it yet, but I think that his podcast with Tyler has got me motivated. Later I’ll post on insights from that book.