Three Rules Beat Thirty Pages

The incident review ends the way incident reviews end. Somebody proposes a new paragraph for the process document. Nobody objects, because objecting to a new rule sounds like you want the outage to happen again. The paragraph goes in, right below the one from last quarter’s incident, which sits below the one from the quarter before that.

I have never seen anyone propose removing a paragraph in that meeting. Not once, at any company. The document only grows, and the page count gets read as how seriously the team takes quality.

Underneath that meeting is a belief almost every leader holds without ever saying it out loud. Complex results need complex systems to produce them, and a few simple rules could never be enough. If you want a team that handles every situation, you write down every situation. The output is rich, so the instructions should be rich too, and a thick document feels like control.

It is wrong, and the evidence that it is wrong is everywhere you look.

The myth

The belief shows up in a few standard shapes: the forty-page engineering handbook, the twelve-step definition of done, the RACI chart that assigns an owner to every decision the org can imagine, and lately the agent guideline document that runs longer than the code it governs.

Each of these is built on the same logic. The output we want is sophisticated, so the instructions must be sophisticated. If a person could handle a situation we did not write down, we got lucky, and luck is not a process. So we write down more situations.

It seems logical because it treats the team like a machine you are assembling. A machine does exactly what its parts specify, so more parts means more capability. Add a paragraph and the machine covers more ground.

Teams are not machines, and neither is anything else that produces rich results, by which I mean work that is varied, coherent, and adapted to conditions nobody specified in advance. If you are machining a part, you want the drawing complete. This piece is about work done by people, and lately by models, making judgment calls at the moment they meet the work, and for that kind of work the drawing is the wrong tool.

Why simple rules create complex results

Watch a starling murmuration, several thousand birds turning as one shape over a field at dusk. The shape has edges, density, a direction, and it changes faster than any bird could receive an instruction. There is no lead bird. Nobody is flying the flock.

In 1986, Craig Reynolds reproduced the whole thing in software with three rules. Do not crowd your neighbors. Steer the way your neighbors are steering. Move toward the average position of your neighbors. Each simulated bird looked only at the birds near it. Three local rules, no global plan, and the screen filled with a flock that looked alive. Two decades later, a team in Rome tracked real starlings and found that each bird follows about six or seven of its nearest neighbors, regardless of how far away they are. The murmuration is the sum of that, repeated by every bird, constantly. That is what emergence means: a pattern nobody specified, produced by everyone applying the same few rules at every interaction. And the count is not a slogan. Take away any one of Reynolds’s three rules and the simulated flock either scatters or collapses into a clump. The number of rules is however many it takes to cover the interactions that matter, and not one more.

In 1970, John Conway wrote four rules for cells on a grid. A live cell with two or three live neighbors survives. A dead cell with exactly three live neighbors comes alive. Everything else dies or stays dead. That is the whole specification. Out of those four rules come gliders that walk across the grid, oscillators, guns that fire gliders on a schedule, and, eventually, patterns that can compute anything a computer can compute. A universal machine, from four lines of rules.

Toyota’s version fit on a cord. Any worker on the line can pull it and stop production. One rule, run by everyone, at the moment they see the problem. It produced a quality standard that no inspection department, no matter how many pages it had, had ever reached.

The oldest version I know is Sparta. Plutarch writes that Lycurgus set the city’s founding laws, and that one of them forbade writing the laws down. He held that the things that mattered most to a city’s welfare had to be trained into citizens by habit, because a rule you have to look up is a rule you do not have. The city ran for centuries on a small body of law that everyone carried in their head.

Then there is the file on my desk that runs the agents. It is short. Run the tests before you say done. Do not touch anything that moves money or identity without a human in the loop. Keep a change small enough to read in one sitting. A few hard rules and a smart model, and the work that comes back is more varied than anything I could have written a spec for. Refactors I did not ask for that were right. A test that caught something I introduced an hour earlier. I wrote about what belongs in that harness already, and the short version is that the harness holds what I cannot afford to guess and nothing else. Everything volatile lives in a prompt I can edit on a Tuesday.

John Gall put a name on the pattern in 1975. A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and you cannot patch it into working. Every example above started small and stayed small at the rule level. The complexity is in the result, and it was never in the instructions.

The hidden cost of a thick rulebook

The forty-page document does more damage than wasting the time it took to write.

Case law kills judgment. When the document has a paragraph for every situation, people stop asking what the point is and start asking what the rule is. That works right up to the situation nobody wrote down, which is the one that matters, and it is the situation your team now handles worst, because the habit of thinking it through has been trained out of them. You asked them to look things up, and they learned to look things up.

Every paragraph is also a decision somebody made once and did not want to make again, so they wrote it down instead of writing the rule that would have made the decision obvious, and the document turns into the author’s memory. Do that for three years and the document is a diary of one person’s judgment calls, and reading it does not transfer the judgment. I have written before about the person who overcomplicates to look thorough. This is the team-scale version, and it is worse, because nobody owns it.

The document needs the author in the room. A rule that a new hire cannot run on day one without asking is a decision the author kept for themselves. Last month I wrote about an agent that followed the documented process exactly and broke the on-call rotation, because the humans had been running a different process for two years. The document was long, and it was nobody’s actual rules.

A watch is complicated: many parts, one designer, and it stops when any part fails. A flock is complex, with few rules and no designer, and it keeps its shape when a hundred birds drop out. A forty-page process is a watch. Pull one step, one owner, one tool, and the whole thing stalls until someone rewrites the page.

And the document cannot keep up. A rule that needs to change every six months cannot live in a document that gets revised every two years. So the document stays wrong for eighteen months at a time, and everyone learns that the real rules are somewhere else.

Some pages do have to exist. An auditor wants a record, a security review wants a record, and a regulator wants a record. Keep the record where the record is demanded, and keep it separate from the rules. The record is for the auditor, the rules are for the person at the moment of decision, and a team that mistakes one for the other ends up with neither.

What a real rule looks like

Design the rules, and stop trying to design the result.

Good rules have three properties. There are few of them, three to five, because every rule past that is one the team will not carry in its head. Each one is local, describing what one person does at the moment they meet a piece of work or another person, rather than what the org should produce by the end of the quarter. And anyone can run one without asking, on day one, with the author nowhere near the room.

Then you do the part the forty-page document never allows. You watch what comes out. The result is not specified in advance. If it is wrong, change one rule and wait to see what the new shape looks like, instead of adding a page.

The Greek word for this kind of rule is arche, which means beginning and ruling principle at once, the origin of a thing and the source that keeps governing it. A real rule is an arche. It starts the behavior and it governs the behavior every time the behavior happens. The thick document has no arche in it anywhere. It has cases, and a case governs nothing except the situation it describes.

What does an arche look like in an engineering org? Anyone can stop a release, and when they do, they say so in the channel. If you touch it, you test it. A change is small enough to review before lunch. The person closest to the customer makes the call. Each of those runs at the interaction level, by anyone, without a meeting, and each one produces most of what the forty pages were reaching for. Stop-the-release produces the quality section on its own, touch-it-test-it produces the testing section, and small-enough-to-review covers half the code review guide and most of the deployment guide.

A rule only counts once the team carries it as habit, which is what Lycurgus was after. The rule is the habit the sentence names, and habits come from repetition. So the first weeks after you cut the document are spent running the three rules out loud, in the channel, every time they apply, until nobody needs the reminder and the sentence can go back to being a sentence.

Rules like these travel, which is the other thing the document cannot do. A practice copied from another company arrives without the conditions that made it work, and I have argued before that you should steal the principle, not the playbook. An arche is the principle. It does not care what tools you run or how big the team is.

How to cut thirty pages down to three rules

Five moves, in order.

1. Count your real rules. Print the process document. Circle every sentence a new hire could run on day one at the moment of decision without asking anyone. That number is your rule count. Expect a handful of circles in thirty pages. The rest is the author’s memory.

2. Find the three. Ask which behaviors, if every person on the team did them every single time, would produce most of what the document wants. Write those at the interaction level: when you meet this, do this. If a rule needs a paragraph of conditions, it is a case, and you have not found the rule yet.

3. Delete the case law. Every paragraph that begins with “in the event that” is a situation you did not trust the rule to cover. Cut it. Then watch whether the rule covers it. Most of the time it does, and when it does not, you have found the weak rule.

4. Tune the rule, not the outcome. When the emergent result is wrong, resist the paragraph. Change one rule, tell the team, and wait two weeks. The result of a rule change shows up in the shape of the work, and you cannot read the shape until enough interactions have run. The rules and the tuning are yours, and the result in any given week is not, because the market moves and people leave and rules take time to become habits. A bad week with good rules tells you about the week.

5. Put the volatile rules where they can change on Tuesday. The pinned message in the channel. The prompt. The file the agents read. If a rule changes with the market, the model, or the quarter, it does not belong in a handbook that changes with the fiscal year. The rules I edit most often live in plain text the model reads, and I change them the afternoon I learn something. Two things to keep straight here. The pinned message is where a rule gets learned, and it has to be short enough that nobody opens it at the moment of decision, or it is a handbook with a shorter scroll. The file the agents read is different in kind. That file is the model’s memory, and the model reads all of it every time by design, which is the one place where writing the rule down and carrying it are the same act.

The test

This applies whether or not you own the document. An engineer who never touches the handbook can carry three rules for their own work and stop asking for a page. A lead running two people owes the same count as a VP running two hundred. The authority to delete pages is not what makes the discipline yours.

Take the last rule your team added. Could the person it applies to have derived it from the rules you already had?

If yes, you added a page, and the page will be ignored by everyone who could already derive it and misread by everyone who could not.

If no, ask why the rule they had did not cover it. That is the rule to fix. Fixing it will cover this case and the next twenty you have not seen yet, and the paragraph would have covered one.

Final Thoughts

Nobody is flying the flock. The shape comes from every bird doing three things with its neighbors, and it is more alive than anything a lead bird could have directed. Your job as the leader moves in that picture, from directing the work to writing the rules and tuning them, and the new job is harder than the one it replaces.

The leaders I have watched get rich, adaptive work out of a team did not write more than the others. They wrote less, wrote it better, and then watched instead of adding pages. How seriously a team takes its work shows in whether the three rules everyone can run are any good, and the page count says nothing about that.

Finding your team’s three rules is harder than writing thirty pages, because you have to know what the work is made of. That is the kind of question MasteryLab exists to work through with builders.

FAQ

What is emergence in simple terms?

Emergence is when a group of parts following a few simple local rules produces a large pattern that none of the parts planned and nobody is directing. A starling murmuration is the standard example: each bird tracks only its nearest neighbors, and the whole flock forms one coherent shape with no leader. The pattern belongs to the rules, not to any individual bird.

Why do simple rules create complex behavior?

Because each rule runs locally, at every interaction, by every participant, and the interactions compound. Three rules applied by a thousand birds thousands of times a second produce more variety than any central plan could specify, and the result adapts when conditions change because every participant is still applying the rules. A thick rulebook tries to specify the result directly, so it only covers the cases someone already thought of.

How many rules should a team have?

Three to five that people can run without asking anyone. The test is whether a new hire could apply the rule on day one at the moment of decision. A rule that requires the author in the room to interpret is a decision the author kept. Most forty-page process documents contain three or four real rules and thirty-six pages of case law written after incidents.

What is Gall’s law?

Gall’s law, from John Gall’s 1975 book Systemantics, states that a complex system that works is invariably found to have evolved from a simple system that worked, and that a complex system designed from scratch never works and cannot be patched up to make it work. For teams, it means you start with a few rules that work and let the system grow from there, rather than designing the full process up front.