A monorepo requires code-owner approval on every PR that touches a shared `libs/common-utils` package used by 30 teams. What problem does this create, and what are two ways to fix it without removing the review requirement entirely?
answer
- shared-package bottleneck
- decompose by subpath
- narrow API surface gate
- round-robin team ownership
- risk-tiered review
basics
~20 sEvery small change to a widely-used shared folder needs sign-off from a small owning team, so that team becomes a bottleneck. Fix it by splitting ownership into smaller pieces, or letting a wider team share the review load instead of one narrow gate covering everything.
solid answer
~40 sA coarse CODEOWNERS entry over a heavily-shared path creates a queueing bottleneck: every PR from 30 consuming teams funnels approval through a handful of reviewers, whose latency becomes the org's velocity ceiling while they context-switch constantly on low-risk changes. Two structural fixes: (1) decompose the shared package into smaller, independently owned subpackages so each subfolder gets its own narrower CODEOWNERS entry, shrinking blast radius per change; (2) risk-tier the gate — use CODEOWNERS precedence to let contributing teams freely change low-risk subpaths (tests, docs) while reserving the central team's review for the stable public API surface only. A supporting fix is pointing CODEOWNERS at a team, not named individuals, so review load is spread rather than concentrated.
go deeper
Aware that widely-shared code often needs review from its maintainers, and that this can be slow.
Can propose subpath decomposition or team-based ownership as concrete fixes when the bottleneck is described.
Designs risk-tiered review policies — narrow gate on public API vs. open contribution elsewhere — and predicts a bottleneck before it happens when reviewing a repo's ownership map.
Sets org-wide policy for how shared/platform packages balance central control against team autonomy, including tooling like bots and SLAs so the gate doesn't become a political flashpoint.
## The queueing problem When a monorepo has one coarse-grained ownership entry over a heavily depended-on package — say `/libs/common-utils/ @platform-team` — every PR from every one of the dozens of consuming teams that touches that path funnels its required approval through the same small group of reviewers. This is a classic **queueing problem**: the arrival rate of review requests scales with the number of teams actively changing shared code, which grows as the org grows, while the service rate — how fast the owning team can meaningfully review — is bounded by roughly fixed headcount and competes with the owning team's own feature work. The result is: - rising **queue time**; - constant **context-switching** for reviewers (each PR touches unfamiliar code written by a different team); - pressure — explicit or cultural — to approve quickly without deep scrutiny, which erodes the review quality the gate exists to protect. ## Why the gate exists at all It's worth separating this from the reason the gate exists at all: shared, widely-depended-on code has a large **blast radius**. A subtle bug or breaking change in a utility used by 30 teams doesn't just affect one team's release, it potentially breaks 30 teams' builds simultaneously, so removing the review requirement entirely trades a velocity problem for a much larger reliability problem the first time something breaks. The fix has to preserve accountable review of the code that matters while removing unnecessary funneling of everything else through the same narrow channel. ## The first structural fix — decomposition The first structural fix is **decomposition by subpath or package**. If `common-utils` splits into, say: - `common-utils/date` - `common-utils/http` - `common-utils/validation` — each with its own owner(s) — a change to date-formatting code no longer requires sign-off from someone who only knows the validation logic, and the queue for any single reviewer group shrinks proportionally. This mirrors how large projects with a CODEOWNERS-like model (e.g. the Linux kernel's MAINTAINERS file) assign narrower ownership as a subsystem grows, rather than leaving one group as the bottleneck for an ever-expanding area. ## The second fix — risk-tiering the gate The second fix is **risk-tiering the gate itself**: distinguish the package's stable public surface — the functions/types other teams actually import — from everything else (internal helpers, tests, documentation, examples). CODEOWNERS pattern precedence supports this directly: a general rule like `/libs/common-utils/ @platform-team` can be overridden by a more specific, later pattern such as `/libs/common-utils/README.md` or a test-file glob with looser or no ownership restriction, so low-risk changes bypass the bottleneck while the actual API surface stays gated. ## The third lever — a wider, load-balanced owner A third, complementary lever is making the owner itself wider and load-balanced: pointing CODEOWNERS at a team handle rather than named individuals lets the platform round-robin or randomly assign the actual reviewer from a larger pool, and some organizations explicitly rotate an 'on-call reviewer' role for high-traffic shared packages so review load doesn't concentrate on whoever's most senior or most available. ## The failure mode to recognize The failure mode to recognize when none of this is done: - merge-time metrics (median time-to-first-review, PR queue depth) for the shared path visibly diverge from the repo average; - the owning team reports review fatigue; - the clearest signal — the owning team starts approving PRs without meaningfully reading them just to clear the backlog, which defeats the entire purpose of the gate while still paying its full latency cost. At that point the organization is getting the worst of both worlds: slow and low-quality review, which is exactly the outcome risk-tiering and decomposition are meant to prevent.
- Why not just remove the review requirement for common-utils to unblock teams?Because it's shared infra — an unreviewed breaking change there fans out to 30 consumers simultaneously. The fix is narrowing or distributing the gate, not deleting it, since the underlying blast-radius risk hasn't gone away.
- How does splitting a shared package into subpackages change the ownership model?Each subpackage gets its own CODEOWNERS scope and can have a different owning group, so a change to one utility no longer requires approval from people unrelated to it. It also lets teams take on partial ownership of pieces they use heavily.
- What's a lightweight way to reduce reviewer load without any restructuring?Point CODEOWNERS at a team rather than named individuals so the platform load-balances requests or lets any team member approve. It doesn't fix the underlying volume problem but avoids single-person bottlenecks.
Like routing every building's maintenance request through one central superintendent instead of giving each floor's residents their own super for routine fixes and reserving the central super for structural work.
saying these in an interview costs you the question
- Suggests simply removing the review gate as the only fix
- Doesn't recognize that reviewer bottleneck scales with number of consumers, not size of the owning team
- Proposes adding more required approvers, which increases friction rather than fixing the root cause
- Doesn't distinguish public API surface changes from low-risk internal or test-only changes