A company builds an internal platform to standardise how services are created and operated across hundreds of teams. What should it enforce, what should it leave flexible, and how does it avoid becoming an obstacle?

What should be enforced

Enforce the things whose absence harms the organisation rather than the team, and where inconsistency has compounding costs:

• Ownership metadata. Every service has a team, an on-call rotation and a contact. An unowned service in production is an incident waiting for a confused responder, and this is the single most valuable thing to enforce.
• Observability instrumentation — standard metrics, structured logs with correlation identifiers, tracing context propagation. One service that drops trace context breaks every trace passing through it, so this is genuinely a collective property.
• Deployment through the standard pipeline, which is where security scanning, provenance, approval gates and rollback live.
• Identity and authentication: service identity, mTLS or equivalent, no static credentials.
• Compliance evidence generation, so audits do not become per-team archaeology.
• Cost attribution tagging, since unattributed cost is nobody's cost.

The common property: each of these is cheap when it is uniform and disproportionately expensive when it is not.

What should be flexible

• Language and framework, within a supported set. Mandating one language across hundreds of teams costs more in fit than it saves in consistency.
• Internal architecture of a service — layering, patterns, libraries.
• Data model and storage choice, within the paved-road options.
• Testing approach, provided the quality gates are met.
• Release cadence, within the pipeline's controls.

The property here: these affect the team that chose them, and the feedback loop is local.

How enforcement should work

Through the golden path, not through a gate. The service template generates a project with observability, pipeline, ownership metadata, identity and cost tags already configured — so compliance is the default state rather than a checklist.

Guardrails over gates: policy evaluated automatically at deployment, blocking only what is genuinely dangerous, warning on the rest. A gate that blocks frequently is routed around; a guardrail that blocks rarely is respected.

Make the compliant path faster than the alternative. A new service running in production in fifteen minutes with everything configured beats days of assembly, and that speed differential is the enforcement mechanism — far more effective than policy.

How it avoids becoming an obstacle

• An escape hatch that is used rarely and is not punished. A platform with no way out is a risk, and teams evaluate it as one. Deviation should be permitted, visible, and carry the operational burden.
• Deviation treated as roadmap input. Repeated escape in the same direction is a requirement the platform has not met — the most valuable signal the platform team receives, and it is only available if escape is permitted.
• Published SLOs on the platform itself, since teams are now depending on it.
• A fast path for a team to request a platform change, because if that path is slow, teams fork and the fork is permanent.
• Backwards compatibility and a real deprecation policy, so the platform does not impose migrations at its own convenience.
• Measured by adoption and by outcomes — time to first deploy, lead time and change failure rate for adopters versus non-adopters — never by capabilities shipped, which is the metric platform teams report and which correlates with nothing users care about.

The organisational precondition

A platform serving hundreds of teams needs to be staffed and run as a product with users, not as a side project. An under-resourced platform that everything depends on is a bottleneck with a mandate, which is worse than no platform at all — because teams cannot route around it and cannot get what they need from it.