Better Is a Local Word
Standardization helps more often than I would like to admit. It fails in the one place that matters most.
I recently took some time off and moved through a few very different places in a short window: Puerto Rico, St. Thomas, Sint Maarten, St. Croix, Dominica, and Barbados. They sit close together and they are nothing alike. Different pace, different priorities, different constraints, different strengths. Each one works, not in spite of being different but because it is built around its own reality rather than someone else’s idea of how things should run. Six islands in a week, each refusing to be a worse copy of the one next door.
I see the opposite instinct in companies all the time, and it has bothered me for years. There is a recurring pull in growing organizations to homogenize: to take teams, products, and processes that each found their own way to succeed and pull them all onto one shared template. The instinct is rarely malicious. It usually comes wrapped in good words like consistency, alignment, and scale. But more often than I would like, the result is not that everything gets better. It is that everything gets the same, and “the same” turns out to be the lowest common denominator.
What homogenizing actually does
Let me make the strongest case for the other side first, because it is a strong case and I have watched it win. Standardizing across teams raises the floor: it kills the worst practices, spreads the good ones, and makes the whole organization legible from above. Consistency lets people move between teams without relearning everything. It makes reporting comparable and coordination cheap. It removes the seams where one team’s way of doing things grinds against another’s. Some of the largest gains in software and in operations came from exactly this, from refusing to let every group invent its own version of a solved problem. Toyota did not get great by letting each plant freelance.
And here is the part of the steelman that stings, because it is the one I have to keep checking myself against: what a team experiences as its hard-won local adaptation is sometimes just a few talented people doing unscalable, heroic things. It feels like excellence from the inside. But it does not transfer, it does not survive those people leaving, and when you try to standardize, you discover the magic was never in the process at all. In those cases the homogenizer is simply right, and the team protesting the loss is defending a liability it mistook for a strength. So I am not claiming standardization usually loses. Often it wins, and often the people resisting it, including me on a bad day, are wrong.
The failure I am pointing at is narrower and more specific than “standardizing is bad.” It is what happens when you force a single template across teams that genuinely differ in their constraints, not just in their habits. Because the template has to work everywhere, you cannot keep every team’s real adaptation, and the easy path is to build to the common case, which in practice drifts toward the weakest case, the one that needs the most guardrails. When that happens, the teams that were genuinely excellent lose the specific things that made them so, and those things do not come back. What felt like raising the floor quietly lowers the ceiling, and you get uniformity at roughly the level the least capable part of the org can sustain. The trouble is that this looks identical, on a dashboard, to the good kind of standardization. Both produce consistency. Only one produces better work.
The tell is in the language. When a change is justified mostly by how much easier it is to manage, compare, or explain from the outside, and not by whether the teams doing the actual work come out stronger, you are usually looking at the bad kind wearing the costume of the good kind. The question that gets skipped is the only one that separates them: what was the difference doing before we erased it?
The discipline, and the honest edge
I want to be careful not to turn this into “never standardize,” because that is its own lazy answer. Sometimes a difference between teams is not a hard-won adaptation at all. It is just cruft, an accident of history that survives because no one ever questioned it. In those cases convergence is exactly right, and “we have our reasons” is a story people tell to avoid changing. Part of the job is telling the two apart, and pretending every local quirk is sacred is as much a failure as flattening all of them.
So the discipline is not to resist standardization on principle. It is to earn the right to it. Before you erase a difference, you have to be able to say what it was trading off and why, and whether that tradeoff is still buying anything. What looks slower may be more resilient. What looks simple may be exactly enough. What looks like a strange exception may be the one thing absorbing a problem no one upstream has noticed yet. Sometimes you look closely and it really is just cruft, and then you cut it without ceremony. The point is that you looked first.
There is a fair objection here, and I do not want to dodge it. Investigating every local difference is a luxury that does not survive scale. At five teams you can understand each one. At five hundred you cannot, and demanding that you justify the erasure of every quirk is just a recipe for never standardizing anything. That is true, and it is why “understand each difference first” is not actually my prescription. The move that scales is to standardize the interface and the outcome, not the internals. Agree on what a team must produce, what it must expose to everyone else, where it connects to the rest of the org, and then leave how it gets there alone. That gives you the legibility and the cheap coordination that make standardization worth wanting, without reaching inside and ripping out the local adaptations you have no time to evaluate. Most of the damage I am describing comes from standardizing the inside, the part that was none of the template’s business, in the name of consistency on the outside.
That is the through-line back to those six islands. The mistake is deciding what “better” means before understanding the place you are standing in. Better is a local word. It depends on the constraints in the room, and those are usually invisible until you go looking for them.
The leaders I trust most are not the ones with the strongest urge to make everything uniform. They are the ones who can sit with the discomfort of things being different on purpose, long enough to find out whether the difference is earning its keep. The instinct to homogenize feels like leadership because it produces something visible and tidy. Often the harder and better move is to listen longer before deciding what “better” even means.