Stages of customer-centric maturitythe day beforeWhile riffing on customer-centric mindsets and the veering toward first-order effects pattern,…
The structure of a principle
Organizational pathology2022I was reading the latest book by Richard Rumelt, The Crux, and…
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.
Build a thing to build the thing2023When building new products, there’s always a weird tension between making something…
Why will this be hard for us?2021I was working on a strategy and helping review another this week,…
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.
The Four Needs Framework2020The stories we tell ourselves shape how we see the world around…
Lenses, framings, and models2022At a meeting this week, I realized that I use the terms…
Steady winds, doldrums, and hurricanes2023It just so happened that this year, many of my friends and…

What the heck is 3P?2021I hear folks using the terms “3P,” “1P,” and even “2P” or…
Own the tension2021A couple of this week’s conversations about platform/product team interactions led to…
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.
Live as our customer2023This principle is something that feels very intuitive at first blush, but…
Doers, Thinkers, and Magicians2023I’ve been reflecting on my experiences of working with developers and developer…
Developer surface2021I mentioned this concept before, and I feel like it’s worth expanding…
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.
Nudges, boosts, bumpers, and tilts2023Using these two properties as axes, we can draw a nice –…
Next, we point out the forces that operate within this context. There are two: availability bias and technical debt.
The productification trap2021Picking up on last week’s 3P insight, I want to share some…
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.
Shadows and Curses2022The second curse can be seen as the interplay between “ 🔮…
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.
The tension between Agency and Belonging2020Though there are many books written and movies made with heroes and…
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.
Cutting or highlighting?2021Talking with one of my wise colleagues, we arrived at this neat…
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.
Weak opinions, strongly held2021Chatting with one of my coworkers, we recognized that there’s a pattern…
Slow downfour days afterI wrote this one primarily for myself, though I believe it’s good…
Beyond pros and conslinks here, 2023First, start with the principles. What are the attributes of the solution…
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.
Show 4 comments
Dew Drop – November 1, 2021 (#3549) – Morning Dew by Alvin Ashcraft linked here · November 1, 2021
[…] The structure of a principle (Dimitri Glazkov) […]
Dew Drop – November 1, 2021 (#3549) - Online Code Generator linked here · November 1, 2021
[…] The structure of a principle (Dimitri Glazkov) […]
➧Dew Drop – November 1, 2021 (#3549) • Softbranchdevelopers linked here · November 1, 2021
[…] Book (Advanced Installer Team) Configure build step into a Jenkins pipeline (Ciprian Burca) The structure of a principle (Dimitri Glazkov) A Manager’s Ultimate Guide To Effective Succession Planning (Kat Boogaard) […]
Beyond pros and cons – Dimitri Glazkov linked here · February 4, 2023
[…] of often-conflicting wishes. If you’re new to the concept of principle-crafting, check out this handy guide I wrote a while […]