2026-11-04 · ~20 min read · Decision records

The engineering code review velocity decision record: why the velocity model you chose determines your deployment frequency ceiling and your reviewer bottleneck surface

Engineering code review velocity decisions are not decisions about which code review tool to use or how many approvals to require. They are a set of founding decisions about how the organization structures the feedback loop between the engineer who writes code and the team that ships it — how review latency is bounded so that the review process does not become the deployment frequency ceiling, how reviewer load is distributed so that review expertise does not concentrate in a bottleneck that every change must pass through, how PR size norms create reviewable units rather than batch-review artifacts that pass inspection without being read, and how approval gate architecture is calibrated to change risk rather than applied uniformly to changes that differ by two orders of magnitude in complexity and consequence. The consequences are invisible when the team is small enough that two or three engineers know every piece of the codebase and synchronous review happens naturally in the course of daily work; they become visible when a production patch waits three days to merge because the two engineers with context are each waiting for the other to review, when two senior engineers approve an 847-line PR in four minutes each because the two-reviewer rule has trained the team to write large PRs and trained reviewers to process them quickly, and when a 6-line config change waits fourteen hours for a component owner in a different timezone while a customer escalation remains open.

A 14-person developer tools startup had been running code review through a combination of GitHub PR notifications and a Slack channel called #pr-reviews since its founding. The model was simple: when an engineer opened a PR, they would paste the link in #pr-reviews with a brief description of the change. Interested engineers would pick up reviews based on their knowledge of the area and their current availability. The CTO considered this model a natural evolution of the team's collaborative culture — reviews happened organically, without ceremony, and the engineers who cared most about a given area of the codebase naturally ended up reviewing changes to it. At 14 people, it worked. The team was small enough that the engineers in #pr-reviews had sufficient context to review most changes quickly, Slack notifications were noticed within the hour, and the informal routing produced reasonable review coverage without any coordination overhead.

As the team grew from 14 to 22 over the following eight months, the model's assumptions began to degrade silently. The #pr-reviews channel received more posts per day than any engineer could track. Engineers developed personal filtering heuristics — reviewing PRs from engineers they worked closely with, reviewing PRs in the services they owned, skipping PRs in areas outside their current focus. The filtering was individually rational and collectively produced a review model where PRs in lower-traffic areas of the codebase accumulated without reviewers while PRs from senior engineers received reviews within two hours. The CTO was not aware of the queue distribution because no one was measuring time-to-first-review by area, by author, or by change size. The metric the team tracked was sprint velocity — story points shipped per sprint — which was healthy and growing. Code review latency was invisible in that metric.

In month nine, the team's payment processing service developed a subtle bug in its subscription renewal path: a race condition between the renewal job and the user's account suspension check was producing a small percentage of erroneous double-charges for accounts that had suspended and reactivated within the same billing window. The bug was detected in a customer support ticket. The engineer who identified it diagnosed the root cause in forty minutes and had a fix ready — eleven lines changing the transaction isolation level and the order of two checks — within ninety minutes of the ticket arriving. She opened the PR at 2:17pm on a Tuesday and posted it in #pr-reviews with the note "hotfix for double-charge race condition, urgent." By 5pm, three engineers had commented reactions in Slack. No one had opened the PR. The two engineers who had the deepest context on the payment service — one was the original author of the renewal path, one had reviewed the most recent architectural change to it — were each working heads-down on their own sprint deliverables. Each assumed the other had seen the #pr-reviews post and would pick it up. At 9pm, the engineer who had written the fix checked GitHub. The PR had one review request opened by the auto-assign rule she had manually triggered, assigned to an engineer who had been in back-to-back meetings since 3pm and had not seen the notification.

The PR was reviewed the following morning at 8:43am — seventeen hours after it was opened. The reviewer requested two minor clarifications. The engineer responded by 9:15am. The reviewer approved at 11:30am. Merge happened at 11:47am — seventy-one hours and thirty minutes after the original fix was written. During that window, the double-charge issue continued to affect customers at a rate of approximately three affected accounts per hour. The customer support queue grew to sixty-three tickets by the time the fix deployed. The post-incident retrospective identified the root cause as "communication gap in the PR review process" — the fix had been labeled urgent in Slack and the two engineers with payment-service context had not seen the urgency signal in time. The recommended action was to add a #hotfix-reviews Slack channel for urgent fixes. The retrospective did not identify the structural cause: the review model had no assignment mechanism, no latency measurement, and no SLA that would have made a 71-hour urgent-fix review window visible as a process failure before the customer impact accumulated.

A 38-person B2B SaaS had instituted a mandatory two-reviewer approval requirement for all production PRs eight months earlier, following a production incident in which a single-reviewer approval had passed a bug in the company's billing calculation logic. The bug had produced incorrect invoice totals for a subset of customers over six weeks before it was detected in a customer audit. The VP of Engineering concluded that a single reviewer was insufficient protection for production-bound changes and that a two-reviewer requirement would ensure that any change reaching production had been evaluated by two independent sets of eyes. The two-reviewer rule was implemented as a branch protection requirement: no PR could merge to main without two approvals from team members.

The team at the time of the two-reviewer rule's introduction had six senior engineers who collectively owned the most critical areas of the codebase: the billing engine, the authentication service, the customer data pipeline, the API gateway, and the notification system. The thirty-two remaining engineers ranged from mid-level to junior, with varying degrees of familiarity with the codebase's most consequential areas. The two-reviewer rule did not specify that both reviewers needed to have context on the changed area; it required any two team members to approve. In practice, the team's culture of review quality meant that engineers self-selected reviews in areas where they had context, and junior engineers declined to review areas outside their familiarity. The result was that the six senior engineers absorbed a review load proportional not to their seniority but to the breadth of their codebase knowledge — the engineer who had written the billing engine received review requests on roughly 40% of all PRs touching any financial logic, because she was the person most capable of evaluating them and the team knew it.

The load concentration produced a secondary adaptation: engineers began writing larger PRs to batch the review cost. Under the two-reviewer rule, each PR open required two of the six senior engineers to context-switch to a review. If the engineer could batch three days of related work into a single PR instead of opening three separate PRs, the total review cost was two senior-engineer context-switches rather than six. The batching was rational from the engineer's perspective and destructive from the reviewer's. By month four of the two-reviewer rule, the team's median PR had grown from 180 lines to 640 lines. By month seven it was 940 lines. The two senior engineers reviewing a 940-line PR faced a choice that the branch protection rule did not acknowledge: spend ninety minutes doing a thorough review of a change that touched seven files across four service boundaries, or spend five minutes doing a structural review that could answer "does this look like it was written by someone who understood the system?" but could not answer "does this change have any interaction effects between the billing path in file 3 and the idempotency check in file 6 that would produce incorrect behavior under concurrent requests?"

In month eight, a mid-level engineer submitted a PR implementing a new discount code redemption flow. The PR was 847 lines across nine files. It touched the billing engine, the customer data model, the API gateway's rate limiting logic, and the front-end checkout form validation. Both required reviewers approved within four minutes each. One reviewer was processing a backlog of eleven pending review requests in a focused two-hour slot and was working through the queue at the pace required to clear it by the end of the sprint. The other reviewer had a 1pm customer call in fifteen minutes. Neither reviewer identified a parameter in the discount validation function that accepted customer-supplied input without sanitization, passed it to a SQL query in the billing engine via string interpolation, and represented a SQL injection vulnerability in the checkout path. The vulnerability was discovered three weeks later by a security researcher during a routine penetration test. The fix was straightforward — a parameterized query in one file, three lines. The incident retrospective concluded that the two-reviewer rule had not provided sufficient protection because the reviewers had not had time to review the PR thoroughly. The recommended action was to add a mandatory security review checklist to the PR template. The retrospective did not identify the structural cause: the two-reviewer rule had trained the team to write large PRs and had trained senior engineers to process large PRs quickly, and the approval gate was functioning as a throughput mechanism rather than a quality gate for exactly the changes where quality review mattered most.

A 71-person enterprise SaaS with eight product teams had built a mature code review process over three years: mandatory PR templates with sections for description, testing evidence, rollback plan, and reviewer guidance; automated lint, type-checking, and test gates that blocked merge on failure; a component ownership model defined in a CODEOWNERS file where eight engineers each owned two to four critical components and were automatically added as required reviewers for any PR touching their components; and a 24-hour first-response SLA for all review requests that the VP of Engineering reviewed monthly in the team's engineering metrics dashboard. The model had been designed deliberately — the VP of Engineering had benchmarked review processes at four comparable companies and had selected a configuration that balanced thoroughness with throughput. The 24-hour SLA had been calibrated against the team's then-current weekly release cadence, where a 24-hour review window fit comfortably within the weekly cycle.

When the company's product strategy shifted to treating deployment speed as a competitive differentiator — the goal was to move from weekly releases to on-demand deployments, with a target of same-day deployment for customer-requested fixes — the 24-hour SLA became the deployment frequency ceiling for every change that touched a component with an owner. Of the team's eight owned components, seven were touched by the majority of meaningful changes: the authentication service, the authorization rules engine, the customer data model, the payment processing pipeline, the notification system, the API gateway, and the data export service. A change that touched any one of these components required the component owner's first-response within 24 hours before the review could proceed. For the new on-demand deployment goal, 24 hours was not an SLA — it was a floor. The minimum time from PR open to merge for any component-touching change was at least 24 hours, regardless of change size, change risk, or business urgency.

The component ownership model's bottleneck was most visible in a specific incident pattern. A customer success engineer supporting the company's largest enterprise account — a $340k ARR contract — opened a support ticket on a Monday morning reporting that the account's API rate limits were being hit on routine export operations. The root cause was identified by 11am: the rate limiting parameters for the account's API key tier had been set to a value that was correct at the time of configuration but had not been updated when the account upgraded its subscription tier six weeks earlier. The fix was straightforward — a configuration update in the authentication service's rate limiting table, implemented as a database migration with six changed lines. The engineer who made the change opened a PR at 11:47am. The CODEOWNERS file assigned the authentication service component owner as a required reviewer. The component owner was a senior engineer based in Singapore; it was 11:47am Berlin time, which was 6:47pm Singapore time. The Singapore engineer was at the end of his workday and had already begun his evening context-switch. He saw the GitHub notification at 7:30pm, opened the PR, saw six changed lines in a configuration migration, and scheduled his review for the following morning when he would have full cognitive context for evaluating authentication service changes. His morning review completed at 9:15am Singapore time — 2:15am Berlin time. The Berlin engineer merged the fix at 9:02am Berlin time — 21 hours after the PR was opened.

During that 21-hour window, the customer's API calls continued to fail. The customer success team sent four escalation emails. The VP of Sales joined the customer's Slack workspace to explain that a fix was in progress. The account team offered a service credit. The post-incident retrospective identified the root cause as "timezone mismatch between the change author and the required reviewer." The recommended action was to add a secondary reviewer for each component owner's timezone so that required reviews could be covered across working hours. The retrospective did not identify the structural cause: the component ownership model required the same approval for a 6-line configuration migration and a 400-line refactor of the authentication service's session management logic, because the CODEOWNERS file treated the entire authentication service as a uniform ownership unit without distinguishing between the changes that required the component owner's architectural judgment and the changes that required only standard code review competence. The model had been designed to protect critical components from unauthorized changes. It had no mechanism for distinguishing between a configuration update that any senior engineer could evaluate in three minutes and an architectural change that required the component owner's specific expertise to evaluate safely.

Structural properties set by the engineering code review velocity decision

Two structural properties are determined by the founding decisions about review latency, approval gates, reviewer assignment, PR size norms, and component ownership. Both are invisible when the team is small enough that every engineer knows every part of the codebase and review happens as a natural part of daily work; both become visible when the codebase grows beyond any single engineer's full context, when the review queue grows deeper than any single engineer's attention can track, and when the first on-call incident reveals that the fix that takes forty-five minutes to write takes seventy-one hours to merge.

Property 1: Deployment frequency ceiling. The deployment frequency ceiling is the maximum rate at which the team can ship changes to production, bounded at the review layer by three factors. First, review latency model: the time between a PR being opened and the first meaningful review. The first failure story illustrates the assignment absence failure mode: a review model where engineers self-assign reviews based on Slack channel attention and personal availability produces a review latency that is a function of reviewer attention and social dynamics rather than a function of the team's review capacity. The 71-hour review window for the payment service hotfix was not a function of the team's capacity to review — the team had twenty-two engineers at the time, and any senior engineer among them could have reviewed the eleven-line fix in fifteen minutes — it was a function of the review model's absence of an assignment mechanism that bound the first-response latency to a named engineer and a named SLA. Connect this to the engineering deployment frequency decision record: the deployment frequency model and the review latency model are coupled at the merge gate — a deployment model that targets same-day deployment for customer-facing fixes requires a review model whose first-response SLA is measured in hours rather than days, because the review process is the merge gate that every change must pass through before the deployment model's pipeline can begin. Second, approval gate model: whether approval requirements are uniform across all change types or tiered by change risk. The second failure story illustrates the uniform gate failure mode: a two-reviewer requirement that applies identically to a 15-line bug fix and an 847-line multi-service change produces a review model where the same review investment is expected for changes that differ by two orders of magnitude in the complexity of their failure modes. The uniform gate is calibrated to the team's lowest-risk changes — reviewers learn to process the gate at the pace required to clear the queue — and applies that calibration to the high-risk changes where the gate exists. Connect this to the engineering sprint planning decision record: the sprint planning model and the review model are coupled at the work-in-progress layer — a sprint planning model that commits to specific deliverables within a sprint requires a review model whose throughput is sufficient to clear the sprint's review queue before the sprint close, and a review model whose throughput is constrained by a uniform approval gate that concentrates load on senior engineers is a sprint planning model whose committed sprint capacity is implicitly a function of senior-engineer review availability. Third, reviewer assignment model: whether review requests are distributed or concentrated. The first failure story illustrates the assignment gap failure mode; the second illustrates the concentration failure mode. Both produce the same outcome — a review queue that cannot be cleared at the rate the team generates changes — from different structural causes. Connect this to the engineering metrics decision record: review latency by risk tier, reviewer load distribution (Lorenz curve), and PR size distribution are the three metrics that reveal whether the review model is functioning as a throughput mechanism or as a bottleneck, and none of them are produced by the standard sprint process or the standard deployment pipeline — they require a measurement model that treats the review process itself as a system with observable behavior.

Property 2: Reviewer bottleneck surface. The reviewer bottleneck surface is the fraction of change throughput constrained by the availability of a small subset of reviewers, determined by three factors. First, review load concentration: whether review load is distributed across a wide reviewer pool or concentrated on the engineers with the most domain context. The second failure story illustrates the expertise-concentration failure mode: a review model that routes all changes in a domain to the engineer with the most domain expertise produces a model where domain expertise and reviewer bottleneck are the same constraint. The concentration is rational — the expert reviewer is the best-qualified reviewer — and self-reinforcing: the expert reviewer's reviews are the most thorough and the most valuable, which increases the demand for expert review relative to non-expert review, which increases the concentration. The bottleneck surface from expertise concentration is widened by the secondary adaptation it produces: when high-load reviewers become scarce, engineers learn to batch their changes into larger PRs to minimize the number of review requests, which produces larger PRs that are harder to review thoroughly, which increases the per-PR review cost, which widens the bottleneck further. Connect this to the engineering technical strategy decision record: a technical strategy that specifies a team's deployment frequency target requires a review model that can process changes at that frequency, and a review model whose throughput is constrained by the availability of a small set of expert reviewers is a deployment frequency target that is achievable when the expert reviewers are available and unachievable when they are not — a deployment frequency that is a function of reviewer availability rather than team capacity. Second, PR size norms: whether the team's PR size conventions create reviewable units. The second failure story illustrates the size norm erosion failure mode: a uniform approval gate produces PR size inflation because engineers batch changes to minimize the total review cost — a rational individual adaptation that makes review quality impossible at the aggregate level. The size norm erosion failure mode is particularly difficult to detect because it is invisible in the metrics the team typically measures: story points per sprint, deployment frequency, and incident rate do not reveal that the team's PRs have grown from 180 lines to 940 lines and that the approval gate is functioning as a throughput mechanism rather than a quality gate for exactly the changes where quality matters most. Connect this to the engineering documentation standards decision record: a PR that is too large to review thoroughly is the code review equivalent of a documentation artifact that is too long to read — the artifact exists, satisfies the formal requirement (approved by two reviewers / written as a document), and fails to produce the value the requirement was designed to create. Third, component ownership model: whether the approval requirements for owned components distinguish between changes that require the owner's expertise and changes that require only standard review competence. The third failure story illustrates the uniform ownership gate failure mode: a CODEOWNERS file that assigns the component owner as a required reviewer for all changes to the component creates a model where the component owner's availability is the deployment frequency ceiling for all changes in that component's scope — a constraint whose cost is proportional to the gap between the owner's review latency and the team's target deployment frequency, and whose cost is highest when the team needs fastest deployment: during customer escalations, production incidents, and time-sensitive compliance deadlines. Connect this to the engineering metrics decision record: component-owner review latency — the time-to-first-review distribution for PRs with component owner required reviewers, broken out by component and by change risk tier — is the metric that reveals whether the component ownership model is producing the architectural protection it was designed to provide or is functioning primarily as a deployment latency constraint, and the distinction between the two determines whether the fix is to the component ownership model's approval gate calibration or to the owner's availability model.

The engineering code review velocity ADR: five sections

Section 1: Review latency model and SLA calibration. The review latency model defines the time bound from PR open to first meaningful review response, how the SLA is calibrated to change risk, and how the SLA is enforced and measured. Three components. SLA calibration by risk tier: the team defines two or three risk tiers based on the properties that determine how much review investment a change requires. A tier-1 change is small scope (under 300 lines of changed logic, excluding generated files and lock file changes), touches no component with a designated owner, and has test coverage for its primary code path. A tier-3 change is large scope (over 500 lines of changed logic), or touches a component designated as requiring specialized review, or modifies behavior in a path with low test coverage. Tier-2 is everything between. The SLA for tier-1 changes is two hours from PR open to first meaningful review comment or approval; for tier-2 changes it is eight hours; for tier-3 changes it is twenty-four hours with a mandatory second reviewer. The SLA calibration is not about how fast reviewers should work — it is about the maximum review latency that is consistent with the team's deployment frequency target for each risk tier. A team targeting same-day deployment for tier-1 changes needs a two-hour SLA; a team targeting weekly deployment can tolerate a twenty-four-hour SLA across all tiers. Assignment mechanism: at PR open time, an assignment algorithm selects a primary reviewer from the team's available reviewer pool, weighted by context proximity (time-since-last-commit to the changed files), current review queue depth (number of pending review requests), and reviewer rotation (time-since-last-assignment, to prevent load concentration on a small subset). The primary reviewer receives a direct notification — not a channel post — with the PR link, the risk tier, and the SLA. If the primary reviewer has not responded within 50% of the SLA window, a secondary reviewer is assigned from the same pool. The assignment mechanism eliminates the first failure story's root cause: the review is not waiting for someone to notice a Slack post, it is assigned to a named engineer with a named deadline. SLA measurement and calibration: the team measures time-to-first-review for all PRs, broken out by risk tier, for the trailing thirty days. The measurement is surfaced in the team's engineering metrics dashboard alongside deployment frequency. If the median time-to-first-review for any tier exceeds the SLA by more than 20%, the VP of Engineering reviews the assignment algorithm's queue depth distribution — a systematic SLA miss indicates either that the reviewer pool is too small for the current review volume or that the assignment algorithm is concentrating load on a subset of reviewers. The SLA calibration is reviewed quarterly and adjusted to reflect changes in the team's deployment frequency target, the codebase's complexity distribution, or the team's reviewer pool size.

Section 2: PR size norms and reviewability criteria. The PR size norm defines what constitutes a reviewable unit, how the norm is enforced, and what the explicit exceptions are. Three components. Reviewable unit definition: a PR constitutes a reviewable unit when a reviewer who is familiar with the codebase but not the specific change can hold the full change in working memory — read the description, read the diff, and answer "does this change do what it says it does and does it do anything else?" — without needing to load additional context mid-review. For most codebases and most changes, this requires that the changed logic be under 300 lines, that the change's purpose is stated in the PR description in one or two sentences, and that the changed files collectively tell a coherent story — an engineer who reads the diff can reconstruct why each file was changed from the PR description without needing to look at a separate design document or a prior PR. The reviewable unit definition is a quality property, not a line count rule; the line count is a heuristic for the quality property. A 50-line change that modifies the same function call in forty-seven files is a reviewable unit; a 300-line change that touches three different subsystems with independent failure modes may not be. Norm enforcement at creation time: when a PR is opened, an automated check evaluates the changed line count against the team's tier boundaries and the number of distinct service boundaries crossed. If the check indicates the PR exceeds the reviewable unit threshold without meeting an explicit exception criterion, it posts a comment on the PR with a description of the threshold, the specific size metric that exceeded it, and a suggestion for how to split the change — not as a block, but as a prompt. The comment is designed to arrive before the reviewer begins reading, so that the engineer can decide to split before a reviewer invests time in a change that will be re-opened. Exception criteria: large-scope automated refactors (codemod-generated renames, automated API migration scripts, generated client updates), dependency upgrades, and lock file changes are excluded from the size norm because the review model for these changes is different — the reviewer is evaluating the tool, the configuration, and the test evidence rather than the diff. These exceptions are defined explicitly in the PR template so that engineers know they exist and can invoke them without ambiguity. A change that invokes an exception criterion is marked as exempt in the automated check and receives a reviewer note in the assignment that explains the exception, so that the reviewer calibrates their review investment appropriately.

Section 3: Reviewer assignment and load distribution model. The reviewer assignment model defines how review requests are routed, how load is distributed, and how the model prevents the expertise-concentration failure mode. Three components. Assignment algorithm: review requests are assigned at PR open time by an algorithm that considers three factors. Context proximity: for each reviewer in the pool, the algorithm calculates the number of commits the reviewer has made to the changed files in the trailing ninety days. Reviewers with more recent commits to the changed area receive a higher weight. Queue depth: each reviewer's current pending review request count is factored inversely — a reviewer with five pending requests receives a lower weight than a reviewer with one. Rotation weight: each reviewer's time-since-last-assignment is factored positively, with a cap that prevents any reviewer from accumulating more than 30% of the team's total review assignments in a rolling thirty-day window. The algorithm combines the three factors into a weighted assignment score and assigns the PR to the highest-scoring available reviewer. The algorithm's output is a single named primary reviewer, not a pool of potential reviewers — the assignment is a named obligation, not an invitation. Reviewer pool management: the reviewer pool is defined as all engineers above junior level who have been onboarded to the codebase areas they may be assigned to review. Pool membership is expanded as engineers develop context in new areas — each engineer's context profile is updated monthly based on their recent commit history, and their review assignment weight for each codebase area reflects their current context rather than their historical title or seniority. The pool management model is the structural fix for the expertise-concentration failure mode: by expanding the reviewer pool to include all engineers with sufficient context rather than only the engineers with the most context, the assignment algorithm distributes load across a wider set of reviewers and reduces the concentration on the small subset who would otherwise absorb a disproportionate share of the queue. Load distribution monitoring: the team measures the Lorenz curve of review assignments — the cumulative fraction of assignments absorbed by the ranked reviewer pool — monthly. If the top 20% of reviewers absorb more than 50% of all assignments, the VP of Engineering reviews the assignment algorithm's context proximity weights and the reviewer pool membership. A load concentration above 50% in the top-20% bracket indicates that the pool is functionally narrow — either because the context proximity weights are over-indexed on a small set of senior engineers, or because pool membership criteria are excluding engineers with sufficient context, or both.

Section 4: Approval gate architecture and risk-tiered ownership model. The approval gate architecture defines the approval requirements by risk tier and the component ownership model that distinguishes between changes requiring owner expertise and changes requiring standard review competence. Three components. Risk-tiered approval requirements: tier-1 changes require one approval from any engineer in the reviewer pool. Tier-2 changes require one approval from an engineer with context proximity weight above a threshold for the changed area — a reviewer who has committed to the changed files in the trailing ninety days. Tier-3 changes require two approvals: one from a context-proximate reviewer and one from a senior engineer designated as a secondary reviewer for the changed area. The tier-3 secondary reviewer is not a component owner; they are a senior engineer whose context is sufficient to evaluate the structural correctness of the change, independent of the primary reviewer. The risk-tiered approval requirement replaces the second failure story's uniform two-reviewer rule with a structure where the approval requirement scales with the change's risk profile rather than applying a constant investment across changes that differ by two orders of magnitude in complexity. Component ownership model calibration: the CODEOWNERS file is modified to distinguish between two categories of component ownership. Architectural ownership: changes that modify the component's public interface, its error handling behavior, its resource consumption model, or its security boundary require the component owner's approval in addition to the standard risk-tier requirement. Configuration and operational ownership: changes that modify the component's configuration, its operational parameters, or its non-interface behavior are routed to the standard risk-tier review process without requiring the component owner's explicit approval. The component owner is added as an informational reviewer for all changes to the component and can flag concerns at any time, but their approval is not required and their absence does not block merge for non-architectural changes. The third failure story's 6-line rate limiting configuration change would be classified as a configuration and operational change, assigned to a tier-1 reviewer with a two-hour SLA, and merged without requiring the Singapore component owner's approval — not because the component owner's context is not valuable, but because the value of the component owner's specific expertise is calibrated to the architectural changes where their expertise is necessary, not applied uniformly to changes that any senior engineer can evaluate in three minutes. Delegation model: each component owner designates two engineers with sufficient context to cover the architectural ownership approval when the owner is unavailable — on vacation, in a meeting-heavy sprint, or in a timezone that creates a systematic response-time gap. The delegation list is maintained in the CODEOWNERS file alongside the primary owner designation. If the primary owner has not responded to an architectural ownership review request within 50% of the tier SLA, the assignment algorithm notifies the first delegate.

Section 5: Review health measurement and improvement cadence. The review health measurement model defines which metrics reveal whether the review model is functioning as a throughput mechanism or as a bottleneck, and the improvement cadence that connects measurement to review model evolution. Three components. Health metric set: the code review health metrics that reveal review model function are distinct from the velocity metrics that reveal team throughput. Throughput metrics — story points shipped per sprint, deployment frequency, feature cycle time — measure the team's output rate. Review health metrics measure whether the review model's design properties are functioning as designed: time-to-first-review by risk tier (median, p75, p95 for the trailing thirty days, broken out by tier — the tier-1 median should be under two hours; a tier-1 p95 above eight hours indicates systematic assignment or availability failure); reviewer load concentration (Lorenz curve updated monthly — top-20% share above 50% indicates pool narrowing); PR size distribution (median, p75, p95 of changed lines per PR by tier — a tier-1 median above 300 lines indicates size norm erosion); component-owner review latency (time-to-first-review for PRs with component owner required reviewers, broken out by component and by change category — architectural versus operational — a systematic gap between architectural and operational review latency that exceeds the tier SLA indicates that the ownership model is not distinguishing between categories correctly); and approval gate effectiveness (fraction of PRs that received at least one substantive review comment — a request for change, a question, or an inline suggestion — per approval, as a proxy for review quality; a tier-3 PR that receives zero substantive review comments on both approvals indicates that both reviewers processed the PR heuristically rather than evaluating it at the depth the tier-3 tier is designed to require). Measurement cadence: the throughput metrics are reviewed weekly at the team standup. The review health metrics are reviewed monthly by the VP of Engineering, using the trailing thirty days of data, with a quarterly retrospective that connects review health trends to deployment frequency trends. The connection between review health and deployment frequency is the key insight that makes the review model's measurement cadence valuable: a deployment frequency below target is usually attributed to pipeline issues, feature complexity, or sprint planning, and rarely attributed to review latency — but review latency is frequently the deployment frequency ceiling for the median change, and the monthly review health check is the mechanism that makes the connection visible before the deployment frequency miss arrives in the quarterly engineering review. Connect this to the engineering deployment frequency decision record: the deployment frequency model's measurement set should include review latency by risk tier as a leading indicator — a team that tracks deployment frequency without tracking review latency is a team that can observe the ceiling but not the constraint that sets it. Improvement protocol: when a health metric falls below its threshold — tier-1 median time-to-first-review above two hours, top-20% reviewer share above 50%, tier-1 median PR size above 300 lines, component-owner review latency for operational changes above tier SLA, tier-3 approval gate effectiveness below 60% — the monthly review produces a named root cause analysis and a named review model adjustment. The adjustment is to the review model's design — the assignment algorithm's weighting parameters, the reviewer pool membership criteria, the size norm enforcement threshold, the CODEOWNERS classification boundaries, the approval gate tier definitions — rather than to individual reviewer behavior, because review model health metric failures are structural rather than behavioral: they indicate that a design property is not functioning as intended rather than that individual reviewers are performing below expectation. Connect this to the engineering sprint planning decision record: the sprint planning model and the review model share the same structural failure mode — both can produce metrics that appear healthy (sprint completion rate / review approval rate) while degrading the properties those metrics are supposed to measure (delivery predictability / review quality), and both require a measurement model that tracks the design properties directly rather than trusting that the output metrics reflect them.

FAQ

How do you set a code review SLA that improves deployment frequency without sacrificing review thoroughness?

The core insight is that review SLA and review thoroughness are not in tension if the SLA is calibrated to change risk rather than applied uniformly. A four-hour first-response SLA on a 2-line config change requires four hours of reviewer attention for a change that takes two minutes to evaluate. A four-hour first-response SLA on a 400-line architectural refactor requires four hours of attention for a change that requires forty-five minutes of genuine review to evaluate at the level where the most consequential bugs hide. The SLA calibration problem is not "how fast should reviews be?" but "what is the right review investment per unit of change risk, and what is the latency target that keeps the review process from becoming the deployment frequency ceiling for each risk tier?" Three components determine whether a review SLA improves deployment frequency without sacrificing thoroughness. First, risk tier definition: define two or three risk tiers based on the properties that determine review investment — change scope (number of lines of changed logic), component criticality (whether the change touches components whose failure modes have disproportionate customer impact), and test coverage (whether the change adds tests that cover its failure modes). A tier-1 change is small scope, low criticality, and covered by tests; a tier-3 change is large scope, high criticality, or modifying a path with low test coverage. Second, SLA calibration by tier: tier-1 changes have a two-hour first-response SLA; tier-3 changes have a twenty-four-hour first-response SLA with a mandatory second reviewer. The tier-1 SLA is aggressive enough to keep small changes flowing through the review process without accumulating in queues; the tier-3 SLA is relaxed enough that the reviewer has time to do the review properly. Third, measurement and calibration: measure the actual time-to-first-review distribution by tier for the trailing thirty days, and adjust the SLAs where the distribution shows systematic underperformance — if tier-1 SLA is two hours and the p75 time-to-first-review is six hours, the SLA is not being met and the gap is a signal about reviewer availability, queue depth, or assignment model that requires a structural investigation rather than a reminder to reviewers about their SLA obligations.

What is the right PR size and how do you create a norm without creating overhead?

The right PR size is the largest change that a reviewer can hold in working memory and reason about all interaction effects without needing to context-switch out of the review to load additional context. For most codebases and most reviewers, this is approximately 200–400 lines of changed code, excluding generated files, test fixtures, and lock file changes. The right PR size is not a universal constant — a 400-line refactor that moves functions between files requires less review investment per line than a 50-line change to a cryptographic primitive — but the 200–400 line range is the right starting point because it is the range where reviewers consistently report being able to evaluate the full change rather than the structural outline of the change. Creating a norm without creating overhead requires three things. First, the norm is defined in terms of reviewable units rather than arbitrary line counts: a PR should contain one coherent change that a reviewer can evaluate as a whole. A coherent change is one where the reviewer, after reading the PR description and the diff, can answer "does this change do what it says it does and does it do anything else?" — if the reviewer needs to read three separate context threads to answer that question, the PR is not a reviewable unit. Second, the norm is enforced at the PR creation layer, not at the review layer: a PR that exceeds the size threshold triggers an automated comment at open time, before the reviewer begins reading, so that the engineer can decide to split before a reviewer invests time in a change that will be re-opened as two smaller PRs. Third, the norm has explicit exceptions for cases where splitting genuinely adds more cost than value: large-scale automated refactors, dependency upgrades, and generated file updates are cases where the size norm should not apply because the review model is different — the reviewer is evaluating the tool that generated the change, not the change itself — and these exceptions should be defined explicitly so that engineers can invoke them without ambiguity rather than treating the size norm as a bureaucratic hurdle to route around.

How do you prevent component ownership from becoming a deployment bottleneck?

The component ownership bottleneck is caused by a mismatch between the ownership model's assumption — all changes to a component require the owner's judgment — and the reality that most changes to a component are low-risk modifications that do not require the owner's specific expertise to evaluate. The fix is not to remove component ownership but to separate the ownership model from the approval model: the component owner owns the component's architectural evolution and is the final authority on changes that modify the component's interface or its failure-mode behavior — but is not required to approve every PR that touches the component. Three models produce different results. First, risk-tiered ownership approval: the component owner's approval is required only for changes that modify the component's public interface, its error handling behavior, or its resource consumption model. Changes within the component that do not touch these properties go through the standard review process without requiring the owner's approval. The component owner defines and maintains the tier boundary, which is the expertise that justifies the ownership role. Second, ownership delegation: the component owner designates two or three engineers with sufficient context to share the first-response review obligation for component-touching PRs, so that the component owner's availability is not the first-response SLA for every change to the component. Third, escalation path rather than approval gate: component owners are listed as informational reviewers for all changes to their components, can flag concerns at any time, but are not required approvers unless the change tier triggers the architectural ownership requirement. The escalation path model is the most flexible approach; the risk-tiered ownership approval model is the most common starting point for teams transitioning from a full-ownership approval gate, because it preserves the owner's architectural authority while removing the owner's availability constraint from operational changes that do not require their expertise.

How do code review velocity decisions connect to AI chat sessions and decision preservation?

Code review velocity decisions are made in AI chat sessions when engineering leaders work through the review latency model — what the first-response SLA should be, whether it should be uniform or risk-tiered, and how the SLA is enforced and measured — the approval gate architecture — whether two reviewers are required for all changes or only for high-risk changes, what constitutes high-risk, and how the risk tier is determined at PR creation time rather than at review time — the reviewer assignment model — whether review requests are self-assigned or auto-assigned, what the auto-assignment algorithm is, and how the assignment model distributes load across a wider reviewer pool rather than concentrating it on the engineers with the most domain context — the PR size norm — what the target size is, what the enforcement mechanism is, and what the exceptions are — and the component ownership model — what the component owner's approval gate covers, how the gate is calibrated to distinguish architectural changes from routine modifications, and what the delegation model is for first-response coverage when the owner is unavailable. The reasoning in those sessions is the substance of the code review model — more so than the GitHub branch protection settings, the CODEOWNERS file, or the PR template — because the model's effectiveness in producing review throughput without sacrificing review quality is a function of whether it was designed with an accurate understanding of how review processes fail rather than how they look when they succeed. Running those AI chat sessions through the open-source extractor produces the code review velocity decision record that allows the next engineering leader to inherit the reasoning about why first-response SLA is two hours for tier-1 changes and twenty-four hours for tier-3 changes, why the component ownership approval gate covers interface and failure-mode changes but not configuration and operational changes, and why the PR size norm is enforced at creation time rather than at review time — rather than inheriting a CODEOWNERS file and a branch protection rule whose design rationale was worked out in a ChatGPT session by the engineering lead who set it up and whose departure removes the reasoning that makes the model's calibrations defensible.

Structural properties set by the engineering code review velocity decision

The engineering code review velocity ADR: five sections

FAQ

Further reading