Cycle time vs lead time in AI-augmented engineering teams
Cycle time tracks how quickly code moves from commit to production (typically 2 to 7 days). Lead time tracks how quickly a feature moves from request to production (typically 2 to 8 weeks). AI tools reduce the first but rarely touch the second, and the widening gap between them reveals where your real bottleneck sits.
Cycle time vs lead time is a distinction that separates engineering managers who measure delivery speed from those who measure business speed.
Cycle time tracks how quickly code moves from commit to production (typically 2 to 7 days), while lead time tracks how quickly a feature moves from request to production (typically 2 to 8 weeks). AI tools reduce the first but rarely touch the second, and the widening gap between them reveals where your real bottleneck sits.
Most engineering teams track cycle time because it lives in their CI/CD pipeline and is easy to measure. Fewer track lead time because it spans product discovery, requirements gathering, design (both UI and technical), planning, engineering, testing, and finally releasing to users, which means pulling data from several systems.
But cycle time alone creates a dangerous blind spot. A team can have a 2-day cycle time and still take 6 weeks to deliver a feature if the bottleneck is upstream in product planning. AI tools make this blind spot worse by compressing the engineering phase while leaving everything else untouched.
What is cycle time and what is lead time?
Cycle time is the duration from the moment a developer commits code to the moment that code reaches production. It captures the engineering delivery pipeline: commit, code review, automated testing, staging, and deployment. The DORA 2024 Research Report measures this at the team level rather than the individual level, and calls it lead time for changes, a narrower span than the lead time defined below. Elite-performing teams get a commit into production in under one day, while low-performing teams take more than a month to do the same.
Lead time is the duration from a feature request (or user story creation) to production deployment. It captures the entire value stream: product discovery, requirements gathering, design, implementation, QA, and deployment. Lead time includes cycle time as a subset.
The critical difference: cycle time is an engineering metric. Lead time is a business metric. A CTO optimising for cycle time is making engineers faster, whereas a CTO optimising for lead time is making the organisation faster. These are not the same thing.
Why AI tools reduce cycle time but not lead time
AI coding assistants accelerate the implementation phase of software development. They generate boilerplate faster, auto-complete repetitive patterns, and reduce the mechanical effort of translating requirements into code. This compresses the implementation phase for boilerplate-heavy tasks. It does not automatically speed up delivery: DORA's 2025 report, drawing on nearly 5,000 technology professionals, found that AI adoption now correlates positively with delivery throughput but still correlates negatively with delivery stability, because a higher volume of change exposes weak testing and release practices.
But implementation is only one phase in the lead time journey. The Microsoft Research study on GitHub Copilot found that developers given the tool completed one controlled task, implementing an HTTP server in JavaScript, 55.8% faster than the control group. What the study does not measure is whether faster coding translates to faster feature delivery. In most organisations, it does not, because the bottleneck was never code writing speed. Three randomised field experiments at Microsoft, Accenture and a Fortune 100 manufacturer, analysed by researchers at MIT, found a smaller effect in real workplaces than the lab result suggests: about 26% more tasks completed per week.
An illustrative breakdown of where time goes in a feature delivery:
- Product discovery and requirements: 1 to 3 weeks. AI tools have no impact here.
- Design and technical planning: 3 to 7 days. AI tools have minimal impact.
- Implementation (coding): 2 to 5 days. This is the phase AI tools compress.
- Code review and QA: 1 to 3 days. AI tools have modest impact on review speed.
- Deployment: hours to 1 day. Already automated in most teams.
If the implementation phase is 20% of lead time, a 30% improvement in implementation speed yields a 6% improvement in lead time. That is a real gain, but it is too small to show up in the delivery numbers leadership reviews at board level. The CTO reports "cycle time dropped 30%", while the CPO reports "time-to-market is about the same". They are measuring different things.
What does the cycle time vs lead time gap reveal about your organisation?
The lead-to-cycle ratio is a diagnostic tool. When the gap widens after AI adoption, it tells you that engineering execution got faster but the surrounding processes did not keep pace. The bottleneck shifted upstream.
Scenario 1: both short, narrow gap (efficient delivery)
Cycle time under 3 days, lead time under 2 weeks. The organisation is delivering efficiently. Engineering execution is fast, and upstream processes (discovery, planning, design) are lean. This is the target state.
Scenario 2: short cycle time, long lead time (product bottleneck)
Cycle time under 3 days, lead time over 4 weeks. Engineers are fast, but features spend weeks in discovery, design reviews, or stakeholder approval. AI tools will not help here. Investment should go into product planning processes: faster discovery sprints, reduced approval layers, sharper requirements gathering, and product visibility tooling that shows where a request is currently sitting.
Scenario 3: long cycle time, long lead time (engineering bottleneck)
Cycle time over 7 days, lead time over 6 weeks. Engineering execution is slow and is a significant contributor to lead time. This is where AI tools can make a measurable difference by compressing the implementation phase.
How to measure cycle time vs lead time in your engineering org
Cycle time data lives in your version control and CI/CD infrastructure. Lead time data requires connecting your product management system to your deployment pipeline.
Cycle time measurement:
- Data source: Git commits, CI/CD pipeline logs, deployment records.
- Calculation: timestamp of production deployment minus timestamp of first commit on the branch.
- Tooling: GitHub Insights, GitLab Analytics, Bitbucket, Jenkins, LinearB, or Sleuth. These sit on top of the same commit and pipeline data listed above and turn it into a chart, so most teams never need to write custom Git queries.
Lead time measurement:
- Data source: Jira, Linear, Asana, or your product management tool, combined with deployment records.
- Calculation: timestamp of production deployment minus timestamp of story/ticket creation.
- Common pitfall: ticket creation date must reflect the actual feature request, not the day someone created the Jira ticket during sprint planning.
The lead-to-cycle ratio: divide lead time by cycle time. A ratio of 3:1 means non-engineering phases consume twice as much time as engineering. A ratio of 10:1 means engineering is a tiny fraction of delivery time. Track this ratio monthly to see if it is widening after AI adoption.
What should engineering managers do when cycle time vs lead time diverges?
A widening lead-to-cycle ratio after AI tool adoption is not a failure. It is information. It tells you the engineering constraint has been partially solved, and the next bottleneck is now visible.
If the gap is widening (short cycle, long lead), invest in product planning speed, not more engineering tools. Faster discovery, shorter design review cycles, and clearer requirements will compress lead time more than any CI/CD improvement.
Tetriz is building the measurement layer that tracks both cycle time and lead time across the full delivery pipeline, connecting AI tool adoption to business delivery speed. Join the early-access cohort to see where your real bottleneck sits.