How to Reduce Cycle Time (Fix the Waits, Not the Work)

TL;DR: Cycle time doesn't shrink by anyone typing faster. The elapsed time between "started" and "shipped" is overwhelmingly waiting: for a reviewer to pick it up, for a re-review, for a merge window, for a deploy. So the playbook is queue surgery, not motivation: split your cycle time into stages, find the one hoarding the hours, and apply the fix that matches that stage. Teams that do this usually find one stage owns most of the total, which is excellent news, because you only have to fix one thing first.

"Reduce cycle time" is the rare goal that survives translation to every altitude: the board hears faster time-to-market, the CTO hears fewer things in flight going stale, engineers hear less limbo between finishing work and seeing it live. But the phrasing smuggles in a wrong assumption: that the cycle is full of work that must go faster. Decompose any real team's cycle time and the work is a sliver; the rest is queues.

That's why pep talks, deadline pressure, and "urgency" never move this number. They push on the sliver. The queues don't care.

Step one: stop measuring the total

A single cycle-time number is unactionable by construction: it says delivery is slow and refuses to say where. (It also gets conflated with its cousin; cycle time vs lead time is worth thirty seconds of disambiguation.) The decomposition that makes it actionable splits every merged PR's life into four stages:

• Pickup: ready for review → first reviewer activity. This is the classic silent killer: LinearB's benchmarks across 8.1M+ PRs band elite pickup under 1 hour and "needs focus" above 16. For calibration on the whole process, Google's study of ~9 million reviewed changes found a median under 4 hours for the entire review, with small changes getting first feedback inside an hour. If your PRs wait days for a first look, you've likely found your stage already.
• Review: first activity → approval. When this stage dominates, it's rarely reading speed: it's re-review loops, oversized diffs, and threads that re-litigate scope.
• Merge: approval → merged. An approved PR that sits is pure process loss: flaky CI, merge trains, "waiting for the release branch."
• Deploy: merged → live. If this is your monster, your bottleneck isn't the team at all; it's the release process.

Compute the median per stage over your last month of merged PRs, and let the shares argue. This is flow efficiency made concrete: touch time versus wait time, per stage, with the guilty queue named.

Step two: apply the fix that matches the stage

If pickup dominates (most common): two moves. Shrink the batch first: small PRs win on the data, because a 2,000-line diff is precisely the one a busy reviewer keeps not starting, and the SmartBear/Cisco research shows review effectiveness collapses past ~500 lines per hour anyway. Then set a pickup working agreement - first response within one business day is achievable for most teams. If everything queues behind one person, that's a review concentration problem with its own playbook.

If review dominates: same batch-size lever, plus better PR framing (descriptions that let a reviewer start without an archaeology dig) and a hard look at whether re-review loops are scope fights that should have happened before the code was written.

If merge or deploy dominates: this is infrastructure, and it's usually the cheapest win on the board: fix the flaky suite, automate the release step. Deploy-stage pain compounds quietly into shipping once a month, which caps every other improvement.

Whatever the stage: cap work in progress. Queues form because too much is in flight; WIP limits attack the cause, and a monthly sweep of stale in-progress work clears the zombies that fake speed can't. This is also the honest speed play per DORA. Their 2023 research found teams with faster code reviews report ~50% higher delivery performance, and a decade of results says speed and stability improve together when the batch is small. What you must not do is buy pickup speed with unread approvals: rubber-stamp reviews just relocate the delay into rework, the one queue that also breaks production.

How you'd actually see this in Busfactor

The month-of-medians spreadsheet is exactly the analysis that gets built once, wins one retro, and dies. Busfactor's cycle-time anatomy runs it continuously from your GitHub data: every qualifying PR split into pickup → review → merge → deploy, medians and shares per org, per team, and per person, with the slowest PRs attached as receipts. "Delivery is slow" arrives pre-diagnosed as "review pickup owns most of your cycle, these are the fourteen PRs that waited longest, this is whose queue they waited in."

The PRs that struggled view catches the tail the medians hide: the outliers that fought through many rounds and long stalls, judged against your own org's percentiles rather than an arbitrary cutoff. And where the sample is too thin to grade honestly, it shows the count instead of a fake verdict.

The honest limits: the anatomy sees repo events. A wait that happened outside them - the review agreed in a call, the deploy gated on a compliance sign-off nobody logged - shows as unexplained stage time, and the tool says so rather than inventing a cause. And speed is never graded alone: cycle time improvements that show up alongside rising rework get called out rather than celebrated. The point was never merging faster; it was shipping things that stay shipped.

The door

Pull one month of merged PRs this week and compute four medians. One stage will own the total - it nearly always does - and that stage's fix is listed above, none of which require a reorg, a new framework, or anyone working weekends. Then, if you want the decomposition running permanently, with receipts, at every grain from org to person: see where your weeks actually die. Cycle time is the rare metric where the first honest look usually pays for itself in the same quarter.