What cycle time measures

Cycle time is a flow metric. It captures the clock time between the first commit on a piece of work and the moment that work is running in production. Shorter cycle time means work moves through review, testing, and deployment with less delay.

It is usually reported as a distribution, not an average. The median tells you the typical experience. The 85th and 95th percentiles tell you where work gets stuck, which is the number worth managing.

How to measure it

Read the timestamps from git and your deploy pipeline. The start is the first commit on the branch or the moment work begins. The end is the production deployment that includes it. Subtract the two. Aggregate across a window and look at the percentiles, not the mean, because a few stuck items distort the average.

The common breakdown is into four stages: coding time, pickup time (waiting for review), review time, and deploy time. The stage with the longest tail is where your delivery actually slows down.

What it does not tell you

Cycle time measures speed. It says nothing about what was built or whether it mattered. A team can drive cycle time to elite levels while shipping work that advances no initiative the business cares about. Fast delivery of the wrong thing is just faster waste.

This is the gap between activity metrics and Execution Intelligence. Cycle time is a real, useful signal of delivery health. It is not a signal of whether engineering effort is pointed at the right work.

How InteliG uses it

InteliG reads cycle time from the same git and deployment timestamps, then connects it to the work it belongs to. Every unit of delivery is linked to its initiative, its contributors, and its cost, so cycle time becomes one input to a larger question: is the organization moving fast on the things that matter, and what is each of those things costing.

Related terms

DORA Metrics — the delivery-performance framework cycle time feeds into
Execution Intelligence — reading not just how fast, but what is being built and why