"The more we standardize the variables and reduce ambiguity, the less complicated things become."

At 4:55 the lights come up on a curve, the song starts, and none of it is a decision.

I wrote that sequence years ago and it has not changed. Lights fade from nothing to something over a couple of minutes. The Verve. Then Chill, then the handoff to the radio, and Jeff Thomas is talking about the Browns to a man who is not yet vertical. Downstairs there is a dresser with a multivitamin and prescriptions on it, in the same place, because a thing that lives in one place is a thing I never look for. Casey gets a good morning. The Diet Pepsi is where Diet Pepsi is.

Nothing in that sequence is impressive and the effect is enormous. From waking to leaving there is exactly one decision in the whole run, which is whether to get up, and I have written elsewhere that the one manual step is the decision to get up. Everything downstream of it is a standardized variable. Time, order, location, sequence, media, and the small objects that would otherwise be looked for.

Tally what that buys. I do not decide what to listen to. I do not decide when to leave. I do not look for the multivitamin, or the keys, or the phone. The mornings are not identical, because mornings are not, but the decisions in them are identical, which means the variance in how the morning goes has almost nothing to do with the morning.

Then the weekend arrives and I run the opposite policy on purpose.

The weekend has a task list, and the list is specified the way work gets specified: floors vacuumed and washed, grass cut and edged, dishwasher run and emptied. What is not specified is anything about when, in what order, or what happens in the hours the list does not fill. Those hours are deliberately unstructured, and I have been clear with myself that structuring them would not produce a better result and would cost something I want.

So the same person, in the same week, runs maximum standardization on one interval and deliberate non-standardization on another, and both are correct. That is the whole chapter. The claim is true, and it is true inside a boundary, and I have been running the boundary by instinct for a decade without ever writing it down.

Stated as a rule:

The variables are the dimensions along which a repeated situation can differ. Time, sequence, place, method, vocabulary, tooling, who does it. Standardizing one means fixing its value across instances rather than choosing each time.

The quantity minimized is the size of the state space. Five variables with four possible values each produce a thousand and twenty-four distinguishable situations. Fix three of them and twelve remain. Nobody has to understand a thousand situations to understand that system, which is what less complicated actually means and why standardizing the variables is not merely a preference for tidiness.

The failure signal is a system where nobody can predict what will happen without asking who is doing it. When the answer to what happens next depends on which person, which shift, or which day, the variables have not been standardized, whatever the documentation says.

The domain of validity is the part the original sentence omits entirely, and the rest of this chapter is about it. The rule holds where cause and effect are knowable, whether or not they are currently known. It inverts where they are not.

The phrase to watch is less complicated. It is doing double duty, and the two duties come apart. One meaning is that the system has fewer distinct states, which is a fact about the system and is exactly what standardization delivers. The other is that the system is easier to work in, which is a fact about people and does not follow automatically. A system can have a small state space and be miserable to operate, and I have built a few.

Claude Shannon gave the first meaning a formal shape in 1948, while working on a problem that had nothing to do with management.

He was asking how much information a message carries, and his answer was that information is a measure of how much uncertainty gets removed. A message that could have been any of a thousand things, and turns out to be one of them, carries more information than a message that could only ever have been one of two. The quantity is entropy, it is measured in bits, and it is a property of the space of possibilities rather than of the message itself.

Turn that around and it says something precise about standardization. Every variable you fix removes possibilities, which lowers the entropy of the system, which reduces the number of bits required to describe any particular state of it. A process with one standard method needs less specification than a process with six acceptable methods, and less specification means less to communicate, less to learn, less to check, and fewer places for two people to be describing different things while using the same words.

The uncomfortable corollary is in the same equation and nobody quotes it. Information is uncertainty removed. A system with no uncertainty transmits nothing. If every variable is fixed, then observing the system tells you nothing you did not already know, which is fine for a morning routine and a serious problem for a system that is supposed to be telling you about the world. A status field that everyone fills in the same way because the rule forces it has become a field that carries no information, and it will still look like data.

The most useful demonstration of the constructive half comes from Toyota, and from an odd angle. Steven Spear and Kent Bowen spent four years inside the production system trying to explain why companies that copied its practices did not get its results, and what they found was four implicit rules rather than a set of techniques. One governs how a worker does the work. One governs how workers connect to each other. One governs how pathways through the plant are constructed. One governs how people learn to improve.

The paradox they lead with is the one this chapter needs. On the one hand, they write, every activity, connection, and production flow in a Toyota factory is rigidly scripted. And at the same time the operation is enormously flexible and responsive. The resolution they propose is the sentence that should be on the wall of anyone who thinks standardization and adaptability are opposites: at Toyota it is the very rigidity of the operations that makes the flexibility possible, because a rigidly specified operation is a continuous series of controlled experiments.

That is the mechanism the original sentence does not state. Standardization does not make things less complicated by making them simpler. It makes them less complicated by making deviation visible. If the standard says the step takes forty seconds and it takes fifty, something happened, and you can see it happened because the forty was written down. Without the standard, fifty seconds is Tuesday.

The evidence is genuinely good here by the standards of this book, and it is narrower than it looks.

Statistical process control, which Chapter 7 takes up properly, rests on exactly this claim and has ninety years of industrial results behind it. A stable process produces a predictable distribution, and it produces one because its variables are held. That is about as well established as anything in operations, and it is a real empirical win rather than a theoretical argument.

Standardized work in manufacturing has a similar record. Where a process is genuinely repeated, specifying content, sequence, timing, and outcome reduces defect rates and cycle-time variance. Weighing that literature chapter and verse is beyond what this book can do, and the direction is not seriously contested.

Three limits belong on the same page.

The first is that nearly all of this evidence comes from manufacturing and from clinical settings with manufacturing-like properties: high volume, short cycles, observable output, and a defect you can define. The work most people reading this actually do has none of those. A service request is not a stamped part. The literature does not cover the transfer.

The second is selection. The processes that get standardized and studied are the ones somebody judged standardizable, which means the sample is drawn from cases where standardizing was already expected to work. Nobody publishes the study where they standardized something unstandardizable and it went badly, because that gets abandoned rather than written up.

The third is that success at standardizing a process is measured, almost always, on the dimension the standard was written for. Cycle time goes down. Whether the thing that got lost was worth more than the cycle time is not measured, because it was not defined, because if it had been defined it would probably have been standardized.

The design problem where I watched all of this happen at once was a status engine.

The situation before: a request's status was a judgment call made by whichever of a few people picked it up, using criteria that had never been written down. The variables were unstandardized in every dimension at once. Different people, different thresholds, different vocabularies for the same state, different moments at which a status got updated, and no rule about who was allowed to change what.

Standardizing it did exactly what the claim promises. The state space collapsed from something nobody could enumerate to a set of named states with written entry conditions. The number of distinguishable situations went from unknown to countable. Two people looking at the same request produced the same answer, and the argument moved from what state is this in to is this the right set of states, which is a much better argument to be having.

And three things went wrong, each of which is an instance of something general.

The first was the case that fit no state. It was not rare, it was maybe one in twenty, and it was always the interesting one. Under the old judgment-based system those requests got handled by somebody noticing they were odd. Under the standardized system they got assigned the nearest state, which made them look like the other requests in that state, which is precisely how they stopped getting noticed. Standardization did not just fail on those. It actively camouflaged them.

The second was that the states started being chosen for their downstream effects rather than for their accuracy, which is the Goodhart problem the chapter on reducing life to quantifiable formulas takes head-on.

The third was slower and worse. The people who had been making the judgment calls stopped making them. That was the intent, and by the stated goal it was a success.

What I did not anticipate is that the judgment had been a byproduct of something else. To classify a request under the old arrangement, a person had to read it. Not skim it for the field that determines the category, because there was no such field. Read it, the whole thing, and form a picture of what was going on at that site with that customer. The classification was the visible output. The picture was the thing that had value, and it was free, because you could not produce the classification without producing the picture.

Standardizing the classification made the picture optional. Nobody decided to stop forming it. The work simply no longer required it, and work that is not required stops happening, not through laziness but through the ordinary operation of a person with eleven other things to do. Within a year the same people who used to know which accounts were about to become a problem no longer knew, and the reason was not that they had gotten worse. It was that the thing that used to make them look had been automated away, and nothing had replaced it, because nobody had known it was there to replace.

That is a general shape and I have not seen it written down anywhere in the standardization literature. A standard substitutes for a judgment. The judgment was produced by an activity. The activity was producing other things nobody was tracking. You can measure everything the standard was built to improve, find it all improved, and be wrong about whether the change was worth making, because the loss is in a quantity that had no name and therefore no baseline. The only honest way I know to guard against it is to ask, before standardizing a judgment, what a person had to do in order to make that judgment, and whether any of it was worth keeping for its own sake.

The boundary has a name, and finding it is the reason this chapter concedes more than any other in the book.

Dave Snowden and Mary Boone laid out a framework in 2007 that separates decision contexts into domains. Two of them are ordered. In the simple or obvious domain, cause and effect are clear to everyone, the action sequence is sense, categorize, respond, and best practice is a legitimate idea. In the complicated domain, cause and effect exist and are knowable but are not apparent without expertise, the sequence is sense, analyze, respond, and what you get is good practice rather than best practice, because there are several defensible answers.

The third domain is where my sentence stops working. In the complex domain, cause and effect are only coherent in retrospect. Right answers, in their phrasing, cannot be ferreted out. The sequence is probe, sense, respond, and what you are after is emergent practice, which means you run small safe experiments and let the pattern show itself. Their warning is unambiguous: leaders who try to impose order in a complex context will fail.

Put the more we standardize the variables and reduce ambiguity, the less complicated things become against that and the collision is total, not partial. The more we standardize the variables and reduce ambiguity, the less complicated things become is a sense-categorize-respond instruction. It is precisely the ordered-domain method. Applied in the complex domain it does not underperform. It suppresses the variation that would have revealed the pattern, which is the only mechanism available for learning what is going on.

And they name the specific trap I am most likely to fall into, which is not the complex domain at all. It is the simple one. The most frequent collapses into chaos, they write, occur because success has bred complacency. A system running smoothly on standardized variables is a system nobody is watching, and it stays fine right up until the conditions it was built for stop holding, at which point it fails without warning, because the warning would have been variation and the variation was engineered out.

Three things the rule cannot see.

It cannot tell which domain it is in. The rule contains no test for whether cause and effect are knowable, and it will be applied with equal confidence either way, because from the inside a complex situation looks like a complicated one you have not analyzed hard enough yet. That is the single most expensive blind spot in the creed.

It cannot see what the eliminated variation was carrying. Variation is noise and it is also the only signal a system produces about conditions nobody anticipated. Removing it removes both, and the original accounts for one.

And it collides with defining every variable to its deepest identifiable condition, though the collision is subtler than the one in the last chapter. Standardizing a variable means fixing its value. Defining it deeply means multiplying the levels at which a value could be fixed. Do both aggressively and you get a standard specified to a depth nobody can follow, which is complication wearing the costume of rigor. The organizations I have seen do this were not being careless. They were obeying two of my rules at once.

The strongest argument against the more we standardize the variables and reduce ambiguity, the less complicated things become is Charles Perrow's, and it is not about ambiguity at all. It is about what standardization does structurally.

Perrow was trying to explain accidents in systems where nobody made a mistake, and he came out with two dimensions. A system's interactions are linear or complex, depending on whether components interact in expected production sequence or through unfamiliar and unintended feedback loops. And a system's coupling is loose or tight, depending on whether it can absorb delay and failure or whether failures propagate immediately with no slack. Systems that are both complex and tightly coupled produce what he called normal accidents: failures that are not the fault of any operator or component and that are properties of the system's shape.

Two of his conclusions go through that sentence like a bullet.

The first is that adding procedures and safety devices increases interactive complexity. Every control added is a component that can fail, and more importantly a component that can interact with other components in ways nobody designed. A check valve installed to prevent backflow becomes a new failure mode. A standard added to eliminate a variation becomes a new thing that can be satisfied while the underlying situation is wrong. The intervention that was supposed to reduce complexity added to it, and did so in the unobserved dimension.

The second is the one I cannot get around. Tight coupling requires centralized control, because a cascading failure gives nobody time to consult. Complex interaction requires decentralized control, because the situations that arise were not anticipated and the person on the spot is the only one who can see what is happening. Those requirements are both real and they contradict. Perrow's conclusion is that they cannot be readily resolved, and that systems with both properties are therefore vulnerable regardless of how well they are managed.

Standardization is the centralizing move. That is what it is. Fixing variables in advance moves decisions from the person present to the person who wrote the standard, and that is the source of every benefit in the first half of this chapter. Perrow's argument is that in a system with complex interactions, that move removes exactly the capacity the system most needs, and it removes it silently, and the removal looks like an improvement on every metric you were tracking.

The strongest form: standardization does not reduce complexity, it relocates it. The state space of the process gets smaller and the state space of the exceptions gets larger, and the exceptions are now handled by people who have been trained not to exercise judgment, using a system that has no representation for the situation they are in. Total complexity went up. It went up somewhere nobody measures, which is why every report says it went down.

I do not have an answer that makes that go away.

Here is what I will actually defend, and it is less than the sentence I have been saying for years.

The claim survives in the ordered domains and is false outside them. Where cause and effect are knowable, standardizing variables reduces the state space, makes deviation visible, and does make things less complicated in both senses. Where cause and effect are knowable only in retrospect, it suppresses the variation that is the only available instrument, and the complex domain is precisely where imposing order fails.

Perrow's relocation argument I accept nearly in full, with one amendment. He is right that standardizing a process enlarges the exception class and that the exceptions are where the danger moves. The amendment is that this is an argument about how to standardize rather than whether. A standard that has no path for the case that does not fit is the one that camouflages the interesting request and strands the person holding it. A standard that names its own boundary, and routes the case outside it to a person rather than forcing it into the nearest box, keeps the reduction and hands the exception to the only thing that can handle it.

That is a design requirement and I did not have it stated. Every standard needs an explicit this does not fit path, that path has to be cheap enough to use, and the rate at which it gets used is the instrument that tells you whether the standard still matches the world. An exception rate that is falling is not necessarily good news. It may mean the boundary is being ignored.

On telling the two domains apart, which I have called the most expensive blind spot in the creed and then deferred, here is a first cut, offered as a working heuristic and not as the instrument. Three questions, none of them requiring expertise in the domain.

Does anyone have a track record of predicting what will happen here? Not explaining afterward, which is always available, but saying in advance and being right more often than chance. Where such people exist, cause and effect are knowable and you are in the ordered domains whatever the situation feels like. Where the people who look most expert are only ever right in retrospect, that is the signature of complexity, and it is detectable without understanding the subject matter.

Does the same intervention produce the same result? Run it twice. In the ordered domains the second run resembles the first. In the complex domain the system has responded to the first intervention and the second one is acting on a different system.

And does describing the situation accurately to a newcomer let them handle it? Complicated problems transfer through explanation; that is what makes expertise teachable. Complex ones do not, and the tell is the experienced person who cannot say why they did what they did, because there was no why that existed before the doing.

None of those is decisive and all three are cheap. Chapter 18 is where they get replaced by something sharper.

Toyota's rigidity is not a counterexample to Perrow, it is the same point from the other side. The reason rigid specification produces flexibility there is that the specification makes deviation visible and something happens when it is visible. The rigidity is the measuring instrument, not the goal. Copy the rigidity without the response to deviation and you have built the thing Perrow warns about: a tightly coupled system that has removed local judgment and gained nothing in exchange.

And the morning holds, for the reason the weekend does not. Getting dressed in the dark at 4:55 is the simple domain. The variables are knowable, the conditions are stable, the interactions are not complex, nothing is tightly coupled to anything, and the exception path is that I can simply do something else. The unstructured weekend hours are not the complex domain exactly; they are something the framework does not address, which is a decision I have made about what I want rather than about what works. Chapter 15 handles that distinction, because I prefer it this way and the method fails here are different claims and my boundary ism currently runs them together.

What survives:

The original claimed a monotonic relationship: more standardization, less complication, always. The revision makes it domain-dependent and adds the exception path, which was never in the sentence and without which the rule builds exactly the tightly coupled, complexly interacting system Perrow's normal accidents are made of.

Three things go forward unresolved. There is no test in the creed for telling a complicated situation from a complex one, and every chapter after this one depends on having one; Chapter 18 builds it. Perrow's relocation argument is answered with a design requirement rather than refuted, and I am not certain a design requirement is enough. And the honest accounting of what gets lost when judgment is removed remains unmeasured, in this chapter and in the field, because the thing lost was never defined, which is one cannot act upon that which has not been defined coming back around to bite the rule that was supposed to build on it.