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

Comment on this note