Two teams own what the capability map calls different capabilities. In the last quarter, 14 of 40 pull requests to either team's service were paired with a same-week change to the other's, and both teams report that every pricing change needs a joint release. The map was signed off nine months ago and nobody disputes it. What is the diagnosis?

The first three signals I would look at

1. Co-change frequency, which is already in hand. 14 of 40 is 35% of changes crossing a boundary that is supposed to separate two capabilities. Above roughly 20%, the boundary is not where the work is.
2. What the joint release actually contains. Is it a shared data structure, a shared rule, or just a deployment-order constraint? These have different fixes and only one of them is a boundary problem.
3. The vocabulary. Ask each team to define "price". If one means the figure shown to a shopper and the other means the figure settled against a contract, you have found the real boundary and it has no name on the map.

The diagnosis

The map stops at a level where a single word covers two capabilities that are funded, measured and changed differently. "Pricing" at level 2 hides "quote a price" and "settle a price": one is latency-bound, approximate and changes weekly; the other is exact, auditable for years and changes rarely. Drawn as one capability, the boundary between the teams had to be put somewhere else, and wherever it went the work crossed it.

The co-change number is the evidence, and it works because version-control history records what the organisation actually did rather than what it drew in 2024. A boundary's job is to absorb change on one side of it, so a boundary that 35% of changes cross is doing the opposite: it adds a release negotiation to a third of the team's work without containing anything, and it fails in the expensive direction, because a joint release is also a joint rollback.

The misleading signal

Nobody disputes the map. Agreement feels like confirmation and it is not: a level-2 map describes the business accurately at level 2, which is why everyone signs it. The map is not wrong, it is too shallow to decide anything, and the test of a capability map is whether two sub-capabilities under one name would be funded, measured or governed differently. Here they would.

The fix

Split the capability at the level the decisions differ, then redraw the team boundary to match: one team owns quoting including its cache and its tolerance for being slightly stale, the other owns settlement including the audit record. Publish a contract between them, versioned, with a consumer test, so a change on one side stops requiring a release on the other.

Then re-measure. Co-change rate after the split is the acceptance criterion, and if it has not fallen below about 10% in a quarter the split was in the wrong place and you have learned that cheaply.

When this is the wrong answer

Choose the simpler fix when the co-change is a deployment-order constraint rather than shared logic: the boundary is fine, the failure is release coupling, and backward-compatible interfaces plus independent deploys close it in weeks rather than a reorganisation.

And if the two capabilities genuinely are one, the honest answer is to merge them and have one team. Redrawing a map is cheap; moving people is not, so confirm the split with the vocabulary test and the funding test before anyone's reporting line changes. When neither test separates them, do not split.