Principles and discomfort

Almost every company or team has some kind of list of “principles”. It seems like a reasonable thing to do - we should stake out a position that says who we are and what we value, right?

But usually these are more like goals or aspirations than truly helpful principles that can be used to make decisions on a daily basis. The reason is that they’re mostly a grab bag of hard-to-argue-with ideals - “quality matters”, “go fast”, “every voice matters”, etc.

But the reality is, principles only really matter, and only really show up, when there is a conflict, a constraint, or a real choice to be made. “quality matters”? Ok, but what happens when the schedule is behind, or there’s an important demo or milestone or deal? Does quality go out the door then? If so, then the real principle is more like “quality matters unless we’re in a hurry”. Which is less fun to put on a poster.

This isn’t to say that teams shouldn’t have cultural principles, or shouldn’t write them down. But they should be written with an eye towards tradeoffs and priorities. One way to do this might be to list them in a strict order, if you can. What’s more important, speed or tech debt? What things do you explicitly contemplate not doing? Can you write those down? How does conflict work, both between team members or projects and between principles?

“Disagree and commit” is one of my favorite expressions of this kind of principle. If you unpack it a bit, what it really is saying is: “we have a principle of listening and debating that’s important, but being able to execute is even more important, so we agree that there is a point where, even if we disagree, we will do so explicitly and promptly, set it aside, and commit to moving forward together on what’s been decided even if we don’t agree with it”. “Commit” is the principle that wins over “agree” or “reach consensus”.

If you’ve built distributed systems, you’ve heard of the CAP theorem. It says that you can’t really have all three of consistency, availability (in a particular sense) and partition tolerance in a service. Sometimes you are in a state where that doesn’t matter - the network is healthy, the load is good, everything works, and you don’t really have to give anything up right at the moment. But as soon as there is stress in the system - a server goes down, the network partitions, etc, whatever choice you’ve implicitly or explicitly made in your design (essentially the “principles” of the design) will manifest itself.

In a similar way, if your company adopts principles that are fundamentally impossible to achieve all at once, you may have periods of low stress where they appear to all be followed. But there will inevitably be a period of higher stress, and again, whatever the real choices are will manifest, because they have to.

Successful organizations think carefully about these constraints and collisions, and design their principles not as a grab bag of good things that they hope for, but as an explicit, ordered (by importance), list of “must do” and “won’t do” statements.