How do you get 40 teams onto a hardened shared pipeline when a written policy alone has not worked?

## Why the policy lost A written policy distributes cost outward and keeps authority central. Each of forty teams must read it, interpret it for their stack, and spend their own sprint capacity implementing it, in competition with the roadmap they are actually measured on. The predictable outcome is partial adoption concentrated in the teams with slack, and an estate where the security team's coverage number is an estimate. A paved road inverts the economics. The controls arrive as a side effect of the fastest way to do the job. Nobody adopts artifact signing because a document told them to; they adopt it because the template that gets their service released in an afternoon happens to sign what it builds. ## What makes the road actually faster - **A small number of well-supported shapes.** Four build shapes done excellently beat twenty done adequately. Configurability is the enemy here: every option is a support surface and a reason for the road to be slower than a bespoke pipeline. - **The platform team does the migration.** If migrating means a service team reading documentation and writing configuration, the migration competes with feature work and loses. If it means reviewing a change somebody else wrote against their repository, with their tests green, it takes ten minutes. - **Fast feedback.** If the shared pipeline is slower on every commit than the one it replaced, teams will route around it eventually no matter what the policy says. - **A real off-road route.** Some services genuinely do not fit. An exception path that exists, has a named owner, requires a review and equivalent evidence, and is granted in days, keeps those teams visible. An exception path that is impossible in practice produces quiet forks instead. ## Measuring adoption honestly The number that gets reported upward decides what the platform team optimises. Three refinements matter. First, count *services in production*, not repositories, because the estate has repositories nobody ships. Second, count only services on a **supported** template version — presence at any version conflates a service on last week's template with one pinned to a version from two years ago that predates half the controls. Third, count vendored copies explicitly as not adopted, and publish that number, because copies are where the coverage claim quietly breaks. A useful headline is the share of production services on a non-end-of-life template version, reported alongside the version distribution, so the shape of the tail is visible rather than averaged away. ## What must stay true for the road to remain honest A paved road is a real security control only under conditions the platform team owes back: - **The template is production software.** It executes in every pipeline in the estate, which makes it a single point of compromise and an extremely attractive target for anyone with commit access to it. Restricted write access, mandatory review, its own tests and released versions are not bureaucracy here; they are the price of centralising execution. - **Trust but verify downstream.** Coverage claims should not rest on the assertion that the template performs a control, because the team running the pipeline can change its configuration. The evidence the pipeline emits gets checked where artifacts are accepted, so the claim is verified rather than assumed. - **The road keeps moving.** A template that is fast today and unmaintained in a year becomes the thing teams work around. Ongoing investment is what keeps the traffic. - **The policy still exists.** The road implements the policy; it does not replace it. You still need the written statement of what is required, both for the exception cases and because a road cannot be audited against nothing. ## The organisational judgment The real question a principal is being asked is where to spend a finite platform budget: on enforcement machinery that makes non-compliance fail, or on ergonomics that make compliance the path of least resistance. The mature answer is sequenced rather than either-or. Ergonomics first, because they generate adoption without conflict and reveal which requirements are unreasonable; measurement next, so the remaining gap is a named list rather than a feeling; enforcement last, aimed at that named list, once the road can carry the traffic you are about to force onto it. Enforcing before the road is ready produces exceptions at scale, and an exception process with forty entries is a policy that has already lost, only more expensively.