Program design is a coordination tool

From Understanding programs and projects—oh, there’s a difference!: 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 Dancoland/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


There are several takeaways from treating program design seriously as a coordination mechanism.


Andy Matuschak points out that this description of program design clashes with the story of J.C.R. 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.
    • 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.



^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

Comment on this note