A large part of a DARPA program manager’s job is focused network building

DARPA and the case for embedded network governance points out that DARPA program managers act as ‘brokers’ and ‘boundary spanners’ - terms of art for people who connect relatively unconnected clusters of people. DARPA PMs network in the literal sense of creating networks, not just plugging into them.

The idea of focused networking is important. DARPA program managers have a clear purpose for building the network - first to generate a clear target in an area, then to solicit paths towards the target, and then to make sure that the people who are executing on those paths know about each other so small adjustments to the plan can happen as frictionlessly as possible. It is easy to network in an indeterminate way, hoping that the connections you make will be useful one day. This indeterminate approach is how much people go about networking.

“Networking” is just jargon for ‘building relationships with people who aren’t shoved in front of you by life’ and PMs need to do this at every step of The DARPA execution framework boils down to showing that thing is not impossible, showing that thing is possible, and then making that thing possible. What does this tactically look like in practice?

In the first step of the process, PMs need to find and become friends with (ideally) everybody who is working on ideas adjacent to the area where they want to have an impact to get a sense of what’s possible. It’s important for PMs to come from the research world so that they already have many of these connections. Realistically, PMs are able to get this access because they bring the possibility of funding. PMs also bring these people together in small groups to dig into which possibilities are not impossible and what it would take to make them possible. If the PM is doing their job well the people at the workshops won’t already know each other and will continue to poke at ideas together on their own. The second step of the process leverages the network built during the first step to quickly do seedling programs. DARPA PMs use seedling programs to ‘acid test’ the riskiest pieces of a program idea.

During the third step of the process, PMs depend heavily on the network to send unique solutions their way. The PMs host performer days - small private conference for all the people working on different pieces of the program. These conferences force people to talk about the work they’re doing while they’re doing it, which while uncomfortable, enables people to share solutions to tricky problems and form more connections. You could imagine this leading to problematic correlation between results because everybody would want to copy whatever the shiniest group is doing but at this point all the performers are locked in to whatever approach they’re trying.

You could think of DARPA PMs as manually playing the role of a Designed Serendipity system. Both connecting the right people at the right time and giving them an incentive to help each other out.

The Dream Machine talks about how J.C.R. Licklider was always flying around to different university groups. In addition to bringing together all the people who thought they were crazy to be interested in human-focused computing, he also helped create several new lab groups. Today, A new professor needs about $1.5m to get going. Interestingly, I haven’t seen any organizations devoted to seeding labs in a structured way beyond funding new professors who would have worked on those ideas anyway.

PMs also build networks of people in different classes of organizations - government, academia, startups, and large companies. Connections between different verticals is one way that The definition of the ARPA model has changed over time - in 1960’s, large companies had much more academic R&D arms and startups were barely a thing. In this way, DARPA PMs are acting to Manage the Transfer not the Technology. This shift in the PM role is important. Two reasons that we don’t have more awesome sci fi shit (§How do we get more awesome sci-fi shit?) that I’ve seen over and over are 1) technology that needs actual manufacturing or high capital investment isn’t able to jump the gap from a lab to a startup prototype or from a startup prototype to a real scalably manufactured product and 2) there are many pieces of technology that are amazing but don’t warrant an entire VC backed startup on their own. It seems like building connections between different organization classes while the technology is being built could address both problems. Worth digging into more.

In a way, the Program Manager acts like a product manager in a tech company, talking to the customer and modeling their needs. For DARPA the military is the customer but the difference is that the ‘product’ isn’t something that can be purchased (TRL 9) but something that is proved out enough that other branches of the military.


Web URL for this note

Comment on this note