Fourteen teams, fourteen definitions of done

Fourteen delivery teams, each with its own definition of done, its own tooling, and its own threshold for when a risk was worth raising. There was a quality function on the org chart and no quality standard in practice.

The visible symptom was integration: a defect found in one team's work usually originated in another's, and the argument about whose it was ran longer than the fix. The invisible one was worse — leadership had no way to tell a team that was improving from a team that was simply quiet.

Wrote the standard with the teams, not for them

Six weeks of working sessions produced a single page: what has to be true before a change leaves a team. Three of the fourteen already met it on the day it was written, which is how we knew it was set at the right height rather than at an aspirational one.

Made every clause measurable without a new tool

Each clause maps to something the teams' existing pipelines already emit. No new instrumentation, no per-team migration project, and no dashboard anyone has to fill in by hand — a standard that costs a weekly form to report gets reported inaccurately.

Staffed the gap instead of reporting it

The teams furthest from the bar got hands-on help — two of ours embedded a sprint at a time — rather than a red square on a slide. A standard that only measures is a scoreboard, and scoreboards make people optimise the score.

Handed the standard to an internal owner

A named quality lead inside the company, with the authority to change the standard rather than just enforce it. This was designed as a decreasing engagement; it is now a monthly review, not a team on site.

At six months, eleven of fourteen teams clear the bar, against three at the start. Defects crossing a team boundary are down 58%, and most of the ownership argument went with them.

The change leadership cares about is simpler than any of the numbers: a quality risk raised inside one team now reaches the people who can act on it, in a form they can hold against every other team's.

One page was the right answer. Six weeks to write it was not. We could have published a draft in week two and let it be wrong in public — the sessions produced a standard the teams genuinely own, but the first two months moved more slowly than the problem deserved.