A customer asks for one extra field in a report.

No one wants to overthink it. It's a small request. It sounds reasonable. It probably takes less time to add the field than to explain why it should not be there.

So it goes in.

Six months later, that field appears in a help article, a spreadsheet export, a training note, and a recurring question from someone new: why do we collect this? The original reason is still around somewhere, but it has become blurry.

This is how work gets harder. Not usually through one bad decision, but through a long series of reasonable exceptions.

A designer needs one more version of a screen. A team wants its own intake process. A customer needs a slightly different handoff. Each request makes sense by itself. Each one is easy to justify in the moment. Enough of them, though, and the shared path starts to disappear.

The cost shows up later.

It shows up when a review takes longer because this page does not behave like the others. It shows up when support has to remember which customers get which answer. It shows up during onboarding, when the new person has to learn not just the system, but all the places where the system quietly breaks its own rules.

That is the part people underestimate.

Customization does not just add work. It adds memory. Somebody has to remember why the thing is different, where the difference lives, and what depends on it. When nobody remembers, people become cautious around it. They leave it alone, not because it is good, but because changing it feels uncertain.

Enough of that and the system becomes harder to trust. It may still function, but it stops feeling clear.

The strongest systems are not the ones with the most options. They are the ones where the common decisions have already been made.

There is one way to start a project. One way to name things. One way to record decisions. One way to hand work from one person to another. One general shape for the pages, forms, documents, and messages people see every day.

That kind of standardization can sound dull. It is dull. It is also generous.

Every standard removes a small negotiation from the future. You do not have to ask how this should be named, where this should live, what the next step is, or who needs to be told. The answer is already part of the environment.

Not because the answer is perfect. Because shared is usually more useful than perfect.

This matters more now because making variations is easier than it used to be.

You can ask a tool for another version of almost anything: another page, another workflow, another message, another dashboard, another document. It may produce something plausible in a few seconds. That makes the variation feel cheap.

But cheap to create is not the same as cheap to maintain.

Every extra version becomes something people have to understand later. Someone has to explain it, test it, update it, and decide whether it still belongs. The faster we can produce variations, the more careful we have to be about which ones deserve to stay.

None of this means every difference should be flattened. Real users are not averages. Taste matters. Context matters. Some products work because they notice something specific that everyone else missed.

But most customization is not that. Most of it is postponed decision-making.

The question is not "can this be different?" Everything can be different. The question is whether the difference carries real information.

If it reflects a real user need, a business constraint, or a product judgment, make room for it. Standards should not crush the part of the work that matters.

But if the difference is mostly preference, habit, politics, or fear of saying no, standardize it. Pick the default. Write it down. Make the common path easy to follow and make the uncommon path explain itself.

The useful line for me is:

Standardize the ground. Customize the signal.

The ground is the part people need before they can do meaningful work: names, roles, handoffs, documents, permissions, meeting rhythms, review expectations, support paths. The things that should not need to be re-decided every week.

The signal is the product insight, the customer need, the unusual constraint, the interface detail that actually changes understanding, the workflow that makes a hard job feel lighter.

Most teams let the ground fragment, then wonder why there is not much energy left for the signal.

Bad standards exist. A standard chosen too early can preserve the wrong abstraction for years. A standard enforced without judgment becomes habit pretending to be principle. The goal is not consistency for its own sake. The goal is to spend inconsistency carefully.

Customization is a kind of debt. Sometimes the debt is worth it. Sometimes speed matters. Sometimes a customer constraint is real. Sometimes the unusual thing becomes the next standard.

But if nobody can name the reason, it is probably clutter.

The best teams do not argue about the same small things twice. They decide once, write the decision into the environment, and move on. A convention becomes a template. A template becomes a habit. Eventually the system starts carrying some of its own weight.

That is what standardization is for. Not control. Not making everything match. Moving effort out of repeated decisions and into better work.

Customize where the difference matters.

Standardize where the difference only adds weight.