Code review SLAs: The Common Fix That Doesn’t Fix Anything

Every engineering team hits this moment. Pull requests are piling up, releases are slowing down, and someone says:

“Let’s add a Service Level Agreement — every PR must be reviewed within 24 hours.”

It sounds like a great idea. If reviews are slow, let’s just make them faster.

But it rarely works. Cycle times don’t drop. Delivery doesn’t speed up. The team feels busier, not better.

To understand why, let’s look at this problem through the Theory of Constraints (TOC) — using five simple ideas: throughput, cycle time, inventory, operating expense, and lead time.

1. A Quick Primer: How TOC Sees a System

TOC says every system has one main constraint — the slowest step that controls the overall pace. Everything you do to improve other parts of the system won’t help unless you improve that constraint.

To measure progress, TOC uses three core metrics:

• Throughput: How much value you actually deliver — working, merged, deployed code.
• Inventory: Work that’s started but not finished — PRs, unmerged code, or rework.
• Operating Expense: The total effort spent to keep things moving — developer time, meetings, monitoring, etc.

Cycle time and lead time are the visible effects:

• Cycle time = how long a PR takes from open to merge.
• Lead time = how long a feature takes from start to production.

If you want faster flow, you must find the constraint and increase its throughput — not just force it to work faster.

2. Case Assumptions

Let’s make our case clear with a realistic setup:

• Developers can take as long as needed to author a pull request (no SLA on authoring).
• Once a PR is opened, there is an SLA — it must be reviewed within 24 hours.
• The author does not start new work while waiting for review.

Even in this ideal and disciplined scenario, SLAs on code reviews don’t help throughput or cycle time. They only move pressure around.

3. What SLAs Actually Do to Flow

a. Throughput Doesn’t Increase

An SLA doesn’t make reviewers more available or skilled. If the team can properly review five PRs of a certain size in a day, forcing 24-hour reviews doesn’t make that number go up. It just makes reviewers rush through them.

The result? More shallow reviews, more bugs, and more rework — which quietly eats into real throughput.

b. Inventory Grows in Disguise

Every half-reviewed PR or rushed merge is unfinished work hiding as progress. When rework increases, your inventory of half-done work grows — even though dashboards show things “moving.”

The system looks faster, but actual completion slows down.

c. Cycle Time Gets No Better

Cycle time isn’t just about review speed. It’s about the total time a piece of work spends in the system — waiting, reworking, retesting, redeploying.
A quick review that leads to a bug later only restarts the cycle. So SLAs improve the visible metric (review time) while harming the real one (delivery time).

d. Operating Expense Rises

To meet review SLAs, everyone works harder:

• Reviewers context-switch more often.
• Developers keep pinging for attention.
• Managers spend time tracking compliance and chasing metrics.

All that activity adds operating expense — more time spent managing the system instead of improving it. So even if cycle time looks stable, the system is now more expensive to run.

4. The Core Issue: You Can’t Schedule a Constraint

If code review is your bottleneck, no timer will fix it. You need to elevate the constraint, not pressure it.

Here’s how:

• Limit WIP (Work in Progress):
  Fewer active PRs mean less waiting and less context switching. The same reviewers now have more focus — increasing true throughput.
• Distribute review load:
  Train more people to review certain parts of the codebase. Don’t make one person the single gatekeeper. Pair programming can be an even better approach.

5. How Pair Programming or Training Helps — Through the Lens of Little’s Law

Up to this point, we’ve seen how relying on a limited review capacity turns into a bottleneck — cycle times rise, throughput drops, and inventory of pending pull requests keeps growing. To understand why this happens, and how to fix it, let’s bring in a simple but powerful principle from queueing theory: Little’s Law.

WIP= Throughput × Cycle Time

In plain terms, the more work you have in progress (WIP) and the slower your throughput, the longer each piece of work takes to complete (cycle time).

When one person acts as the sole gatekeeper for code reviews, throughput is constrained by that person’s availability. Pull requests continue to arrive faster than they’re reviewed, causing WIP to rise. According to Little’s Law, this automatically stretches cycle time — developers wait longer for reviews, features take longer to reach production, and the team’s throughput suffers.

Training more people to review specific parts of the codebase changes that equation. With more reviewers available, throughput increases. For the same WIP, that means shorter cycle times — code moves faster, lead times shrink, and the overall operating expense (time spent waiting, recontextualizing, or fixing merge conflicts) goes down.

Pair programming amplifies this effect. Instead of queuing work for later review, feedback happens in real time as code is written. WIP in that flow is practically zero, which — by Little’s Law — means cycle time also approaches zero.

The outcome is a smoother, faster flow of value:

• Higher throughput, since work moves continuously.
• Lower operating expense, as developers spend less time idle or revisiting old changes.
• Reduced inventory, with fewer pull requests piling up in review queues.

In short, pairing and distributed review training aren’t just collaboration techniques — they’re direct levers to optimize system flow. They help the team operate closer to steady state, where every change moves predictably from authoring to production without unnecessary waiting.

6. The Better Question

Instead of asking:

“How can we make reviews faster?”

Ask:

“What limits our throughput — and how can we increase it?”

If reviews are slow because too many PRs are open, limit WIP.
If reviewers are overloaded, share the load.
If rework keeps coming back, improve review quality instead of speed.

Automate what doesn’t need human judgment:
Formatting, linting, and coverage checks shouldn’t consume review time.

Measure throughput and lead time, not SLA compliance:
The right metric is: “How long does it take for code to reach production?” Not: “How fast did we review it?”

Make the queue visible:
If everyone can see what’s waiting for review, they can help manage flow collectively instead of relying on reminders.

The goal isn’t to beat the clock — it’s to improve the system’s ability to deliver completed work. SLAs optimize compliance, not flow.

7. Closing Thought

SLAs make teams look efficient, but they don’t make the system effective.

They hide the real constraint behind metrics, increase operating expense, and reduce throughput. They fix symptoms, not causes.

The next time someone proposes a review SLA, pause and ask:

“Will this actually increase throughput — or just add more work?”

Because the fastest systems aren’t the ones with the tightest rules —
they’re the ones that understand where time truly gets stuck.