“There is no compression algorithm for experience.” The line is Andy Jassy’s, and it’s the unsentimental answer to the question every senior leader eventually faces: how do I transfer my judgment so the team can decide well without me?
Rituals and artifacts handle the what and the when of work. This is about the how we decide — the cultural toolkit that keeps the team’s judgment honest when the leader isn’t in the room. Three instruments, in order of force.
Principles — gestures towards goodness
A principle is a gesture towards what good looks like. When a team picks a technology, designs a ritual, implements a pattern, or chooses a library, principles are what people pause and check the choice against. They are usually broad — spanning teams, products, often the whole organisation.
Examples Wilco has used:
- “Don’t wake me up at night.” Especially relevant for ETL and batch systems. Engineer the pipeline so that if something fails at 3 a.m., you can think “I’ll look at that tomorrow” and go back to sleep.
- “The holiday rule.” If a technical component has fewer than two colleagues who can support it, you’re not allowed to go on holiday. Either grow the bench or simplify the component.
- “Bias for action.” When the choice is between waiting and doing, pick something. Ask: what new information will waiting actually produce, and how much better will the decision be with it?
Trade-offs — principles with weight
A trade-off is a principle with an explicit thumb on the scale. It names two goods that compete and tells the team which one wins under normal circumstances. Trade-offs are tie-breakers — they give weight to arguments when the leader isn’t in the room.
They are usually narrower than principles, specific to a product, a layer, or a team. A B2C front-end team’s trade-offs will often invert a back-end ETL team’s.
The format matters: name both sides, then say which one tips the scale.
- Reliability over speed.
- Lazy over eager loading.
- The Agile Manifesto’s “individuals and interactions over processes and tools” is the most famous example of all.
Rules — to be broken
A rule is a petrified principle: explicit, unambiguous, no interpretation. “Never use MongoDB in production.” “Don’t use FIFO queues.” The leader has reasons; the team is expected to follow.
The “to be broken” part is essential. Rules that can’t be broken become dogmas, and dogmas signal a team that has stopped thinking. The shape that works: a rule can be broken, but only by someone who does the work to convince the rest. A senior engineer with a working POC and a coherent argument can break a rule; a junior engineer with a hunch cannot. The act of breaking a rule, well, is how a team grows its seniors.
How to start
Sit down for an hour or two. Open a page — Notion, Confluence, a wiki, anywhere shared. List the principles, trade-offs, and rules you actually use, and give each one a paragraph or two of why, not just what.
Then watch what happens. The questions colleagues ask, the objections they bring, the examples you find yourself reaching for — those are the next paragraphs. The document grows quickly, then stabilises. When it does, take a good look: there’s a lot of you in it, and that’s the point.