Avery Pennarun published a piece this week arguing that each review layer in a software development process doesn’t add latency, it multiplies it. Ten times per layer is his estimate. I’ve been sitting with this for a day, and the claim matches something I’ve felt for years without having clean language for it.
I ship Discord bots as a side project. I write the code, I deploy it, I fix it when it breaks. The only review gate is whether I think the change is good enough to push. Most changes go from idea to running in production in under two hours. When I join a larger team or contribute to a project with formal review requirements, I feel the gear shift immediately. The work doesn’t get harder. The calendar gets slower. Understanding why that happens, and why it gets geometrically worse as you add more layers, is what Pennarun’s piece is really about.
The Queue Nobody Draws
Every process diagram I’ve seen in a software organization draws code review as an arrow. Work moves from ‘author submits’ to ‘reviewer approves.’ The arrow looks lightweight. What the diagram omits is that the arrow isn’t a transfer, it’s a queue, and queues have wait times that bear almost no relationship to the work being done.
The M/M/1 queue model from queuing theory is the right frame here. For a single server processing requests, average wait time scales with 1/(1-ρ), where ρ is the server’s utilization, the fraction of its capacity currently being consumed. At 50% utilization, wait time is 2x the service time. At 80%, it’s 5x. At 90%, it’s 10x. At 95%, it’s 20x. The curve is nonlinear and it gets steep fast.
Senior engineers, the people whose review actually means something on most teams, are almost always heavily loaded. They have their own code to write, architectural questions to answer, incidents to handle, and other PRs to review. Putting them at 85-90% utilization as reviewers is not unusual. At 90%, every PR they touch spends ten times longer waiting than the review itself takes.
Now chain two of those reviewers in sequence. Little’s Law tells us the average number of items in a stable system equals arrival rate times average time in the system. At the pipeline level, a PR waits in multiple queues simultaneously, and the total wait compounds: two reviewers at 90% utilization gives 10x times 10x, not 10x plus 10x. Three layers at 90%: roughly 1,000x. The work hasn’t changed. Only the process structure has.
What the Research Shows
This isn’t just theory. The DORA program, whose findings are compiled in Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim, has tracked engineering teams across thousands of organizations annually since 2014. The data is unambiguous: elite teams have lead times under one day, often measured in hours. Low-performing teams measure lead time in weeks or months.
The gap is primarily not in how fast people write code. It’s in how long changes sit in approval queues. The State of DevOps research identifies streamlining change approval as one of the technical capabilities most strongly correlated with software delivery performance. Elite teams that replaced sequential manual approval gates with peer review plus automated testing saw better performance across all four core DORA metrics, including change failure rate. More review didn’t produce better quality. Less queue-intensive review did.
The uncomfortable implication is that organizations with the heaviest review cultures are not more careful. They are slower and roughly equally error-prone, because the errors they prevent through manual review are offset by the errors introduced through large batch sizes, stale context, and the pressure to rush once a merge finally lands.
Quality Review vs. Compliance Review
Here is a distinction I keep coming back to, and one I think Pennarun gestures at without fully naming. There is a material difference between quality review and compliance review, and most organizations have far more of the latter than they realize.
Quality review is done by someone who is technically invested in the outcome. They have standing to veto for real reasons. They will be on-call when the change causes an incident. They care whether the code is good because bad code falls on them. This kind of review is worth its queuing cost. The reviewer is a principal with skin in the game, and the judgment they apply is genuinely unavailable elsewhere.
Compliance review is done by someone whose job is to check a box. They are not on the hook for the result. Their approval means ‘I reviewed this,’ not ‘this is correct.’ A security team that reviews every pull request but is not paged when a vulnerability ships is doing compliance review. A DBA who approves schema migrations but does not own the database’s reliability is doing compliance review. An architecture committee that signs off on designs but does not maintain the systems those designs produce is doing compliance review.
Compliance review is almost perfectly optimized to produce queue latency without producing safety. The reviewer is not motivated to be thorough because their career is not affected by the outcome. The author is not motivated to produce high-quality proposals because the bar for approval is box-checking, not correctness. The queue overhead is real. The error-catching is marginal. This is not a knock on the individuals involved. It is a structural observation about what rational behavior looks like when accountability and authority are separated.
The Org Chart Rendered as Process
Conway’s Law, stated by Mel Conway in 1968, says that organizations design systems that mirror their own communication structures. It applies to code architecture. It applies equally to review processes.
The number of sequential review layers a change requires almost exactly matches the number of team boundaries it crosses. A change touching frontend, backend, and infrastructure passes through three teams’ authority hierarchies, so it needs three approvals. CODEOWNERS files in GitHub make this explicit: they are the org chart encoded as a configuration file, specifying which team must review changes to each path.
This means that reducing review layers without changing the org structure usually doesn’t stick. You can remove the explicit approval requirement, and within months informal approval channels emerge to fill the same role: a Slack message asking for someone to look at it, a verbal nod sought before pushing to production. The authority boundaries are real, and they find mechanisms to express themselves whether or not those mechanisms appear in your documented process.
Genuinely fixing the compounding review problem requires redistribution of ownership and accountability. Teams organized around product or service flow rather than technical function cross fewer authority boundaries with standard changes. A team where frontend, backend, and infrastructure engineers share ownership of the product they’re building can review that product’s changes internally without routing through three separate approval queues. When the team writing the code is also the team paged at 3am for its failures, they have personal reasons to review it carefully and to target external help on specific risk areas, rather than routing everything through generalist approval layers.
What the Wait Does to the Author
I want to be specific about what happens to the person who submitted the work, because this part tends to get overlooked in discussions that focus on process metrics.
A PR submitted on Monday morning that receives its first review comment on Wednesday afternoon has spent two and a half days in transit. By Wednesday afternoon, I have been working on other things. The feature I was building, the constraints that shaped my decisions, the alternative approaches I considered and rejected, all of that is substantially less accessible than it was Monday morning. Returning to a multi-day-old PR with substantive feedback requires rebuilding a mental model that partially decayed. Research on developer context-switching puts the recovery time after a significant interruption at over twenty minutes. For a complex PR with a full revision cycle, the reconstruction is longer and less complete.
Developers adapt to this rationally. If every PR takes three days to get reviewed, you batch more work into each submission to amortize the wait. A week’s worth of changes goes in one PR instead of five. This makes each review harder, produces more comments, extends revision cycles, and trains the system to move in larger and slower increments. The slowness compounds in a feedback loop that has nothing to do with queuing theory and everything to do with how people respond to incentives. Research from LinearB tracking over 2,000 engineering teams found that teams with review cycle times over 24 hours had median PR sizes roughly three to four times larger than teams with cycle times under four hours. You’re not just measuring the queue. The queue is reshaping the work being submitted to it.
What Fast-Shipping Organizations Do
The empirical answer from DORA and from organizations that ship continuously is not fewer people looking at code. It is fewer sequential human queues in the path from commit to production.
Trunk-based development with feature flags is the structural foundation. Engineers commit to the main branch continuously, or use feature branches measured in hours. Feature flags decouple deployment from release: a change can land in production while the feature it introduces remains invisible to users. The blast radius of any individual merge stays small, which means the review cycle can be short and iterative rather than thorough-because-blocking.
Automated gates replace human gates for the mechanical categories of quality check. Static analysis, type checking, test coverage thresholds, security scanning, dependency audits: all of these run in CI with zero queue wait time because they have no utilization in the queuing sense. They run immediately. The human review they replace was operating at 85% utilization, which means 7x overhead on review work time. Automation eliminates that overhead entirely.
Pair programming solves the queue problem completely. Code written by two people is code that has already been reviewed, in real time, by someone who understands the context. There is no review queue because the reviewer was present during implementation. The synchronous overhead is real, but the queue overhead is zero. For teams where review bottlenecks dominate cycle time, this tradeoff deserves more serious consideration than it typically gets.
Post-merge review is used by some teams for low-risk paths: the change goes to production, monitoring and automated rollback act as the safety net, and a reviewer reads the code afterward. The reviewer still provides feedback. They just don’t block the merge. The code ships; the conversation continues. For product software with good observability, this removes the queue entirely for change categories where the cost of a mistake is recoverable.
The Solo Developer Baseline
When I build a Discord bot feature alone, end-to-end cycle time from idea to deployed code is typically under two hours for anything modest. There is no waiting. There is no context reconstruction. There is no batching driven by amortization of queue overhead. The only gate is my own judgment about whether the change is ready.
That zero-overhead baseline is not achievable in team development. But the gap between zero and whatever a specific process costs is worth measuring precisely. Adding one asynchronous human approval gate at 90% reviewer utilization turns the zero into a 10x multiplier on review time. Adding a second turns it into 100x. Adding a third turns it into 1,000x.
The framing I find most useful is this: what is each review layer actually protecting against, and is the protection it provides worth its queuing cost? For changes behind a feature flag, with automated checks passing, touching code the author also owns and is paged for, the marginal protection of a compliance review is approximately zero. The queue latency is approximately ten times the review time. The math is not close.
Some layers earn their cost. A genuine peer review from someone who will maintain the code and bears the consequences of its failures has real value, and a motivated reviewer who responds quickly can hold the queue multiplier near 2x rather than 10x. The question is how many of the approval layers in a typical enterprise process fall into that category, and how many are the accumulated scar tissue of post-mortems written by teams that never did the accounting on the other side of the ledger. Pennarun’s piece is useful precisely because it makes that accounting legible. The math was always there. Most organizations have just been choosing not to run it.