The DARPA execution framework boils down to showing that thing is not impossible, showing that thing is possible, and then making that thing possible

Executing on this framework is different for every case, which is why PMs need to be extremely competent, able to think for themselves, and trustworthy, but its still worth going a few rungs down The ladder of abstraction in to what this means.

1. Show that the thing is not impossible

At the end of this step, a PM should have a concrete vision of where the world could go, evidence that ‘on paper’ it should be possible, and a precise list of things that you would need to demonstrate to show that the vision was possible, not merely non-impossible. Man-Computer Symbiosis is the classic example of a concrete vision. Tactically, PMs get to this point by first talking to researchers in a domain about what they’re working on and start to synthesize possibilities into a vision of where the domain could go. They also get small groups of researchers together to hone ideas against each other and figure out where the key constraints lie. Massive constraints imposed by the laws of physics can kill the program right there, but if there are uncertainty ones that can be tested for a few hundred $K the PM will do that.
A large part of a DARPA program manager’s job is focused network building.

2. Show that thing is possible

At the end of this step, a PM should have demonstration-based evidence that creating the vision is possible and a roadmap for how to get there. (Technological roadmapping can give an idea of where technological evolution can go and how to get there) The evidence and roadmap needs to hold up to scrutiny by well-intentioned experts. (The ‘framework’ DARPA PMs use to create a program is by modeling the tech council) Tactically, PMs get to this point by bringing together small groups of researchers to map out precisely what the pieces of the puzzle look like, which are the most risky, and where the unknowns are, what experiments could be done to derisk the biggest risks. They figure out where you can’t get more precision without experiment and do those experiments as part of seedling programs. DARPA PMs use seedling programs to ‘acid test’ the riskiest pieces of a program idea. They lay out where the biggest blockers are along the roadmap and figure out the different approaches that you could take to remove the same blockers.

3. Make thing possible

This is where the majority of the time and money in the program and can potentially last through the tenure of multiple program managers. During this step PMs fund different groups to work on different pieces and approaches for the problem, making sure that the groups working on different pieces are communicating through both formal and informal channels to minimize getting stuck and maximize new ideas. The PMs adjust frequently, killing approaches that aren’t working and reroute funds to new approaches that come up. There are many tight feedback loops built into the ARPA model.

  1. Show that thing is not impossible
    • The actual tactics
      • Talk to researchers in a domain about what they’re working on and start to synthesize what the possibilities are
      • Lay out a vision for where the domain could go
      • Get a small group of researchers together to start to synthesize ideas and where the key constraints are
      • Fund a few experiments to that physics/the world doesn’t forbid something
    • Output
      • A vision of where you could go with evidence that ‘on paper’ it should be possible
      • Enumerated what you would need to show in order to show that the thing is possible
  2. Show that thing is possible
  3. Make thing possible
    • This is where the majority of the time and money in the program
    • Fund different groups to work on different pieces and approaches for the problem
    • Make sure that the groups are actually talking together
    • Bring all the performers together for conferences
    • Kill approaches that aren’t working and reroute funds to new approaches that come up

Questions

Related

Web URL for this note

Comment on this note