ESSAY · 2 min · 2026.04.06

Your CI isn't the bottleneck

Flow diagram: a small CI box (12 min) feeds into a giant dashed box labeled 'Review Queue, 8–24 hrs' stuffed with overlapping PR cards, which then funnels into a small Merge box (5 min).

A 12-minute CI pipeline feels slow. It shows up in dashboards. People complain about it. It gets optimized.

An 8–24 hour review delay? That just feels… normal. So it gets ignored — even though it dominates your actual time-to-merge.

The real queue is human

Most teams obsess over CI performance because it’s visible and measurable. You can point to a number, track improvements, and ship small wins. But CI is rarely the thing holding you back.

Pull requests don’t sit around waiting for tests to finish. They sit around waiting for humans. Waiting for context switches. Waiting for someone with the right ownership. Waiting for “I’ll take a look later.”

That’s the real queue.

Treat review like infrastructure

If you care about velocity, treat review capacity like infrastructure.

Measure it:

  • Time-to-first-review
  • Time between review cycles
  • Queue depth per reviewer

Staff it:

  • Make review a first-class responsibility, not background work
  • Balance ownership so the same people aren’t always the bottleneck

Automate the safe parts:

  • Catch obvious issues before a human ever sees the PR
  • Reduce the surface area reviewers need to think about
  • Auto-approve what’s low risk

Most teams are optimizing the fastest stage in their pipeline and ignoring the slowest one. CI feels like the problem. The review queue actually is.

esc
Like the background? ↗