Cycle time varies wildly; a large study shows tiny effects from PR count, comments, coding days, and defects, urging leaders to focus on system-level improvements rather than individual blame.
Cycle time is tempting because it's easy to measure, but the reality is that a developer's speed fluctuates so much that any single number tells you almost nothing about true performance. The paper cited in this piece shows that variability overwhelms signal, and that focusing on individual metrics leads to misdirected blame.
The authors analyzed data from nearly 12,000 contributors across over 200 organizations, measuring coding days, total merged pull requests, comment depth, and defect rates. Their findings: more merged PRs and more coding days per week modestly reduce cycle time; more comments per PR and higher defect percentages increase it. Even the strongest effects are tiny compared to the massive month-to-month variation within a single developer.
Because the noise is so large, comparing developers side-by-side is almost meaningless. The myth of the "10x developer" collapses when you see that a person's cycle time can swing wildly from one month to the next, making any snapshot unreliable for performance judgments.
The practical takeaway for leaders is to shift the lens to the team level. Track aggregate trends over months, pair the numbers with qualitative signals, and prioritize system-wide improvements-better tooling, clearer processes, and healthier collaboration-over trying to tweak individual behavior.
In short, cycle time can be a useful aggregate indicator, but only when you treat it as a weather pattern, not a fixed trait. Embrace the variability, stop hunting for silver bullets, and invest in the environment that lets teams deliver consistently.
Check out the full stdlib collection for more frameworks, templates, and guides to accelerate your technical leadership journey.