WESTLAKE VILLAGE, Calif. — The promise of Silicon Valley is built on unicorns — startup companies valued at more than $1 billion. They’re rare. Hence the name. But the payoff is big enough that venture capitalists are willing to funnel a lot of money by way of multiple rounds of funding toward unproven technologies, to accept significant risk, in hopes they’ll be in on the ground floor of the next great discovery.
Compare that to Washington, where in the words of Defense Innovation Board Executive Director Josh Marcuse: “We put forward a defense program full of things that we know aren’t going to work, but no one is willing to say so.”
For more than three years the Pentagon has attempted to draw upon the Silicon Valley culture of innovation, to buy instead of build, to take advantage of commercial technology. But success has been spotty at best — with SpaceX and Palantir rather exclusively held up as the two “unicorns” catering to the military.
But while many procurement reformists will point to burdensome regulations as the problem, innovation leaders from both the Department of Defense and Silicon Valley companies agreed during a November roundtable hosted by Defense News that no laws currently in place prevent smart buying by the government.
Instead, those same innovation leader say that what causes the greatest minds in the tech community to walk away from the largest buyer in the world is a slow, arduous process combined with a serious lack of understanding within the Pentagon for how software is designed.
“We basically created an innovation program where you have to have Howard Hughes-style entrepreneurship to do anything that matters,” said Trae Stephens, partner at San Francisco-based venture capital firm Founders Fund and co-founder of Silicon Vally tech firm Anduril.
To buy or to build
Since the 1990s, defense acquisition regulations have clearly stated that commercial preference should be given in every contracting decision. Reinforcing that point, the Office of the Secretary of Defense for Acquisition, Technology, and Logistics released a guidebook for acquiring commercial items in January 2018, stating: “The time and cost to develop and field new capabilities, the technological advances made by near peer competitors and the rapid pace of innovation by private industry have demonstrated the need to access the best technology — now.”
And yet, such earnest support of commercial tech does not regularly filter to the acquisition community. Agencies over-specify requirements, “so now if the company wants to do business with [the Pentagon], they have to modify their product,” Stephens said. “All you have to do is say, ‘Yes, we have validated that there is no commercial product that meets our requirements,’ and that’s it.”
The Pentagon does not, however, do the opposite — adapt requirements for a particular product.
“There are a lot of things that we just have to build. We’re going to build aircraft carriers, we’re going to build fighter planes,” Stephens added. “And then there’s the thing that we’re going to buy — the products. These should be entirely separate conversations.”
That over-specification runs counter to the “agile” development method typically favored by the tech community, which is built on a premise of short sprints that factor into evolving requirements. Agile can’t exist without a degree of flexibility, ensuring, too, that if you fail, you fail fast. Contrast that with the traditional waterfall approach that predefines the various phases of development to ensure, in theory, a predictable outcome.
For their part, “the acquisition community inside the department knew they were supposed to ask for agile, and then savvy marketing people understood that they should just sell the same waterfall approach using different terminology,” said Raj Shah, CEO of Silicon Valley startup Arceo and founding managing director of the Defense Innovation Unit.
The result: program managers or senior leaders in the Department of Defense advocated for some new software, where the vendor was supposedly doing agile, but with sprints that last 180 days, led by teams that have never met the ultimate users of the products, using the same traditional development infrastructure .
“They can say, ‘we’re talking to users,’ or they can say that ‘we’re doing sprints,’ but it isn’t really agile,” Shah said.
Under his tenure, DIU came up with a way to try to arm people with probing questions to get to some ground truth around how the software is developed, and for whom and at what tempo. It’s helped — people inside the Pentagon are starting to use metrics to try to figure out what they should buy in the future, and companies are incorporating these metrics into their pitch decks.
But what might drive a true transition?
“The way you would do this, if you were serious, is you would look at your defense program, all hundreds of billions of dollars of it, and you would say: ‘Everyone that’s written a requirement that has spec’d out their waterfall development — that will be subjected to a higher degree of scrutiny.' And you should seriously consider not funding many of those things, and say instead: ‘Bring me a lean or an agile approach,' ” Marcuse said.
But “I don’t think there’s an appetite to do what I just described anywhere in the building at the moment,” he added.
You get what you pay for
Stephens estimates that the development of commercial products typically brings a 5 or 10 times multiplier on a company’s revenue, thanks to long-term, repeatable sales potential. And for developers, there’s equity associated with that. Put simply, “engineers working on these programs can have life-changing moments of wealth” that come from building these products that are easily re-sellable.
“When you over-specify requirements, not only are you forcing yourselves down this long and tenuous process, but you’re also fundamentally changing the economics for the people that are building the thing” because the potential of repeatable sales en masse all but disappears, Stephens said. “So my theory then would be that when you hire people to build things with labor, you’re getting the leftover engineers that aren’t optimizing for ambition because they’re making a financially unwise decision.”
Silicon Valley is an engineering-driven culture, and engineers “get turned on by the latest and greatest technical challenges,” said Steve Bowsher, managing general partner and executive vice president at In-Q-Tel, where he leads the company’s technology investment strategy. The American not-for-profit venture capital firm invests in high-tech companies that show promise for the intelligence and defense communities. It’s name is a reference to Q, the brains behind the futuristic tech supplied to James Bond.
“But engineers are also capitalists, and they want to make money for their companies. And the U.S. is a large tech buyer that is just not very good at buying from startup companies," Bowsher added, noting that startups get funded in 12-18 months, and can only land the next round of financing by showing tangible progress by way of purchase orders.
And just as there are unicorns in Silicon Valley, there is the so-called 10-times engineer — the developer that creates such robust and elegant code that he or she performs 10 times the amount of work an average engineer would.
“If you really want to find the unicorn or ninja, or whatever the latest word that they’re using, the engineer [needs to be] 10 times more productive than the next guy because these problems are really hard,” Shah said. “But in the current contracting process, there’s not a lot of value given to that type of thought. It is I need ‘X’ number of engineering hours to write ‘Y’ amount of coding. Both measures are the wrong ones if you’re trying to get quality.
“If we want procurement officers and acquisition officers to make these sound decisions, they need to understand this technology, they need to understand how it works [or they need to identify] people that understand this, and find ways for them to come into the department to help."