Start with throughput = WIP / cycle time. A developer holds some number of open pull requests at once; call it two, which is not a heroic figure. If each sits five days, that developer merges 0.4 pull requests a day. Cut the wait to two and a half days and the same developer merges 0.8 a day, without adding a single line of code [14]. The predictor and the outcome are two readings off the same queue.
The identity also predicts the shape of the result. For a fixed cut in wait time, the change in merges scales with work in progress, so teams already carrying the most open work move the most and teams carrying almost none barely move [15]. That is the reported pattern: strongest among the highest shippers, all but gone among the lowest [2]. A causal story fits the data. So does the arithmetic, and the arithmetic requires no one to behave differently.
For the correlation to support a claim about developer output, two things would have to hold. Work in progress per developer would have to be free to vary rather than pinned by how many branches a person can juggle. And "how much each developer shipped" would have to be counted in something a customer can receive, such as deploys or completed items, rather than merges. The note in DX's own writeup, that parked changes often spend significant time waiting and are neither being coded nor reviewed [4], argues for the queue reading. When the queue drains, what disappears is idle time, not effort recovered.
Then there is what the instrument can see. Accelerate's high performers kept fewer than three active branches at a time, each living under a day before it hit trunk [9]. Fowler's statement of the mechanism is that pre-integration review always introduces latency into integration and so encourages lower integration frequency [6]. A team working that way emits almost no PR duration data, so there is nothing to put in the quantile chart. A dashboard built on PR timestamps therefore ranks batching teams against each other and quietly drops the comparison that would settle the question. Timing the tea service is fine work, but filing it under running speed is the error.
A caveat on my read: I have not seen the DX article, and everything here about it comes from a dev.to post that quotes it. That post is by someone who says he is not a fan of pull requests and lost battles over them at Amazon [5], and who nonetheless grants that DX's data looks sound and the analysis appears correct while calling the framing exactly backward [3]. He wants the four DORA measures instead: deployment frequency, lead time for changes, change failure rate, and time to restore service [7], with trunk-based development named as a capability that predicts delivery performance [8].
In my context that is the right trade, and here is the context. Post-merge review and pairing [10] are only safe where fast pipelines and robust automated tests already exist [11]. Deleting the review gate without them moves risk, it does not remove it. The cost of getting off PR metrics lands on the test suite, and it lands before the dashboard changes.
