How do you set a technology standard that teams follow without resenting?

What is being tested

Whether you achieve governance through convenience rather than through enforcement.

The three properties that make a standard work

1. A paved road, not a rulebook. The standard must be the easiest option — a template, a module, a pipeline that works out of the box, with observability and compliance wired in.

Teams then follow it because it saves them work, which is the only form of compliance that survives deadline pressure. A standard that is extra work will be followed when there is slack and abandoned when there is not.

2. A fast, credible waiver path. Standards without exceptions are broken quietly rather than formally, and invisible exceptions are worse than granted ones — you lose the ability to see and support what is actually running.

A waiver should need a stated reason, an owner and a review date, and should be granted in days rather than by a fortnightly committee. Track waivers: a pattern of teams needing the same exception is the standard's roadmap.

3. A defined lifecycle. Adopt, trial, contain, retire — reviewed on a cadence. A standard set that never changes freezes the estate on decisions made a decade ago, and teams will correctly stop respecting it.

What to standardise and what to leave open

Standardise where variety costs operational effort and provides no benefit: observability, deployment, secrets management, identity, base images, network patterns. Nobody's product is better for having a different logging library.

Leave open where the workload genuinely differs and the team bears the consequences: a specialised data store for a specialised problem, a language suited to a particular domain.

Over-standardising the second category is what produces resentment, high waiver rates and shadow infrastructure — and it discredits the standards that were worth having.

What the standard actually buys

Reduced operational surface — every technology needs expertise, patching, monitoring and someone available at 3am, and the number of things an organisation can be genuinely good at is small. Engineer mobility between teams. Vendor negotiating position. And faster decisions, because most choices stop being debates.

The cost is local optimality: some team is doing something more expensively than it needs to. That is usually a good trade, and stating it as a trade rather than as a rule is what makes it acceptable.

What a strong answer adds

That the standard should be set with the teams who will follow it, not handed to them. A standard chosen by the people who will live with it is defended by them; one imposed is worked around. That is a governance design decision, not a courtesy.