DARPA theory of innovation

I recently read Loonshots by Safi Bahcall, a physicist turned biotech entrepreneur. The book included some interesting stories and ideas, but I didn’t find his terminology or physics analogies very useful. His word “loonshot” just means an innovative project with uncertain chances of success — trying to capture a notion I usually phrase as “you can’t get innovation without risk”.

The book’s thesis (as I see it) is that any organization that wants to be innovative should study and copy the DARPA model. Specifically, the US military is split into two branches that are organized very differently to optimize for very different levels of risk tolerance. The rigid hierarchy of the regular military is designed to carry out orders with no surprises. In contrast, the loose DARPA organization is composed of independent research labs working on innovative projects, most of which fail but some of which eventually transform the military’s capability (and beyond — we have DARPA to thank for the internet, GPS, voice recognition, and many other technologies). Other notable success stories have been organized in a similar way — from AT&T Bell Labs to the startups and tech giants of Silicon Valley — with separate yet interconnected groups focusing on predictable business vs. new research.

The part of the book I found interesting was the discussion of how critical it is to manage the interface between the two types of organization. If researchers don’t stay grounded in pragmatic operational needs, their research becomes less useful. And if operations teams don’t understand the research results or aren’t willing to try them out, then the innovations never make it out of the lab. The challenge is finding intermediaries who can talk to both sides — to convince academics that they need to pay attention to seemingly mundane details, and to convince bureaucrats that it’s ok to make measured changes and take risks on promising innovations.

I saw this challenge first-hand at Tableau. As a researcher, I didn’t fully understand the practical limitations of the business and I was frustrated when engineering teams showed little interest in adopting my prototypes. Meanwhile, engineers didn’t fully understand the promise of my research and were frustrated when I distracted them with ideas that seemed to put their operational goals at risk. In retrospect, it would have been helpful to have liaisons whose sole job was to bridge this gap, providing the necessary context to both sides and keeping the lines of communication open. I agree with Bahcall that such work is a difficult and under-appreciated specialty.