Week of 2021-10-29
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.
🔗 https://glazkov.com/2021/10/29/the-structure-of-a-principle/
Slow down
I wrote this one primarily for myself, though I believe it’s good advice for anyone who’s ever found themselves in a leadership role in today’s work environment. Here it is: slow down.
I am not talking about taking some time off, going on a digital vacation, or just relaxing a bit in the evening and doing some light reading. Those things are great and important parts of our lives all in themselves. When I say “slow down,” I mean slowing down at work: to remain surrounded by work, but take time to reflect on what’s happening. When I was developing my self-work routine, I had this metaphor of a riverbank that might be useful here. Slowing down means stepping out of the turbulent river of our daily work and sitting on the riverbank for a little bit. Pause. Look around. Are we still going where we want to go? Or are we being carried by the river?
Think of it this way: we’ve learned to go fast, we’ve honed our effectiveness, ways to put the pedal to the metal. Today, our problem is not that we are lazy. It’s that our undercurrent of achieving is too strong. Through this lens, procrastination can be a shaming word for having patience to let the solution reveal itself. And when we start getting worried that we’re not achieving fast enough, we get further trapped in the churn of the river.
In Adult Development Theory, there’s this notion of fallback. A metaphor for it that I really like is that our minds are houses with rooms, where some rooms become inaccessible during fallback. It’s like we know our house has them, but we just can’t find our way to them. So while in fallback, if we want to go to the Strategy room and do some long-term thinking, we keep finding ourselves in the Tactics room, covered in glitter and glue of the short-term fixes. There are many causes of fallback, and in my experience, the achiever stress is not an uncommon one.
As we fall back, our perspective narrows. We can no longer see options and opportunities that are locked away in those now-inaccessible rooms, and it feels right and natural to just keep doing what we’re doing. A deadline is coming up, so of course we need to jump on that. Our colleague needs to meet, so yes, we’ll find the time. And as we just keep on swimming, we find our schedules getting busier and pace continuing to rise. We keep going faster and faster. In the moment when we need to open some space to think, taking an even little pause feels like the wrong thing to do: who’s going to do all this work?
Those of you who work with me know that I have my late Friday afternoon blocked off for reflection. I have three questions that I pose for myself. They are loosely: 1) what did I do this week? 2) am I losing sight of the big picture? and 3) what might I change in how I conduct my next week? This is my time to slow down. No matter how high the fires are, and how urgent the pings to meet, I try to spend this time sitting on the riverbank. Sometimes it doesn’t work, though over time, I am realizing that the trick is to keep trying. Keep trying to slow down.