The math on compounding review overhead is now well-established. Avery Pennarun’s recent post makes the core claim precisely: each review layer multiplies rather than adds to cycle time, with 10x per layer being a realistic estimate at typical reviewer utilization. The queuing theory behind it is sound. Busy reviewers create queue buildup that vastly exceeds their actual review time, and chaining queues produces costs that compound rather than accumulate.
Most of the conversation that followed treats this as a process problem to be fixed with better tooling, stricter SLAs for reviewers, or smaller PRs. All of those improvements help at the margin. But the underlying structure is organizational. You can eliminate a review step from your documented flow, and most teams find it returns within six to twelve months, because the conditions that generated it are unchanged.
Conway’s Law Extends Past Code
Mel Conway’s 1968 observation, that organizations which design systems are constrained to produce designs which copy their communication structures, is most often cited in the context of service boundaries and API shapes. It applies equally to approval processes.
The number of sequential review layers a pull request requires reflects the number of authority boundaries the change crosses. A change that touches frontend code, backend logic, and a shared infrastructure layer will require sign-off from the owner of each area, because each area sits inside a different team’s authority hierarchy. The review layer count is a direct function of how many teams own pieces of what you are changing.
GitHub’s CODEOWNERS file makes this explicit. It is a precise map of authority boundaries encoded into a configuration file, where each entry specifies which team must approve changes touching a given path. This is a useful feature that makes implicit authority visible, but it also makes sequential multi-team review easy to encode and difficult to remove. Changing a CODEOWNERS entry requires a conversation with the team being removed from it, and that team has standing to object on the grounds that the change crosses into territory they are accountable for.
Process documentation rarely captures the full picture anyway. A team might document “one reviewer approval required to merge,” but the actual process includes a tech lead check, a Slack message to the platform team, and a verbal okay from the security engineer before anything sensitive goes out. These informal layers exist because authority boundaries exist. Writing them out of the documented process does not move the authority; it just makes it invisible to anyone measuring cycle time.
Review Layers as Principal-Agent Checkpoints
Each formal or informal review layer is a checkpoint where a principal, the party who owns the outcome, verifies that an agent, the party who implemented the change, made choices consistent with the principal’s interests. That framing makes clear why review layers are not arbitrary bureaucracy. They are the mechanism by which distributed authority manifests in day-to-day engineering work.
If a DBA owns database reliability, a security team owns vulnerability response, a platform team owns the deployment pipeline, and a product team lead owns delivery commitments, you have four principals with standing interests in most production changes. Each of those principals will find a mechanism to exercise their authority, whether through formal review gates, mandatory ticket approvals, informal sign-off requests, or post-merge comments that generate revision work.
Teams that eliminate formal review layers often find them replaced by informal ones. A Slack message from a senior engineer saying “can you check with X before this goes out” carries all the same queue properties as a formal reviewer assignment. It waits for X’s availability, requires context transfer, and can generate revision cycles. It just does not show up in PR metrics, which makes it invisible to the cycle time dashboard while remaining fully real in practice.
What Structural Change Actually Requires
The fix is redistributing authority, not removing checkpoints. These are distinct operations that require different organizational moves.
The most direct mechanism is ownership of consequences. Teams that are on-call for a service develop substantial authority over changes to that service, because they absorb the cost when something goes wrong at 3am. A team that owns the alert has standing to own the review, without needing a gatekeeping sign-off from parties who will not be paged when the change causes an incident. The accountability and the authority align.
The Team Topologies framework, developed by Matthew Skelton and Manuel Pais, provides a structural vocabulary for this problem. Stream-aligned teams, organized around product or service flow rather than technical function, minimize the number of authority boundaries a standard change crosses. When frontend engineers, backend engineers, and infrastructure engineers sit within the same product team rather than separate functional orgs, a full-stack change crosses one authority boundary instead of three.
Centralized specialists, a dedicated security team, a separate database team, a platform org that reviews all infrastructure changes, each introduce an authority boundary that every change touching their domain must cross. Embedded specialists, security engineers and data engineers sitting inside product teams, can provide equivalent expertise without adding a sequential review queue. Their scrutiny happens alongside development rather than after it. The review does not disappear; the queue does.
The Structural Reversion Problem
Teams that reduce review layers through process changes alone tend to see those layers return within a year. The incident that re-establishes them is nearly guaranteed to arrive: a security issue that a security review would have caught, a data migration that a DBA review would have flagged. The case for restoring the layer is then identical to the original case for adding it, and the arguments against it, that the layer adds compounding overhead, have lost the rhetorical high ground to a concrete recent failure.
The only durable way to prevent reversion is to close the loop between who bears the consequence and who does the review. A security team accountable for production security incidents has genuine incentives to shift security review left, toward automated scanning, threat modeling at design time, and security guidelines embedded in coding standards, rather than maintaining a sequential gate that compounds overhead while providing marginal late-stage coverage. Removing a gate while preserving the accountability that required it just shifts blame without changing outcomes.
When the team writing code is also the team paged for its failures, they have reasons to review it carefully themselves and to target help on specific risk areas rather than routing everything through a generalist approval layer.
What This Means in Practice
Measuring cycle time broken down by stage is the right starting point, as the DORA research in Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim consistently demonstrates. But measurement identifies where queues form; it does not explain why authority boundaries exist there, and it does not, by itself, give anyone the standing to remove them.
The practical question after looking at the data is whether the team that reviews a change is the same team that owns the outcome when the change is wrong. When those are the same team, review overhead is a cost they pay to protect themselves, and they have personal reasons to optimize it. When those are different teams, the reviewing team pays the overhead cost while the outcome team bears the risk, and neither has the full picture to rationalize the arrangement.
Pennarun’s framing puts the 10x cost per layer on the table as a starting point for the conversation. The organizational consequence that follows is that reducing from five layers to two requires not just agreement that five is too many, but redistribution of the accountability that currently requires five different sign-offs to satisfy. That redistribution involves changing team structure, incident ownership, and authority, none of which appear in a pull request template or a CODEOWNERS file.