Is there a relationship between cycle time and PR throughput?
There’s a closer relationship between the two in high-throughput organizations. In low-throughput organizations, there are other variables at play.
Welcome to the latest issue of Engineering Enablement, a weekly newsletter sharing research and perspectives on developer productivity.
DX’s Q2 AI Impact Report is now available with the latest research on AI’s impact across engineering organizations. Read the full report.
When teams reduce the time it takes to complete a pull request, it’s natural to assume they’ll be able to deliver more work, but this relationship is rarely quantified at scale. A customer recently brought this question to DX’s Research team, asking us to look into the relationship between PR cycle time and PR throughput.
Key takeaway: High-throughput organizations are highly sensitive to long cycle times, potentially indicating that bottlenecks like review wait times are particularly acute for these orgs. For lower-throughput teams, there is no meaningful relationship between cycle time and throughput, suggesting bottlenecks exist elsewhere.
Queuing theory behind cycle time and throughput
Little’s Law, a theorem from queuing theory, helps explain the relationship between three things: how much work is in progress (WIP), how quickly work gets completed, and how long each piece of work takes. For software teams, we can think of these as:
WIP: the number of pull requests currently open,
Pull Request (PR) Throughput: number of pull requests merged over a period of time, and
PR cycle time: how long a pull request takes to move from development through review and merge.
The equation is straightforward. When the amount and type of work stay relatively consistent, work that moves through the process faster can help a team complete more work over time. This relationship is commonly used to explain how software teams improve flow but it hasn’t yet been quantified in the developer productivity space.
Research by Maddila et al. shows that pull requests often spend significant amounts of time waiting, not being actively coded or reviewed, and implies that cycle time isn’t a fixed metric. Teams can recover some of that waiting time by improving the workflow around development and review, without changing the process of writing code.
To understand how PR cycle time relates to throughput, we looked at the relationship between median PR cycle time and average PR throughput per developer across organizations using data from 500+ DX customers from January-July 2026, inclusive.
Cycle time matters more for high-throughput organizations than it does low-throughput organizations
Our analysis suggests that PR cycle time is not a reliable standalone predictor of throughput. In the raw data, organizations with similar review speeds show a wide range of throughput levels, indicating that other factors, like PR size and organizational context, likely play an important role in determining output.
The median trend is relatively flat across most of the distribution, with throughput beginning to decline more noticeably only at longer cycle times. This indicates that reducing cycle time may not automatically increase throughput for every organization, particularly when teams are already operating within a typical throughput range.
Because median results can obscure differences across the performance distribution, we also used quantile regression to look at this relationship at the 25th, 50th, 75th, and 90th percentiles of throughput. This approach allows us to look at whether the association between cycle time and throughput changes for lower-, median-, and higher-throughput organizations.
The results show that the relationship between cycle time and throughput is concentrated among higher-performing organizations.
At the 25th percentile, there is no statistically significant relationship between cycle time and throughput (p=0.366, β=-1.1).
At the median, there is a modest but statistically significant negative relationship (p=0.0008, β=-4.0).
At the 75th and 90th percentiles, the negative relationship becomes substantially stronger and remains statistically significant (p=0.000, β=-11.7; p=0.000, β=-12.8).
In practical terms, high-throughput teams are the most sensitive to cycle time slowdowns. For teams already in the bottom 25% of throughput, cycle time barely matters. For teams in the top 10%, it matters quite a bit.
Final thoughts: Speed is a safeguard but not a universal solution
Across most organizations, throughput stays fairly steady as PR cycle time increases. The relationship between the two becomes more noticeable around 17 hours. Beyond that point, median throughput starts to decline. This makes 17 hours a useful inflection point, not a universal target. For teams below that point, reducing cycle time may not lead to a meaningful increase in throughput. But once cycle times go beyond it, longer review cycles may start to limit teams that have the capacity to deliver more.
Think of the 17-hour mark as a warning sign and not a productivity cutoff. Teams with longer cycle times may benefit from looking more closely at review queues, reviewer availability, PR size, and other sources of waiting. These results show an association, not proof that longer cycle times directly cause lower throughput. Cycle time is most useful when considered alongside quality, work complexity, team structure, and other developer-experience measures, not as a standalone productivity target.
This week’s featured DevProd job openings. See more open roles here.
Ashby is hiring an Staff Platform Engineer | Remote
Carta is hiring a Sr. Software Engineer II, Developer Experience | Santa Clara, CA; San Francisco, CA; New York, NY
Figma is hiring a Staff Software Engineer, Developer Experience | Remote; US
Mastercard is hiring a Vice President, Software Engineering | New York
Notion is hiring a Software Engineer, Developer Experience | Hybrid; Hyderabad, India