The structure of a principle

We had a bit of weather recently, and while waiting for electricity to come back on, I found myself flipping through the pages of The Timeless Way of Building by Christopher Alexander. I was re-reading the chapter about the structure of patterns when something clicked. I realized that patterns and well-learned organizational principles are very similar in structure.

Principles are a big thing in today’s organizations. Most want to have them, yet few get to benefit from them. It is fairly easy to list out a bunch of “things we wish to be true”. But how do I make them actually useful to my team? A sound principle is like a pattern in this regard: it helps navigate a tension that is otherwise difficult to grasp. A principle is only an aspiration if it simply points at the desired destination without doing the hard work of capturing the challenges that will make reaching this destination difficult. Put it differently, if a principle doesn’t wrestle with some tension, it’s probably not a principle.

Borrowing from Alexander’s playbook, my guess is that a sound principle will have this structure: it will begin with the context, describing the situation in a way that is resonant to the team. Then, it will point out the forces that are present within this context — these forces are usually in tension with each other. Then, it will provide guidance (Alexander calls it “configuration”) on how to navigate this tension. Another thing that stood out for me was Alexander’s pursuit to get the name of the pattern right. Similarly, the few words that capture the nature of the principle will become the team’s shorthand, the intuitive handle. It’s worth a bit of extra wordsmithing to make that handle fit like a well-built tool in the team’s collective minds. 

To play with this idea, I decided to use a principle from an org I used to lead. We dubbed it “Treat 1P like 3P.” It was a simple phrase, but it seemed to have been useful: it helped resolve conversations about priorities, serving as a planning and strategy tool. Let’s see if I can retcon that principle into the structure above.

We’ll start with framing the broader context.

Our team ships a developer surface to both internal and external customers. We are at the early stage of our journey, where most of our customers are internal, but we expect the ratio to shift toward external customers over time. The internal customers sit right next to us. We know their workflows and tools. We work at the same company. We  can talk easily to them and partner with them as well as coordinate our plans. The external customers work at other companies, and we often have no easy way to communicate with them. At the start, we only have some guesses about what tools and workflows they might use, but we know for sure they will be different from the custom stack of our internal customers.

Next, we point out the forces that operate within this context. There are two: availability bias and technical debt.

Availability bias. Proximity, familiarity, and general alignment of values creates an incentive toward first-party customers. The path of least resistance leads to shaping our developer surface closely to fit the tools and workflows of internal customers.

Technical debt. Knowing that the internal/external ratio will shift over time, we need to be cognizant that overfitting to the needs of internal customers will incur the cost of painful future migration to a more flexible architecture.

Now that the forces are defined and it’s fairly easy to see how they are in tension, let’s provide guidance on how to navigate that tension.

We recognize that the availability bias is a short-term force, and technical debt is a long-term force. We expect that the short-term force will generally prevail in day-to-day decisions, so we lean a bit toward the long-term force. To do so, we treat our internal customers as if they were a kind of an external customer. We avoid embedding any special knowledge of the internal customer-specific stack. We do research on other potential stacks and ensure that our architecture is flexible enough to support them.

Finally, the handle. Within our team, we called internal customers “1P” and external customers “3P,” so “Treat 1P like 3P” ended up working nicely: it was easy to say and remember while conveying the gist of the guidance.

Looking back, this is not how I structured the principle. Instead, it was just a brief paragraph of words beneath the title. But now that I’ve gone through the exercise, I am noticing something interesting: I want to argue with my past self about the context and the nature of the forces that I was seeing back then. This is probably the most powerful part of structuring principles like that: it allows your team to examine the principle, understand how you arrived at it, and help you make it more sound by presenting their own perspectives.