intermediate 3 min answer

Your estate has 240 services owned by 40 teams. A new standard requires every service to emit an ownership descriptor and a cost tag - a mechanical change, about 20 minutes per service. There is no migration funding, so teams do it when they next touch the service. Repositories are touched at a median of roughly once a month, but about 25% of services have had no commit in a year. Estimate when the standard reaches 95% of the estate, and say what that number should change about how the standard is written.

standardsadoptionestimationdormant servicescompliance
Show the full answer Hide the answer

The assumptions, stated

  • 240 services. 25% dormant means 60 services with no commit in a year, 180 active.
  • Active services are touched at a median of about a month, so the active population is a decaying exponential with a long tail: roughly half comply within a month, three quarters within two to three, and the last stragglers take a year.
  • Opportunistic adoption only ever reaches services that are touched. Dormant services are not slow adopters; they are outside the mechanism.

The arithmetic

Ceiling first, because the ceiling is the answer:

reachable by opportunistic adoption = 180 / 240 = 75%
target                              = 95% of 240 = 228 services
shortfall                           = 228 - 180 = 48 dormant services

Opportunistic adoption asymptotes at about 75% and never reaches 95%. The active 180 get there in roughly six to nine months - fast at first, then a tail - and then the curve flattens and stays flat. Reporting it monthly produces the familiar shape: encouraging progress to 70-something percent, then two years of no movement that gets attributed to culture.

Which assumption dominates the error? The dormant share, by a wide margin. If the true figure is 15% rather than 25%, the ceiling moves to 85% - still short of 95%. The median touch rate barely matters: it changes how long the first 75% takes, not whether the target is reachable. An estimate that is sensitive to one input and insensitive to the other is telling you where to look.

What the number rules in or out

Ruled out: a 95% target enforced at merge time with no funding. The mechanism and the target are incompatible, so the programme fails in a specific and demoralising way - the gap gets reported as non-compliance by teams who have done nothing wrong, and the standard loses authority for the two years the curve is flat.

Ruled in, two options:

  1. Fund a sweep. The change is mechanical, so one engineer writes a generator and opens 60 pull requests. That is roughly two to three weeks of one person, plus about 20 hours of other teams' review time spread across 40 teams. Compare that with waiting indefinitely: a central week beats a distributed year whenever the change needs no domain judgement.
  2. Scope the standard honestly. Write it as applying to services that deploy, measure against that denominator, and route the dormant 60 to a different question. A service with no commit and no deploy in a year is a retirement candidate, not a compliance gap, and the standard has just generated the best retirement shortlist the organisation has.

Most estates should do both: sweep the ones that are alive but quiet, and send the genuinely dead ones to a disposition decision.

What a strong answer adds

The enforcement point, chosen from the arithmetic rather than by habit. Merge-time checks cover only what gets committed - 75% of this estate at best. Deploy-time checks cover everything that still ships. A periodic scan over the running estate covers everything, including services in production that nobody edits, and it is the only one of the three that can report a true denominator. Choose the gate by what you need to count, not by where it is easiest to add.

And the metric to publish: not percentage compliant, which hides the ceiling, but compliant as a share of the active estate, with the dormant count reported separately as a line item. Two numbers that mean something beat one that means two things.

When this is the wrong answer

When the change is not mechanical. A standard that requires judgement per service - choosing a data classification, naming a system of record - cannot be swept by a generator, and the central-week argument collapses. There the only honest plan is opportunistic adoption with a funded push for the services that matter most, and a target set at the active estate.