The best DARPA program managers are the ones who can look at an entire literature in an area and notice a systemic bias

IARPA

§ARPA model

DARPA Program managers pull control and risk away from both researchers and directors

Bartlett Russell

Data-Driven Discovery of Models (D3M)

Michael Goldblatt

How does DARPA strike a balance between problem-focus and solution focus?

Kaigham Gabriel

Defense Science Office - DSO

The coronavirus could lead to new institutional structures for long term preparation for tail events

Mihai Surdeanu conversation 14/2/20

World Modelers

Magnetically Actuated Micro-Robots for Advanced Manipulation Applications

# DARPA does multiple levels of top-down problem generation and bottom-up solution generation
In some ways the the Program manager is the ‘bottom up’ half of [[Top down problems and bottom up solutions]].  When DARPA hires someone, they are usually looking for someone to go after a vague area or problem rather than just hiring someone to fill a slot or because they’re great. So the DARPA director or previous program manager do a first pass of ‘top down.’  
The Program manager then synthesizes a program by digging into the current state of the discipline, what people on the bleeding think might be possible, and  integrating that with an idea of where they see the world going.  From the directors point of view this whole process is very bottom up. 

In other ways the program manager is the ‘top down’ half of [[Top down problems and bottom up solutions]]. When they are doing initial program design  ([[The DARPA execution framework boils down to showing that thing is not impossible, showing that thing is possible, and then making that thing possible]]) they talk to tons of researchers about possible directions and solutions. [[A large part of a DARPA program manager’s job is focused network building]]. During the actual execution phase, while PMs have a plan and an idea of who they want to deliver on it, they still put out a broad call that anybody can respond to at least nominally keep the door open to other bottom up solutions. 

In order to be a nexus of top-down and bottom-up approaches [[DARPA PMs need to think for themselves, be curious, and have low ego]]. If they don’t think for themselves, they will be at the whim of either the perceived desires of the director or the scientific community. If they’re not curious, they won’t actually synthesize anything interesting ([[The best DARPA program managers are the ones who can look at an entire literature in an area and notice a systemic bias]]) and will leave gems sitting by the roadside. Finally, if they don’t have low ego, they will build a program purely from their own ideas and cut off the bottom-up value of the system. 

### Related
- [[DARPA Program managers pull control and risk away from both researchers and directors]]

## References
- [[Email w Daniel Windham Part 2]]
- [[Mark Micire conversation 21/4/20]]


[Web URL for this note](https:

[Comment on this note](https:




Sam Moleneux Conversation 31/10/2019

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

# How does DARPA strike a balance between problem-focus and solution focus?
[[DARPA does multiple levels of top-down problem generation and bottom-up solution generation]]



[Web URL for this note](https:

[Comment on this note](https:




DARPA does multiple levels of top-down problem generation and bottom-up solution generation

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

The initial exploratory tranche of a DARPA program is approximately $1.5m

There are many tight feedback loops built into the ARPA model

Every program at DARPA is intensely technically scrutinized by the tech council

It is worthwhile to try to replicate outliers

# 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 
	- Output
		- Enough evidence that the thing is possible that it can stand up to [[The ‘framework’ DARPA PMs use to create a program is by modeling the tech council]]. Basically getting the idea to [[TRL3 - Proof of Concept]] 
		- A roadmap of how to get to the vision [[Technological roadmapping can give an idea of where technological evolution can go and how to get there]]
	- The actual tactics
		- Get that same small group of researchers together to map out 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. The biggest “blockers” to the vision in as precise definition as possible. Figure out where you can’t get more precision without experiment and do those experiments. 
		- 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 
	- 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
- [[How does DARPA strike a balance between problem-focus and solution focus?]]
- What does it look like for something to be possible vs. impossible “on paper?”
- What are ways that you can show that something is not impossible?
- What is the difference between showing that something is not impossible and that something is possible?

## Related
- [[Roadmapping could be thought of as backwards-chaining together a series of conception-only heuretics]]
- [[Technological roadmapping can give an idea of where technological evolution can go and how to get there]]
- [[Modularization allows different groups to work on different pieces]]
- [[Program and project management is important and valuable]]
- [[A large part of a DARPA program manager’s job is focused network building]]
## References
- [[“Special Forces” Innovation: How DARPA Attacks Problems]]
- [[Sam Moleneux Conversation 31/10/2019]]7/5/20 7/5/20


                            

[Web URL for this note](https:

[Comment on this note](https:




Ben's working notes

How does DARPA strike a balance between problem-focus and solution focus?

Links to this note