Summary
- Engineering efficiency measures how much of the pipeline's time is spent moving work forward versus waiting between phases.
- Agentic pull requests wait 17.6 hours before review at the 75th percentile versus 3.4 hours for unassisted work, per LinearB's 2026 Benchmarks Report.
- Elite cycle time sits under 25 hours and elite pickup time sits under one hour at the 75th percentile, which gives you the two tightest bands to target first.
- Efficiency gains that raise change failure rate are not gains, since elite change failure rate sits under 1% and the lowest tier runs above 17%.
- Syngenta cut cycle time by 81% by decomposing the pipeline and automating the phase that was absorbing the most time.
What is engineering efficiency?
Engineering efficiency is how much of your delivery pipeline's total time is spent moving work forward versus waiting, and in the 2026 data the waiting dominates. LinearB's 2026 Software Engineering Benchmarks Report, built from more than 8.1 million pull requests, found that pull requests created by AI agents wait 17.6 hours before review at the 75th percentile against 3.4 hours for unassisted pull requests, a 5.25x difference. Efficiency is a phase-by-phase property of the pipeline rather than a measure of individual effort, and the fastest way to raise it is to find the single phase absorbing the most time and fix that one first. This page defines engineering efficiency, gives the 2026 phase-level bands, and sets out the decomposition method that finds the constraint.
Efficiency is one of four pillars in a broader operating model, and it works alongside predictability rather than instead of it. See engineering metrics benchmarks for the full tier-by-tier view.
Engineering efficiency is the share of total pipeline time spent moving work forward, measured phase by phase from first commit to release. A team is efficient when the gap between coding and shipping is mostly work rather than waiting, and the 2026 data shows waiting dominates in the phase right after code is published.
Efficiency is decomposition, not speed
Treating efficiency as a single speed target produces the wrong fix, because a slow cycle time can come from five different phases and each one needs a different response. Coding time, pickup time, approve time, merge time, and deploy time each carry a distinct failure mode, and only decomposition tells you which one is yours. A team that halves its coding time while pickup time stays at 16 hours will not see its cycle time move.
The 2026 data shows where the waiting concentrates for AI-driven work specifically. Pickup time for agentic pull requests runs 17.6 hours at the 75th percentile against 3.4 hours for unassisted work, while review time once picked up is comparable or faster for AI-assisted pull requests, at 3.2 hours against 4.2 hours for unassisted work. The bottleneck is not the reviewing, it is the wait to start. For the phase definitions themselves, see cycle time and how to calculate cycle time.
What to do next: Pull your own pickup time and review time side by side. If pickup dwarfs review, your efficiency problem is routing and ownership rather than review capacity.
The 2026 efficiency bands
Elite efficiency keeps cycle time under 25 hours and pickup time under one hour at the 75th percentile, according to LinearB's 2026 Software Engineering Benchmarks Report. The table below gives the full set of phase bands.
| Metric | Elite | Good | Fair | Needs improvement |
|---|---|---|---|---|
| Cycle Time (hours) | < 25 | 25 - 72 | 73 - 161 | > 161 |
| Pickup Time (hours) | < 1 | 1 - 4 | 5 - 16 | > 16 |
| Review Time (hours) | < 3 | 3 - 14 | 15 - 24 | > 24 |
| Deploy Time (hours) | < 16 | 16 - 106 | 107 - 277 | > 277 |
| PR Size (lines) | < 100 | 100 - 155 | 156 - 228 | > 228 |
| Merge Frequency (per dev/week) | > 2.0 | 2 - 1.2 | 1.2 - 0.66 | < 0.66 |
Deploy time carries the widest range of any phase, running from under 16 hours at elite to beyond 277 hours in the lowest tier, which makes it the phase where a single automation investment can move the aggregate the most. Compare against your organization size band rather than the full data set, since enterprise organizations above 1,000 employees reach elite cycle time under 27 hours against under 25 for the aggregate.
What to do next: Place your own phase values in these bands and rank them by distance from elite. The largest gap, not the slowest absolute number, is your target.
APEX efficiency: the four-step method
Efficiency is one of the four APEX pillars, and its method is decomposition followed by automation rather than a general push for speed. The full model, including the other three pillars, is in the APEX framework.
- Decompose cycle time into its phases every time you report it, since a total obscures which handoff needs attention.
- Benchmark each phase against the band for your organization size, recording the gap in hours.
- Isolate the phase with the largest gap and segment it by team, repository, and pull request type to locate where it concentrates.
- Automate the handoff inside that phase and re-measure after one full sprint before touching a second phase.
Predictability is the pillar that keeps this method honest, since change failure rate is the guardrail against efficiency gains that shift cost into production. Elite change failure rate sits under 1%, and the lowest tier runs above 17%. For the counterpart pillar, see software delivery predictability.
What to do next: Run steps one through four on a single repository this month rather than the whole organization. A proven fix on one pipeline is a stronger case than an analysis with no automation attached.
What efficiency gains look like in practice
Syngenta cut cycle time by 81%. Yum! Brands automated 321 developer hours per month. Expedia Group ran more than 3 million automations, including over 200,000 pull request automations, and reinvested 2,000 developer hours per month while improving developer satisfaction by 22%, which shows efficiency and developer experience moving together rather than trading off. Each result followed the same sequence of decomposing the pipeline, isolating the constraint, and automating the handoff. Workflow automation is where the fourth step happens.
What to do next: Choose the single handoff a human repeats on every pull request in your worst-gap phase, and automate that one first.
Frequently asked questions
What is engineering efficiency?
Engineering efficiency is the share of total pipeline time spent moving work forward rather than waiting between phases, measured from first commit to release. It is a property of the delivery system rather than a measure of how hard individual developers are working.
How do you measure engineering efficiency?
Decompose cycle time into coding, pickup, approve, merge, and deploy phases, then compare each against the benchmark band for your organization size. The phase with the largest gap from elite is where efficiency work should start.
What is a good cycle time for engineering efficiency?
Elite cycle time is under 25 hours and good is 25 to 72 hours at the 75th percentile, according to LinearB's 2026 Software Engineering Benchmarks Report. Enterprise organizations above 1,000 employees reach elite under 27 hours.
Why do AI pull requests hurt engineering efficiency?
They do not hurt review speed, they hurt pickup time. Agentic pull requests wait 17.6 hours before review at the 75th percentile against 3.4 hours for unassisted work, while review time once picked up is comparable or faster for AI-assisted pull requests. The efficiency loss is in routing and ownership, not in review capacity.
Can you improve efficiency without hurting quality?
Yes, provided you pair every efficiency target with change failure rate in the same report. Elite change failure rate sits under 1%, and a cycle time improvement that pushes failure rate toward the 17% tier is a cost shift into production rather than a genuine gain.