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.