# Program design is a coordination tool From [[weaverUnderstandingProgramsProjects2010]]: **Programs** *focus on the coordination of a number of related projects and other activities, over time, to deliver benefits to the organization*. (Contra projects) Unlike something like architecting a building, the point of doing[[§Program Design]][^1] is not to create a blueprint that encodes all the information of the process and can be handed off to someone to execute on. In this sense, it’s a misnomer to call it “program design” and to call the resulting artifact a “roadmap.” Both of these terms imply a process whose main goal is to produce something static that can be separated from the people involved. In reality the goal is to create a shared purpose (in the [[dancoWelcomeDancoland2021]]/[[Complex System]] sense)[^2] and then maintain that shared purpose. Program design coordinates people in three distinct ways: 1. The process creates is a Schelling point for ongoing *purpose maintenance*. [[Program design creates Schelling points for purpose maintenance]] 2. The design process’ output isn’t just the artifact but is also connectivity between people, a shared understanding about who has what role, and a shared context between the people who are going to participate in the program. [[The most important role of program design is to build a shared context and connectivity between stakeholders]] 3. The process of *doing* program design itself is a coordination mechanism both between levels of a hierarchy and within levels of that hierarchy. [[The process of program design itself surfaces information through iterative feedback loops]] ### Upshots There are several takeaways from treating program design seriously as a coordination mechanism. * [[Roadmaps need to be coupled to people]] except in situations where 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 [[International Roadmap for Devices and Systems]]. * [[Speeding up program design requires sales or power]]. * [[Good program design can’t exist in isolation]] ### Pushbacks [[Andy Matuschak]] points out that this description of program design clashes with the story of [[JCR Licklider]]. Instead of an iterated process of understanding the state of a field and finding a target point that aligns the various stakeholders <[[Stakeholders are sometimes the maximum level of precision for complex systems]]>, Lick (the story goes) had a vision and did a combination of funding the few people who shared it and forced other people to go along with it by threatening their other funding. It’s the difference between 1. Going around a boat and finding a mutually acceptable way for everybody to row and 2. Only letting the people who will to row the way you want to row on the boat in the first place. There are several corollary questions here: * Is the program manager’s role primarily *selection* and then acting as a communication facilitator OR is it primarily *alignment* and then acting as a shepherd and communicator to maintain that alignment? Another framing might be “getting the right people in the room” vs “getting the relevant people in the room and then making them work together.” * * Is there a spectrum between those two roles? It feels that way. [[Programs and Program Managers exist on several different spectra]] * Does the state of the world and a program manager’s power affect how program management needs to happen? Lick was hooked into some of the only sources of funding and had a lot of money, which allowed him to both enable people to spin up entire labs from scratch and put pressure on existing labs. * How hard would it be to spin up a lab that wouldn’t exist otherwise in a university? * Is there a way to “spin up a lab” outside of the university? * Does this only work with low enough equipment costs that you don’t need to have accumulated equipment over years? * There’s something about the gap between what people say they’re doing and what they’re actually doing that makes this whole thing very sticky. * There are many more people doing research <[[Research can mean drastically different things]]> on many different areas so finding people who aren’t at least adjacent to a thing is harder. Which means that no matter what you want to do you’re probably going to be at least nominally adjacent to what someone else is working on. <[[“There’s a startup for that” is a harmful dogma]]> * Does this suggest that the sorts of programs PARPA can undertake is also constrained by how many people are working adjacent to the area? * Does the roadmap-as-coordination only work for incremental things that already have momentum like Semiconductors? * Have there been successful programs where the program manager didn’t come in with a strong vision from day one? * If it is the case that every successful program needs a Lick-style PM, where did the person create the vision from in the first place? * The assumption would be that it was primarily brewed in their own head from experiences? Is there more value to visions that come from experiences vs. conversations that are specifically for the purpose? * [[Can you only come at powerful visions sideways?]] * [[DARPA’s Process for Creating New Programs]] suggests that the answer is yes. ### References * [[Stephen Dean podcast 20 Aug 2021]] * The [[The International Technology Roadmap for Semiconductors]] is widely acclaimed as one of the most successful roadmaps *because* it enables this coordination. ### Related * [[DARPA is a coordination mechanism]] * [[Plans are coordination mechanisms]] * [[PARPA is a coordination mechanism]] * [[Coordination Problems]] * [[Centralized coordination makes sure effort is not being repeated in stupid ways]] * [[The less shared context you have the higher the coordination costs]] * [[Centralized coordination sometimes stops effort from being repeated in smart ways]] * One thing that does need to be decided up front is what organizational form the program will take. 2021 culture is heavily biased towards programs being structured as high-growth startups so answering the question [[When should an idea that smells like research be a startup?]] is important. * [[Areas programs and projects are distinct but often confused]] * [[Programs and Program Managers exist on several different spectra]] [^1]: Note that as of at least [[3 Sep 2021]] I’m still feeling around what program design actually *is* but you can still make assertions about a [[Nebulous]] thing. [^2]: At least as of [[8 Sep 2021]] I find this to be a really powerful concept to think about the equivalent for a “goal” in complex systems to sidestep the pressure to either think about goals or simply the things that a productive system *does* like conversations and decisions. [Web URL for this note](http://notes.benjaminreinhardt.com/Program+design+is+a+coordination+tool) [Comment on this note](http://via.hypothes.is/http://notes.benjaminreinhardt.com/Program+design+is+a+coordination+tool)