Coordination-Cost Metric

Delivery metrics conventionally measure the pipeline: lead time, deployment frequency, change failure rate, time to restore. They describe how quickly a change moves once it exists, and they are silent on the question that usually dominates: how many parties had to agree before it could be written.

The coordination-cost metric measures that directly. For a representative sample of features, how many independently-deployed services changed, and how many distinct teams owned them?

Why it matters

Lead time in a large organisation is usually dominated by waiting for other teams, not by engineering effort. A feature that takes four days of work and six weeks of elapsed time has a coordination problem, and every pipeline optimisation in the world will not touch it.

The metric is also the most direct evidence available that service boundaries are wrong. Services that consistently change together do not have independent reasons to change — which is the defining property a boundary is supposed to express — so they are paying the full price of separation and obtaining none of its benefit.

And crucially, it is invisible in every other dashboard. SLOs are green, the pipeline is fast, each team is delivering, and the organisation cannot ship — because the cost is distributed across the gaps between teams where nothing is measured.

Implementation patterns

• Derive it from deployment history: for each feature or epic, the set of services deployed within the change window, and their owning teams. This is computable from data most organisations already hold.
• Mine change coupling from version control — files and services that repeatedly change in the same commit or the same week are coupled regardless of what the architecture diagram claims.
• Track the distribution, not the mean. A median of one with a long tail is a different problem from a median of four.
• Measure teams as well as services, since teams are what actually causes waiting; five services owned by one team is a very different situation from three owned by three.
• Pair it with lead time, so the correlation can be shown rather than asserted — which is what makes the case fundable.
• Watch the trend, since the absolute number is less informative than its direction.
• Use it to target consolidation: merge candidates are services that deploy together, have similar scaling profiles, and already fail together.

Industry example

The reasoning underlies Netflix's shift from a very large number of fine-grained services toward fewer, better-bounded ones, and the same shape appears wherever an organisation reverses a decomposition: the observable symptom is lockstep deployment and cross-team coordination for ordinary features, not a runtime problem.

It also explains a pattern visible across the DORA research programme's findings — that architectural characteristics enabling teams to deploy independently are among the strongest predictors of delivery performance. The metric is the operational form of that finding: independent deployability is not a property of the pipeline, it is a property of the boundaries, and this is how you tell whether you have it.

Failure scenarios

• Never measured, so coordination cost accumulates invisibly while every other metric looks healthy.
• Restructuring on the metric alone, when the real cause was manual approval gates, slow tests, environment scarcity or unclear ownership — the same symptom with a far cheaper fix.
• Merging services and losing the internal module boundaries, producing something that cannot be split again.
• Treating a low service count as the goal, which is the microservice-count error pointed the other way.
• Measuring services and ignoring teams, missing the actual source of delay.
• Using it as a team performance measure, which guarantees the data is gamed and the signal destroyed.

Trade-offs

The metric is more effort to collect than pipeline metrics and requires linking features to deployments, which not every organisation's tooling supports cleanly. Approximations — change coupling from version control, deployment correlation — are cheaper and noisier, and are usually sufficient to identify the worst cases.

It also points toward consolidation, which sacrifices independent deployability, independent scaling and fault isolation. That trade is correct precisely when those things were not actually being obtained — when services already deploy together, scale together and fail together — and wrong when they were. The metric identifies candidates; it does not make the decision.

The trade is measurement effort in exchange for visibility of the delivery cost that no other instrument shows. For a small organisation it tells you nothing you did not know. For a large one it is frequently the single most informative number available, and its absence is why "our SLOs are green and we have stopped shipping" is such a common and confusing situation.

Interview question

"Leadership says delivery has slowed and engineering says everything is fine. Tell me the first number you would compute, where you would get the data, what each possible result would mean, and what you would recommend if it turned out the pipeline was fast and five teams touch every feature."