The Review Tax

Every organization knows how to add a review layer. Almost none know how to remove one.

Three layers of approval between an idea and its execution. Each layer adds roughly 10x to the timeline. Not linearly — multiplicatively. A 30-minute bug fix becomes a 5-hour code review cycle. Add an architect's design approval and you're at a week. Require cross-team scheduling and you're looking at a quarter.

Avery Pennarun published these numbers recently, and they land with the weight of something you already knew but hadn't calculated. Three layers. A thousand-fold slowdown. The math isn't complicated. The fact that almost nobody does it is.

The Ratchet

Review layers accumulate the way sediment does — one thin deposit at a time, each one reasonable in isolation.

A deployment breaks production. Someone proposes a review gate. The gate catches a problem six weeks later. The gate earns its keep. Nobody asks what the gate cost in the meantime — the dozens of deployments that waited an extra day, the context that decayed while code sat in a queue, the engineer who moved on to something else and now has to context-switch back to address review comments on work they finished last week.

This is how institutional friction works. Each layer makes individual sense. The compound effect is invisible because it manifests as absence — the features that didn't ship, the experiments that weren't worth the approval overhead, the talented people who left because they spent more time waiting than building.

The ratchet turns one direction. Adding a review layer has a visible champion — the person who remembers the outage. Removing one has no champion at all. Nobody gets promoted for eliminating a safety gate, even one that catches nothing.

Nobody Audits the Audit

Here's what makes the 10x figure diagnostic rather than merely alarming: it exposes a category error in how organizations think about process.

Review is treated as a fixed cost — a small toll for crossing a bridge. But it's not fixed. It's multiplicative. And the multiplication has secondary effects that don't appear on any dashboard.

Context decay. A developer finishes a change in 30 minutes. It sits in a review queue for two days. By the time comments arrive, the mental model has faded. The reviewer is reconstructing intent from code; the author is reconstructing reasoning from memory. Both are doing worse work than they would have done in the first hour.

Diffused responsibility. Pennarun nails this one: when multiple layers of review exist, each one slackens. The code reviewer knows QA will catch integration bugs. QA knows the architect already approved the design. The architect knows code review will catch implementation mistakes. Everyone's responsibility. No one's ownership.

Velocity as signal. Organizations that can't ship fast can't learn fast. Every review layer between observation and action is a layer between the organization and reality. Slow feedback loops don't just delay output — they degrade judgment. You can't develop intuition about what works when you're always looking at three-month-old data.

The pattern underneath: review layers don't just slow work. They degrade the conditions that make good work possible.

The Deming Inversion

In the 1950s, most manufacturing companies treated quality as an inspection problem. You built the thing, then quality-control inspectors examined it. If defects were high, you added more inspectors.

W. Edwards Deming walked into Toyota and proposed the opposite. Remove the inspection layers. Give every worker on the line the authority — and the responsibility — to stop production the moment they saw a defect. Build quality into the environment, not the review process.

The result is one of the most studied organizational transformations in history. Toyota didn't sacrifice quality by removing review layers. Quality improved. Not because the people were better, but because the system was designed differently.

The lesson isn't "trust your people." That's a platitude. The lesson is structural: when you design the environment so that the right action is the easy action, the review becomes unnecessary.

Pennarun arrives at the same place from a different direction. He argues that a code reviewer's real job isn't to review code — it's to figure out how to make their review comment obsolete. Found a confusing function? Don't just flag it. Redesign the interface so confusion is impossible. Caught a missing null check? Don't just comment. Add a type system that makes null checks automatic.

Every review comment that recurs is a failure of environmental design.

The Calculation Nobody Runs

Most organizations can tell you their headcount, their cloud spend, their revenue per employee. Almost none can tell you the cumulative latency cost of their approval stack.

Try it. Map every layer between "someone has an idea" and "that idea reaches a user." Assign each layer the 10x multiplier. A five-layer approval process — not unusual in an enterprise — means a 100,000x slowdown from the baseline of the work itself. Zero layers isn't the target. But the gap between that number and your actual timeline tells you how much of your process is process.

Now ask: what does each layer actually catch? Not in theory. In the last quarter, what specific failures did this review prevent? If the answer is vague or anecdotal, you're paying a compound tax for a benefit you can't measure.

This isn't an argument against all review. It's an argument against unmeasured review. The same rigor you'd apply to any other cost center — does this investment justify its return? — should apply to every gate in your process. But review is culturally exempt from ROI analysis. It carries the moral weight of "being careful," which makes it expensive to question and almost impossible to remove.

The question isn't whether review has value. It's whether the compounding cost of accumulated review exceeds the value of what it catches. In most organizations, nobody has ever done that math.

Designing the Environment

The alternative isn't recklessness. It's a different theory of safety — and Deming proved it works.

Force-based safety adds friction at each stage to catch problems before they propagate. Each layer is locally rational. The compound effect is a system that can barely move. Alignment-based safety designs the environment so problems are less likely to occur — clear ownership boundaries, modular architecture that limits blast radius, automated checks that run in seconds instead of human reviews that take days. The same inversion Deming demonstrated on the factory floor applies to any process with an approval stack.

The practical version:

• Replace review with tooling where possible. A linter that enforces style conventions eliminates a category of code review comments. An automated test suite that catches regressions eliminates a category of QA. Each automated check that replaces a human review layer removes a 10x multiplier from your stack.
• Shrink the blast radius instead of adding approval. If a mistake in one service can't cascade to others, you don't need cross-team review of every change. Modular boundaries do the safety work that review layers do, without the latency cost.
• Make ownership explicit. When one person or team owns a decision, they carry the full weight of its consequences. Diffused review diffuses responsibility. Clear ownership concentrates it — and concentrated responsibility produces better judgment than distributed review.
• Audit the audit. Once a quarter, measure what each review layer actually caught. If a gate hasn't prevented a meaningful failure in 90 days, it's not a safety measure. It's a ritual. Every organization has a theory of safety embedded in its process architecture. Most have never examined it. They've inherited layers, added layers, and never asked whether the compounding cost exceeds the compounding benefit.

The 10x rule is a diagnostic tool. Run the multiplication. See the number. Then ask the question that nobody asks: what would it take to design the environment so this review becomes unnecessary?

That's not a question about moving fast. It's a question about where safety actually lives — in the layers of inspection, or in the structure of the work itself.

Field Notes

• Avery Pennarun, "Every layer of review makes you 10x slower" (apenwarr.ca)
• W. Edwards Deming, Out of the Crisis (1982) — Toyota Production System principles