A good cycle time is under 72 hours

At the 75th percentile, LinearB's 2026 benchmarks put elite cycle time under 25 hours and good cycle time between 25 and 72 hours. A 200-engineer organization is large enough that those aggregate tiers apply directly, and small enough that the enterprise adjustment (elite under 27 hours for companies above 1,000 employees) doesn't.

The number on its own is less useful than the breakdown. Cycle time is the sum of four stages of software delivery, from first commit to release, and at 200 engineers one of those stages is almost always carrying the whole gap. The tiers below are broken out stage by stage for that reason.

The tiers come from LinearB's 2026 Software Engineering Benchmarks Report, built from 8.1 million pull requests across roughly 4,800 engineering teams in 42 countries. Cycle time is measured from first commit to production release and calculated at the 75th percentile (P75) rather than the mean, so a handful of very long PRs don't distort the figure.

Tiers are defined by rank within the dataset:

Cycle time in this dataset is the sum of four stages, each benchmarked separately: coding time (first commit to PR opened), pickup time (PR opened to first review), review time (first review to merge), and deploy time (merge to release). Full tables are in the benchmarks report and the research hub.

Enterprise teams above 1,000 employees get a slightly looser elite bar (cycle time under 27 hours, deploy time under 25) because coordination cost rises with size. A 200-engineer org doesn't get that allowance, and usually doesn't need it. At that size an organization typically runs 10 to 25 teams, deploys frequently enough that deploy time isn't the dominant stage, and has enough reviewers that pickup time is a scheduling problem rather than a capacity one.

That's also the size where cycle time starts drifting without anyone owning it. Two or three teams can keep cycle time in their heads; twenty can't. Dan Lines, LinearB's co-founder and COO, describes what the benchmark does at that point:

"Let's see where you are from a benchmark perspective, and then let's decide together. It's pretty obvious where you'll, the same way the benchmark will select you."

— Dan Lines, co-founder and COO of LinearB, on Dev Interrupted, Stop measuring AI adoption. Start measuring AI impact.

The benchmark tells a 200-engineer org which stage to look at first. The headline number alone can't.

Take your P75 cycle time and the four stage figures, and compare each to the tiers separately. The pattern matters more than the total.

Cycle time in Good or Fair, with one stage in Needs focus. The most common shape at 200 engineers. One stage, usually pickup or deploy, is carrying the whole gap. Fix that stage; the total follows.

Cycle time in Good, with all stages in Good. Healthy. Moving to Elite means shaving hours off every stage rather than fixing one, which is a different, slower kind of work.

Cycle time in Needs focus, with coding time in Elite. Engineers are fast while the system around them stays slow. AI adoption produces this shape once generation outruns review and deploy, and it's where the 2026 data shows the sharpest divergence: agentic pull requests in this dataset wait 17.6 hours for review alone, against an elite pickup bar of under one hour.

Ben Lloyd Pearson, LinearB's Director of AI Innovation, on why the breakdown is the point:

"Any one of these stages could be your constraint within the system and you really need to go from that high level efficiency view all the way down to looking at the actual segments that are getting bottlenecked and which PRs are the ones that are causing those bottlenecks."

— Ben Lloyd Pearson, Director of AI Innovation at LinearB, on Dev Interrupted, Stop measuring AI adoption. Start measuring AI impact.

The cycle time diagnosis guide in this library covers how to run that investigation.

Cycle time measures speed, not value. An org can hit Elite on cycle time while shipping work nobody uses, and the 2026 report pairs cycle time with change failure rate and rework rate for that reason. A fast cycle time with a rising change failure rate is speed being paid for in incidents.

It also doesn't account for what's in the PR. AI-assisted PRs in the dataset run 2.5x larger at P75 than unassisted ones; an org whose PR size is climbing will see cycle time climb with it, and the fix is upstream of any stage.

The tiers describe the LinearB customer base, which skews toward teams that already measure delivery; a random 200-engineer company would likely benchmark lower against the general population than against this set. P75 is the recommended aggregation; comparing a mean or median against these tiers overstates or understates performance. The enterprise cut in the report is by company employee count, not engineering headcount, so a 200-engineer org inside a 5,000-person company may sit on either side of it.

What is a good cycle time for a software team?

Under 72 hours at the 75th percentile is Good in LinearB's 2026 benchmarks; under 25 hours is Elite. The tiers come from 8.1 million pull requests across 4,800 teams.

Does cycle time scale with team size?

Somewhat. Enterprise organizations above 1,000 employees get an elite bar of 27 hours rather than 25, reflecting coordination cost. Below that, the aggregate tiers apply.

Which cycle time stage matters most?

The one in the worst tier. At 200 engineers, that's most often pickup or deploy time. Coding time is rarely the constraint, and with AI adoption it's getting shorter while the stages after it get longer.