A motor and a rudder

Having done a bit of work on researching and sketching out strategies this week, I realized that there are some commonalities in their theories of change, a few patterns that I start seeing.

The first pattern is what I want to call a “motor.” Every effective theory of change seems to have a means for sustaining the process of change. When drawing out boxes and arrows in such theories, eventually a motor pops out as a cycle of causal relationships: if we do more of this, more of that will happen, which will allow us to do more of this, etc. It can be something that involves network effects (aka flywheel), or it can be something as simple as “if we deliver <blah>, we get funded to deliver more <blah>.” In either case, there’s something that serves as a source of energy, allowing us to keep going. There doesn’t have to be just one. Just like in any reliable ship, several motors are useful for redundancy. Conversely, if our theory of change is just linear sequences of steps, chances are that it’s not a very durable one.

The second pattern is a “rudder.” Now that we’ve powered the tiny ship of our theory of change with a motor, we need a way to steer it. A rudder manifests as causal arrows that interact with the object of change. They also look like a cycle, but here, they will look more like an OODA loop: ship something, get feedback, adjust, ship something again, etc. 

Rudders are critical to a sound theory of change. Change rarely happens in one big splash, and our ideas about the effects of the change tend to seem naive and silly when they make contact with reality. For example, back in the Web Platform days, I kept trying to build more rudders: from Origin Trials to Web Confluence to Lighthouse.

Next time when you’re in a strategic thinking mood, consider your theory of change, be that the one of your organization, your team, or your own. What are its motors? What are its rudders? How do you power and steer the ship of your destiny?

Forces of the pace layering confusion

I had a super-insightful conversation this week with a colleague about approaches to resolving pace layering confusion. For those of you who haven’t heard of it, Steward Brand’s concept of pace layers is something I’ve often applied to layering in software engineering: the lower the layer, the more stable it is. The higher the layer, the faster it innovates. For a canonical example, Web sites innovate faster than JS frameworks. JS frameworks move faster than browsers. Browsers typically get updated faster than the operating systems they run on. The pace layering confusion refers to the situation when a project is scoped to span more than one layer. These projects typically encounter constant friction and a shearing force that is caused by the pace layers moving at different pace.

We’ve been looking at a project that is currently caught in this trap, and found a peculiar tension: there seems to be forces that are both trying to split the project up along the pace layer and forces that are trying to keep it together. These forces are distributed quite evenly: the same team members who advocate for a “more platform-like” approach (a proper splitting up at the layer boundary) are skittish about taking the step. And it makes sense: monoliths deliver. From the tougher time to land commits to the lesser degree of control, one more API boundary adds a not insignificant cost. What’s even more troubling, once separated, it might not be clear where the lower layer code will live.  Especially when a project is facing tight shipping deadlines, the work of extracting out and maintaining the bits of the layer that doesn’t directly contribute to the product is unlikely to have any mindshare. Why would a product team have a sub-team that’s making a framework? So the project gets stuck in this twilight-zone mode of “we want to move faster, but something is holding us back.”

If you find yourself in a situation that feels that way, it might be a good use of your team’s time to have a pace layering discussion. Is there a weird force that tries to pry your team apart along a yet-invisible seam? How much energy are you spending on counteracting the force of the pacing layer confusion? What might be the code that wants to live at a lower pace layer?

If you’re lucky, there might already be an adjacent team that makes its living at that lower layer. In this case, a conversation about a strategy for transitioning the lower-layer bits ownership to them might be a good first step. Otherwise, it might be worth it to go looking for a partner who could play that role.