A process that works for one team erodes at twenty

The pilot went well. One team, a well-understood codebase, engineers who chose the method and cared about it. The numbers were good, so the method was rolled out to twenty teams.

A year later every team says it follows the process, every dashboard is green, and nobody can say whether quality is where it was in the pilot. Nobody decided to cut corners. Processes erode one reasonable exception at a time.

How a delivery process erodes

The temporary bypass. A gate is switched off for an urgent release, and nobody switches it back on.

The template specification. Specs are written to satisfy the format rather than to decide anything. Every section is filled in, and the acceptance criteria restate the title.

The rubber stamp. Approvals arrive faster than the change could have been read. Nothing in the tooling distinguishes them from real reviews.

The inherited method. Teams that joined later received the rules without the reasons. They keep the rules that are cheap and drop the ones that hurt, which are usually the ones that mattered.

The silent gate. A check that has not caught anything in a year. It is either working perfectly or checking nothing, and nobody knows which.

From the dashboard, each of these looks exactly like compliance.

Audit the output, not the paperwork

Asking teams whether they follow the process measures their answer to the question. The only reliable signal comes from looking at what the process produced.

Sampled deep review. Every month a small random sample of merged changes from each team is reviewed again, properly, by somebody outside the team and against the specification. The point is not to catch those changes, which have already shipped, but to measure the gap between the review they got and the review they needed. It is the only way to see review quality, because a shallow approval and a careful one look identical in every log. Results are reported per team, not per reviewer: the aim is calibration, and a sample that leads to blame will be gamed within a quarter.

A visible bypass log. Every gate override is recorded with who, why and until when. The log is reviewed monthly, and an override without an end date gets one.

Defect origin by team. Escaped defects are classified by the stage that should have caught them. Across twenty teams, that classification becomes a map of whose process is drifting, and where.

Specifications checked by regeneration. Now and then a module is regenerated from its specification in a branch and tested. A team that is reluctant to try has a specification that stopped being the source of truth.

Prune the rules, too

Erosion is not the only failure. The opposite one is accumulation: every incident adds a rule, no rule is ever removed, and the process becomes so heavy that bypassing it starts to look like common sense.

Infographic

Which process rules to keep

Costly to runCheap to run

Rethink or retireCosts everyone time; check whether it still guards anything.

Automate itWorth keeping; let the pipeline do the checking.

Keep and testInject a known fault now and then to prove it fires.

FoundationNever bypassed and never up for debate.

Rarely catchesOften catches

Every rule should earn its place. The expensive ones that rarely catch anything get rethought or retired. The cheap, silent ones get tested: introduce a known fault now and then and confirm the gate fires. A gate nobody has seen working is a belief rather than a control.

Give the process an owner

The pipeline, the gates, the specification format and the audit are a product with internal users. Somebody has to own it, have time for it, publish the numbers and have the authority to change the rules for everyone. Without that owner every team edits its own copy, and a year later there are twenty processes sharing one name.

That owner is rarely the pilot team. The pilot needed context and enthusiasm; the role now needs the authority to say no to twenty teams and the time to look at their numbers every month.

The pilot proved that the method works when people care. Scaling it is the work of making it hold when they are busy. In spec-driven development the aim is for your engineers to run the method with its failure modes named, these ones included, so that it survives the rollout and survives our leaving.