A written standard says every new service must emit structured logs with eight required fields. Twenty-six teams ship roughly 30 new services a year and about 45% comply. Which change most reduces the annual cost of this standard?

What an unenforced standard costs per year

Estimate it before choosing, because the costs are not where people look.

• Argument time. Every new service re-opens the question of whether the standard applies. 30 services a year × roughly 2 hours of discussion across the team and a reviewer is about 60 hours.
• Divergence work. The 55% that do not comply are 16 or 17 services a year whose logs need bespoke parsing, dashboard wiring and alert rules. At roughly 6 hours each, about 100 hours.
• Incident cost. One multi-service incident a year running 90 minutes longer than it needed to with 6 people engaged is about 9 hours, plus whatever the downtime cost.

That totals roughly 170 engineer-hours a year, on the order of 0.1 FTE, and it recurs every year while buying no uniformity at all. At roughly $100 to $150 per engineer-hour fully loaded in 2026, the paper standard costs $17k to $25k a year to not work.

Why the template wins the arithmetic

A service template with the eight fields already wired in costs on the order of two weeks to build (80 hours) once, plus about a day a quarter to maintain (32 hours a year). It takes the 30-services-a-year inflow to near-total compliance with zero marginal effort per service, because compliance becomes the path of least resistance rather than an instruction competing for a team's attention. Payback lands inside the first year, and the recurring cost is a third of the status quo.

The mechanism matters more than the saving. A standard's cost is paid per decision; a default's cost is paid once. Write a standard only when you can name the mechanism that will carry it — a template, a CI check, a platform default, a library that is the only sanctioned path. If you cannot name one, publish a default implementation and call it a recommendation, which is honest and costs nothing to not enforce.

The complement is a CI check for drift, since services diverge after month one. Build the template first; the check then has something to compare against.

When not to build the mechanism

With 3 teams and 4 new services a year, the arithmetic reverses. 80 hours of template work against 8 hours of annual argument is over-engineering, and a documented example plus a conversation is the correct answer. Mechanical enforcement earns its cost when the inflow is large enough that per-decision argument dominates the one-time build. Mechanical enforcement also needs an escape hatch with a named approver; without one, teams fork the template and you lose the visibility the standard existed for.

Why the other options fail

Quarterly compliance review. It scales with the thing you want to shrink: 26 teams × 4 quarters × 1 hour is 104 hours a year, and the output is reports rather than logs. Reviews are a reasonable way to measure a mechanism that exists; they are an expensive substitute for one that does not.

Architecture sign-off on every new service. 30 reviews a year at roughly 3 hours each is 90 hours, it puts a queue in front of every team, and it makes the architect the bottleneck for work they do not own. It also tends to find the standard's violations late, when the service already emits logs the wrong way. This is the option that feels like authority and buys resentment.

Publish it more prominently. 45% compliance in a documented, presented standard is not an awareness problem; the teams that skipped it knew. Communication changes behaviour where the gap is knowledge, and here the gap is effort.

Fund a retrofit team. This pays for the past and leaves the inflow intact, so the debt rebuilds at 16 services a year. Retrofit is the right second project, once the inflow is closed and the backlog is finite.