A platform company wants engineering standards without slowing autonomous teams. Where should standards be mandatory, and where should they be defaults?

What should be mandatory

The test: does variety here create risk or cost that a team cannot see from inside its own boundary?

• Identity and authentication. A team choosing its own model creates a security surface nobody can assess.
• Observability format and correlation identifiers. Without uniformity, cross-service latency attribution is impossible — which is the capability the whole organisation needs during incidents.
• Deployment and change controls, where an audit or regulatory obligation applies.
• Network policy and data classification, where the consequence of divergence is exposure.
• Interface and event contract compatibility rules, since a breaking change harms other teams rather than the team making it.
• Cost attribution tagging, without which nobody owns any part of the bill.

Each of these has a consequence that lands outside the team, which is precisely why it cannot be a per-team choice.

What should be a default

Language, framework, database, testing approach, internal architecture. A strong default with an easy path — and freedom to differ with a reason.

The value of a default is that most teams take it without deciding, so variety stays low without anybody being forced. The freedom matters because the exceptions are frequently right: a workload with an unusual shape deserves an unusual choice.

What makes this work

The compliant path must be faster than the alternative. A team that can provision a compliant service in an hour will use the paved road; a team facing a six-week intake will build its own and be right to. Standards enforced by review lose to deadlines; standards embodied in a service template win by being easier.

Preventive enforcement for the mandatory set, in the pipeline and at the control plane, so compliance does not depend on anyone remembering.

An exception path with an owner, scope and expiry, because a standard with no exception process is routed around and a permanent exception becomes the architecture.

Standards state properties, not mechanisms, so a legitimately different workload can meet the intent without breaking the letter.

The failure in each direction

Mandatory everywhere produces an estate that cannot accommodate a legitimately different workload, and teams that route around governance entirely. No standards produces an estate where every incident requires learning a new system and no platform investment pays back.