Description
What share of your merged changes get reverted within two weeks? Most engineering leaders can answer deployment frequency, roughly answer lead time, and produce a change failure rate if the dashboard is working. That one usually draws a blank. It is also only the engineering half of the question. The other half is whether the people downstream, the ones selling the feature, supporting it and using it, can take in what is shipping at the rate it now ships.
Organisational theorists named this long before software had the problem. Absorptive capacity is the ability to recognise something new, take it in and put it to use, and the finding that matters is the dependency: capacity rests on what you already understand. It is a property of the organisation rather than of any individual. One developer accepting suggestions quickly does not mean the reviewer understood the change, the maintainer can debug it in three weeks, or the team on the other side of the interface knows it moved.
Under acceleration both surfaces bend at once. Changes arrive faster and larger, review time grows roughly in step with the volume rather than falling behind gracefully, and the share of code revised or reverted shortly after landing rises. That share is the honest canary, and it is not a new metric: the relationship between how much code churns and where the defects land was established on large commercial systems two decades ago. Nobody thought to point it at generated code until the rate started moving.
So this dimension is about the gap between producing and absorbing, and whether anything in your organisation is watching it. A team with high deployment frequency and rising churn is moving quickly toward a wall. A team with modest throughput and a flat churn rate has room to accelerate safely. The two look similar on most dashboards, and only one of them should be adding volume.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
Nobody counts what gets reverted or rewritten. Rework happens, usually done by the same people who wrote the original, and it disappears into the next estimate rather than into a number. The system could be absorbing less every month and nothing in it would say so.
The tellSearch last month's merge history for reverts, and for files rewritten within two weeks of landing. If getting that count is a small project rather than a query, nothing is watching it.
- 2
Tacit
Teams know when they are redoing work, and some track it privately in a retrospective or a spreadsheet. It stays local. Nothing aggregates it, so the organisation reads throughput as delivery and never sees the part of that throughput which came back.
The tellAsk two teams whether rework is up. If both say yes with conviction and neither has a figure, the knowledge is there and the measurement is not.
- 3
Visible but inert
The numbers exist. Churn, revert rate and change failure rate are computed and reported, sometimes well. Nothing depends on them: adoption targets, headcount plans and delivery commitments are set without asking whether the last increase in volume was actually absorbed.
The tellFind your churn or revert number, then find the last decision that changed because of it. If rising churn has never slowed a rollout or reopened a plan, it is reporting.
- 4
Acted on
The rate is tracked on a cadence and it can stop work. Churn or reverts above the agreed line stop a rollout, tighten batch size or trigger a review, without depending on an engineer winning an argument that quarter. The number is allowed to say no.
The tellFind the last time your churn or revert rate crossed its threshold. Something stopped or slowed because of the number, rather than a person noticing and arguing for it.
- 5
Durable
Absorption is treated as a capacity to be maintained. Batch size, review load and the rate of change reaching people outside engineering are watched together, capacity is added before the number degrades rather than after an incident, and the practice survives a quarter when delivery is behind.
The tellLook at churn against merge volume over the past year. If volume rose and the rate stayed flat, and you can name what was funded to keep it there, absorption is being maintained rather than gradually spent.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
Nagappan and Ball, Use of Relative Code Churn Measures to Predict System Defect Density (ICSE 2005)
Showed on a large commercial system that how much code churns, measured against its size, predicts where the defects land. Churn was a defect signal two decades before it became a symptom of acceleration.
Cohen and Levinthal, Absorptive Capacity: A New Perspective on Learning and Innovation (Administrative Science Quarterly, 1990)
Established that an organisation's ability to take in something new depends on what it already understands, and that the capacity is organisational rather than individual. Generating more does not raise it.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Change absorption →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.