Progress frontiers are geographically fractal

The tech tree is fractal

What are the properties of maps?

There are two levels of institution

Scientific inquiry is an abstracting process while engineering design is a narrowing process

Technological and scientific paradigms are each based around exploiting a specific phenomenon

The creation of a heuretic has two steps - conception and implementation

Phenomena are things that happen without a human consciously making them happen

Maps are multi-scale

The difference between specialists and generalists is fractal in nature

olsonManagingModesEffort2020

How can you describe the difference between learning by doing and idea sex?

Each node on the tech tree can recursively be decomposed into more nodes

Conservatism and Progressivism both have good and bad sides

Identity categories are fractal

# Every time you zoom in on a fractal, it presents the same pattern on a different scale
Fractals are Multi- Scale patters
## Questions
## Related
* [[Progress frontiers are geographically fractal]]
## References


[Web URL for this note](http://notes.benjaminreinhardt.com/Every_time_you_zoom_in_on_a_fractal,_it_presents_the_same_pattern_on_a_different_scale)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Every_time_you_zoom_in_on_a_fractal,_it_presents_the_same_pattern_on_a_different_scale)




Most roadmaps suck

Maps help you figure out possibilities

Maps help you understand the state of something

Technical Planning Principles

# Maps are multi-scale
You can get some information just by glancing at a map and then more and different information by zooming in.  Fractals were literally discovered by someone mapping coastlines.[[Every time you zoom in on a fractal, it presents the same pattern on a different scale]]. 

 If a map doesn’t give you something useful on first glance, it’s not doing its job. Most pure-text roadmaps fail on this point - it’s very hard to get something useful on first glance from pure text unless it has a well crafted outline. If you can’t get different useful things when you investigate a map more closely it’s not doing its job.

If you can’t get different useful things when you investigate a map more closely it’s not doing its job. Digital maps are wonderful in this way because they can actually load scale-dependent information. Good paper maps did this by being obscenely detailed - cartographers ‘[entire professional life is spent at the magnification level of a postage stamp](https://eyeondesign.aiga.org/for-decades-cartographers-have-been-hiding-covert-illustrations-inside-of-switzerlands-official-maps/).’

### Related
- [[Maps help you figure out possibilities]]
- [[Maps help you understand the state of something]]
- [[What are the properties of maps?]]



[Web URL for this note](http://notes.benjaminreinhardt.com/Maps_are_multi-scale)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Maps_are_multi-scale)




Roadmaps need to be coupled to people

# Maps help you figure out possibilities
Even the medieval T-O map let you know that you could get to Africa from Europe by crossing the mediterranean.  Star maps help you figure out which constellations you could draw or where you could look in the night sky. 

If you can’t figure out possible (and unallowable moves) from a map, it’s not doing its job. Many ‘competitive’ landscapes fail on this front. 

A good map makes you aware of the tradeoffs between different possible moves.  Google Maps also helps you figure out possibilities by showing alternate possibilities and making you aware of the time and distance between those possibilities. The parameters of these tradeoffs vary drastically between maps - on a hiking map, elevation is important while on a driving map it is almost irrelevant. On a research map, cost is important while on a star map the concept of cost doesn’t even make sense. 

[[The Map is not the Territory]] - a good map will capture the information that you need to make decisions and exclude information that is distracted. 

*Roadmaps* ([[§Program Design]]) explicitly point out those possibilities in an opinionated way.  The difference between a map and a roadmap is the difference between google maps and the directions the map gives you to a location. 

![](../BearImages/57FE1074-F3ED-4A30-A4EB-C75575380032-456-00003424E76F85DB/9F042C35-37C6-4A14-8DCC-2066389EFB4E.png)
(Wardley)
![](../BearImages/D46F1E2D-1AC7-43B6-B703-46E7BA120E26-456-0000343CA6138B63/A9DE43E5-B06E-442A-8C30-4ED7643D2317.png)

### Related
- [[The less shared context you have the higher the coordination costs]]
- [[Context is important and underrated for knowledge transfer]]
- [[Maps are multi-scale]]
- [[Maps help you understand the state of something]]
- Wardley points out how useless a strengths/weaknesses/opportunities/threats analysis would be for a battle [On being lost - wardleymaps - Medium](https://medium.com/wardleymaps/on-being-lost-2ef5f05eb1ec)
	- [[Wardley Maps]]

[Web URL for this note](http://notes.benjaminreinhardt.com/Maps_help_you_figure_out_possibilities)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Maps_help_you_figure_out_possibilities)






# Maps help you understand the state of something
If you don’t understand the state of something better after looking at a map, it’s not doing its job.

Maps are always an abstraction ([[The Map is not the Territory]]) so there is always something about the state of the thing being mapped that the map will not capture. However, this is not always a bad thing! You can think of a map as compressing and structuring knowledge similar to how [[Jargon is a mechanism for compressing information]]. 

The compression mechanism means that a map is always going to be opinionated about what is signal and what is noise. Therefore, the design of a map should never be independent of its audience. [[More context can decrease the signal to noise ratio of communication for people who already have that context]].

A [[Stock and Flow Models]] *can* be a map, if it reflects the state of reality, but is not necessarily a map. 

### Related
- [[Structuring knowledge is expensive]]
- [[Maps are multi-scale]]
- [[Maps help you figure out possibilities]]



[Web URL for this note](http://notes.benjaminreinhardt.com/Maps_help_you_understand_the_state_of_something)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Maps_help_you_understand_the_state_of_something)




§Program Design

Most predictions suck

List of Roadmapping Examples

You can create a program design discipline that enables better research and development

Program design could be thought of as creating a causal graph of blockers and hypotheses about how to mitigate those blockers

Program design is like creating the lego instruction book

Good roadmaps work backwards from a goal

Technical language should be treated like an actual other language

Playbook for Writing a Roadmap

People often confuse whether they are or should be creating prescriptive vs descriptive work

Program design creates Schelling points for purpose maintenance

Engineering Biology Roadmap -ERBC

What is SpecTechs Edge?

Jordan Blashek conversation 23 Feb 2023

Andy Matuschak Conversation 30 Aug 2020

Josh Greenberg Conversation 18 May 2021

Michael Filler Converstation 2 Sep 2020

# Most roadmaps suck
As the name suggests, roadmaps should have the properties of a map ([[What are the properties of maps?]]) [[Maps are multi-scale]], [[Maps help you understand the state of something]], [[Maps help you figure out possibilities]] and explicitly point out those possibilities and associated tradeoffs. 

Most roadmaps do a poor job on many of these points. Instead, they feel like a mush of keywords and key phrases that someone evaluating a grant could check against and say “aha! This grant is legitimate because they’re trying to do this this thing that’s mentioned in the roadmap.” 

Of course, it’s possible that creating a good roadmap is an impossible task. It may be impossible to create a roadmap that actually enables coordination and progress that would not happen otherwise. However, the assertion that most roadmaps suck is based on a list of points that are very possible to fix.  

- Most roadmaps are primarily text, which makes it hard for them to be multi-scale. You should be able to glance at a roadmap at at least get a sense of what you need to do. For most of these roadmaps you need to do a deep reading to actually get a full picture. The only thing you can get at a glance from a full-text roadmap is an isolated chunk of whatever you’re looking at. 
- None of the roadmaps I’ve seen talk about either who is most suited for a task and who is going to do it.  This people/organizational decoupling might work on for the semiconductor industry, where everything is highly modularized, interfaces are standardized, and each organization has a clear responsibility. For less mature industries this isn’t the case and there’s still no pointers from jobs to be done to people or organizations. [[Roadmaps need to be coupled to people]].
- Most roadmaps don’t have precise ideas of what would enable a capability step change. All aspects of a technology can be improved, but improving some metrics can actually make the difference between a tool being almost useless and super useful [[Continuous changes can lead to discrete differences]]. Sometimes these changes are going to be improved metrics, but I’m being careful not to over-focused on metrics because often the key blocker keeping a technology from being useful is more fuzzy. At the same time, sometimes numbers are necessary to enforce precision. 
- Most roadmaps don’t go into the precision needed to actually decide whether a project is on a critical path towards enabling something important. Following on the previous point, most of the intermediate steps in roadmaps are incredibly fuzzy “Step 5: build improved planning algorithms.” What does it mean to improve a planning? Calculating paths faster? Being able to recalculate smoothly on the fly? etc.
- Most roadmaps don’t precisely present the state of an area. A question I have constantly in response to “In five years, we hope to be able to X, Y, Z” is  “Ok, so why can’t we do those things today?” I suspect the way to answer that question is to work backwards from where you hope to be to where you are today. ie. [[Good roadmaps work backwards from a goal]].  In order to do that you need a clear idea of where you are on the things that matter.
- Most roadmaps don’t make it clear which constraints are major blockers and which are nice-to-haves from an application perspective. For example, do we need robots to have five fingered hands that are as dextrous as a human’s in order to take care of older adults? Probably not! Do they need to be able to locomote over carpet? Absolutely. 
- Most roadmaps don’t make it clear which metrics matter and which metrics don’t matter. Different metrics are important to different applications. 
- All the roadmaps I’ve looked at don’t distinguish between exogenous changes that they’re counting on and endogenous changes in the field that someone reading the roadmap needs to go do. Instead, the roadmaps just use the blanket statement “X should be possible or true in five years.” The litmus test is whether X would still happen if everybody reading the roadmap went and drank mai tais on the beach for five years. In the context of robotics, for example, Moore’s Law chugging away or shifts in the ratio of older adults to working-age people are exogenous changes. Faster path-panning algorithms are endogenous. It’s important to distinguish between endogenous and exogenous predictions because exogenous predictions can be core assumptions, while endogenous predictions need to be broken down into “X will happen in five years IF A, B, and C” so that if A is behind schedule you can update your expectations for X. 
- Most roadmaps don’t talk about different scenarios. It’s absurd to think that there will simultaneously be no exogenous changes in the world *and* you are absolutely right about each step of the plan. [[Plans can change in a definite worldview]]. I would hope to see statements like “The primary path to success looks like A -> B -> C, but if B fails to achieve X, an alternative path looks like E -> F -> G.” This sort of thinking allows you to assign some sort of weight to the chance that different scenarios would play out and spend effort effectively. Scenario planning has been a discipline since at least the 1970’s, so there isn’t much excuse. [[What role does scenario planning have in technological program design?]]
- Most roadmaps don’t break down why a timeline is what it is. Most timelines are in the form of “in the next five years, we could expect to get to this point.”  That sort of estimate doesn’t give you any room to come to your own conclusion. A bulk time estimate also doesn’t let you 
- [[Most roadmaps are not execution oriented]]. Concretely, most roadmaps don’t address jobs to be done. There’s a description of applications (like elder care) and ‘tools’ (like path planning)  ::need a better word here:: but not “these are the challenges in path planning that need to be done in order to enable elder care.” 
- Most roadmaps are dead documents. [[Make living documents]] is almost universally true but is doubly so for roadmaps. The whole point is to try to shift the frontier, so hopefully within a few months something is different about the world than when the roadmap was created - whether it’s an exogenous assumption, an endogenous capability, or even just different information about the requirements on a subsystem thanks to a failed experiment. 
- Most roadmaps do not acknowledge that [[Program design is a coordination tool]]. 

### Examples
[THIS IS NOT A ROADMAP](https://home.cern/news/opinion/physics/roadmap-future)
[The Rejuvenation Roadmap | Lifespan.io](https://www.lifespan.io/road-maps/the-rejuvenation-roadmap/) - reasonable
This can’t help you make any decision https://nowandnext.com/PDF/Mega%20Trends%20and%20Technologies%202017-2050%20(Web).png

### Examples of roadmaps that don’t suck
The [[International Roadmap for Devices and Systems]] is actually useful for guiding the semiconductor industry. I suspect this is because there are well-defined interfaces, most progress will be incremental, entities are fairly fungible, and there’s strong incentive for new entities to take on different pieces of the roadmap (like in the semiconductor industry .

### Related
- [[The returns to good technical planning have decreased]]
- [[Instead of planning not working as well as people in the past thought as a society we’ve become worse at technological planning]]
- [[List of Roadmapping Examples]]
- [[Most predictions suck]]
- [[What are the properties of maps?]]



[Web URL for this note](http://notes.benjaminreinhardt.com/Most_roadmaps_suck)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Most_roadmaps_suck)




# Technical Planning Principles
Each of these principles must reference one or more of the idealized properties of [[What does good technical planning look like?]]
 
Since we’ve established that good technical plans resemble roadmaps, what happens if we invert why [[Most roadmaps suck]]?
- ***State a precise, realistic, but ambitious vision*** What does winning look like?
	- 1, 8.1, 8.4, 8.8, 15
-  **Make living documents**  “No plan survives first contact with the enemy.”  It takes work, but living plans are powerful coordination tools that helped us get to the Moon. Computers make living documents easier to create but the liveness needs to be designed in from the beginning - ways to keep track of what was changed when, what depends on what, etc.
	- 1, 2, 3, 5, 6, 7, 9, 15
- **Graphical information should be a first class citizen** Text is great for explaining, making arguments, and creating a narrative, but it is terrible at creating a holistic overview.  [[Maps are multi-scale]] and it is hard to achieve that with text. 
	- 3, 4, 14
- **Talk about who could work on what.** More detail is better, from precise skillsets down to specific people or groups.  The latter is especially important for work on the knowledge frontier because [[There are many pieces of equipment or tacit knowledge that only exist  in one or two places in the world]]. 
	- 1, 2, 10, 11, 12
- **Prioritize problems to go attack.*** It’s hard but critical to identify ‘need to haves’ vs ‘nice to haves’ to make a vision a reality.  
	- 1, 2, 8.1, 8.4, 8.5, 11, 15
- **Make it clear what has been tried before and why it didn’t work.*** Most visions are not new and the people who tried to achieve them weren’t stupid. These two facts mean that you’re likely to try something that someone else has tried before. Doing this is not *necessarily* bad - the world can change, but the burden of proof is on you to explain what those changes are and why they will make the difference between success and failure.  
	- 8.2, 8.3, 9, 13
- **Explain both technically and politically why the vision isn’t a reality today** Technical projects don’t exist in a vacuum. Sometimes the real reason a vision doesn’t exist is because of regulation, cost, or institutional bias. It’s not a party-killer if the primary blocker on a technology isn’t sheer technical capacity but it does change how to think about it and the work that needs to be done to make it a reality.  [[You can transform between technology constraints, regulatory constraints, and cultural constraints]]. Non-technical reasons don’t have to be broad macro explanations either - it could be that professor A and professor B hate each other so they never integrated their technologies. 
	- 7, 8.2, 8.3, 11, 13
- ***Use numbers but no more than necessary*** Numbers are great because they are the most unambiguous way to compare two things, set targets, and see improvement. However, [[Metrics can cause paradigm lock-in]],  the [[Streetlight Effect]], and they can give a false sense of progress (ie. going from 50% to 75% is unambiguously a 50% improvement but is actually worthless if the same methods won’t get you to 99.9% and nothing useful will happen until get there.)  If there are one or more numbers that people are trying to hit, even the most diligent person will focus on the number instead of the high level goal. The upshot is that numbers are powerful, in both good and bad ways so be judicious about their use. Numbers are just one way to represent constraints and goals - there are other low-ambiguity markers of success and progress: precisely articulated scenarios, reactions of people using a thing to do a real job, etc. 
	- 1, 2, 3, 4, 7, 8.1, 8.8, 11, 14
- **Draw a clear line between the parameters that matter in a given context and those that don’t.** Both technologies and scientific theories have many operating parameters. One difference between the two is that while a scientific theory wants to explain as many phenomena and be applicable in as many situations as possible, a technology just needs to work in a set of specific contexts. A technical plan should make it clear which parameters matter for the contexts a technology is intended for. (ie. Weight really matters for a technology meant to be used on a spacecraft but doesn’t matter at all for one meant to be used on a boat.)  
	- 2, 8.4, 9, 11, 12
- **Address multiple development scenarios.** Anybody who has does technical development work knows that the first thing you try often doesn’t work. Resorting to alternatives is not a bad thing, but not calling out what they might be (and the failure modes that might lead to them) means that the plan doesn’t reflect reality from the start.  Good statements look like like “The primary path to success looks like A -> B -> C, but if B fails to achieve X, an alternative path looks like E -> F -> G.” Additionally, external circumstances might change - funding could increase or decrease or external technologies could be invented. Acknowledging this and providing multiple “tracks” the project could follow make it more likely to succeed.
	- 1, 2, 7, 8.5, 9, 11, 12, 
- **Explain timelines and budgets in as much detail as possible but no more.** Demystifying timelines and budgets open the possibility that someone else can help figure out ways to decrease them “oh, you need to buy that machine? A friend has a spare” etc.  At the same time, be honest - if you don’t know, you don’t know. Pulling timelines and budgets out of thin air is far too common and doesn’t help anybody. 
	- 2, 3, 7, 8.6, 8,7, 12
- **Be execution-oriented.** Unless there is a great reason to believe that some work will happen exogenously to the scope of the plan, everything needs to be done by a real human. Focus on specifically what those experiments, build projects, and other actions are. 
	- 2, 3, 8.6, 8.7, 10, 12

We can do even better than  just inverting the things that suck, but by embracing [[What are the properties of maps?]] 

- **Make the plan useful at multiple levels of detail starting with just a glance.** You should be able to get some information about the plan just by glancing at it and then more and different information by engaging further. Even the people who care about minute details appreciate an easily digestible overview. This principle is one of the reasons that images should be first class - it’s very hard to get information from glancing at pure text. 
	- 3, 4, 5, 8.1, 14
- **Help people come to their own conclusions.**  Giving a reader the power to disagree forces you to show  them that your plan is the best plan instead of asserting it. Room for disagreement enables much stronger buy-in in the long run. How do you help people come to their own conclusions? …
	- 1, 2, 3, 5, 7, 9, 11, 15
- **Lay out constraints, assumptions, and affordances** Constraints look like “this technique doesn’t doesn’t work in temperatures about 5K.” A lot of technological development is about relaxing or finding ways around constraints. Affordances look like “this tool is great at doing X and Y” - they’re kind of the mirror of constraints. A lot of technological development is about expanding or finding clever uses for affordances. Assumptions look like “we’re assuming that we’ll be able to run everything on off the shelf parts.” Explicitly calling out constraints, assumptions, and affordances helps people understand tradeoffs. 
	- 1, 2, 7, 9, 11, 13
- **Draw lines between the exogenous and endogenous.** Exogenous changes are things you expect to happen external to the plan - for example, it’s a good bet that there will be better GPUs in two years. Exogenous are fine to incorporate into the plan as assumptions. However, it’s important to call them out and ideal to outline different scenarios for if they fail to happen. It’s important to draw a bright line between exogenous and endogenous changes because endogenous changes fall under the responsibility of whoever is executing on the plan while exogenous changes do not. 
	- 2, 7, 13, 15 

### Related
- [[There are scientific and technological problems that make other technology advances irrelevant by altering the environment]]



[Web URL for this note](http://notes.benjaminreinhardt.com/Technical_Planning_Principles)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Technical_Planning_Principles)




Workshops could be a way to start small building a private ARPA

Most roadmaps are not execution oriented

# What are the properties of maps?
# What are the properties of maps
“Maps”, “Mapping”, and “Roadmaps” feel like [[Suitcase Handle Word]]s but  there is a nugget of desire in using them. What are we really yearning for from a map?

- [[Maps are multi-scale]]. You can get some information just by glancing at a map and then more and different information by zooming in.  Fractals were literally discovered by someone mapping coastlines.[[Every time you zoom in on a fractal, it presents the same pattern on a different scale]]. 
	- If a map doesn’t give you something useful on first glance, it’s not doing its job.
		- Most pure-text roadmaps fail on this point - it’s very hard to get something useful on first glance from pure text unless it has a well crafted outline. 
	- If you can’t get different useful things when you investigate a map more closely it’s not doing its job. 
-  [[Maps help you understand the state of something]].
	- If you don’t understand the state of something better after looking at a map, it’s not doing its job. 
- [[Maps help you figure out possibilities]]. Even the medieval T-O map let you know that you could get to Africa from Europe by crossing the mediterranean.  
	- *Roadmaps* explicitly point out those possibilities in an opinionated way. 
	- If you can’t figure out possible (and unallowable moves) from a map, it’s not doing its job.

![](BearImages/A1F27DD7-DF6B-467B-96E4-599D26CC393D-32352-00023ECE922974A5/DEE0FD40-B247-4C7C-82BD-5CB1EB003417.png)

### Types of maps
- Conceptual 

### Related
- [[Wardley Maps]]



[Web URL for this note](http://notes.benjaminreinhardt.com/What_are_the_properties_of_maps)

[Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/What_are_the_properties_of_maps)




Benʼs working notes

Maps are multi-scale

Related

Links to this note