Google's eng-practices repository is the company's public-facing guidance on how engineers do code review. It isn't a tutorial — it's a working document codifying how thousands of engineers at one of the largest engineering organisations on the planet keep their codebase deployable.
For most teams shipping software in 2026, the question isn't whether code review is valuable. It's whether code review is fast enough to keep up with deployment cadence. A team that deploys five times a day cannot afford reviewers who treat every PR like a thesis defence. Whether you're practising continuous delivery or true continuous deployment, the review process is the gate.
That's the lens for this article. The principles in Google's playbook are well-documented elsewhere. What rarely gets discussed is how each principle translates — and sometimes fails to translate — for teams whose definition of shipping
is twenty deploys before lunch
.
Small CLs are a deployment policy, not a style preference
Google's most cited rule: CLs (their term for changes
or PRs) should be small. Their official guidance points at under 200 lines as a strong target.
This isn't a style preference. It's a deployment policy.
A 50-line PR can be reviewed in ten minutes. A 500-line PR is a half-day commitment, which means it sits in a queue, which means the branch diverges from main, which means the eventual merge produces conflicts, which means the deploy is more dangerous. Every line of unmerged code is a small bet that nothing else will change underneath it before you ship.
We covered the mechanics of right-sized PRs in our pull request best practices guide — the 400-line threshold, splitting strategies, when to use stacked PRs. The Google rule is stricter than the industry average, but the underlying logic generalises: every unreviewed line of code is technical debt that gets harder to ship.
For teams running continuous deployment, the test is simple. If your average PR size means review takes longer than the time between deploys, your review process is the bottleneck. Halve PR size, and you roughly halve review latency.
LGTM
means good enough, not perfect
Buried in Google's documentation is what may be the most counter-cultural principle in modern engineering practice:
Reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn't perfect.
This is the principle that protects deploy cadence from review perfectionism.
Most teams have a reviewer who treats every PR as a chance to relitigate architecture. That reviewer is technically right — there's always a better variable name, a more elegant abstraction, an edge case worth handling. But better
is the enemy of shipped
, and code that never merges never improves the system at all.
The Google rule reframes review as a directional check rather than a quality gate. Did this PR move the code in a better direction? Approve. Save the perfectionism for the next CL by the same author.
This principle pairs directly with the dysfunctional reviewer patterns we wrote about previously — the reviewer who blocks for personal preference, the reviewer who relitigates settled decisions, the reviewer who uses approval as political leverage. Good enough
is the antidote, and it's the single hardest cultural change to land on a team that's grown up with the opposite norm.
One-business-day responsiveness is a deploy-velocity SLA
Google's playbook explicitly sets a response-time expectation: reviewers should respond within one business day, even if only to acknowledge that a full review is coming later.
For deployment teams, this is the most operationally consequential rule in the whole document.
Here's the failure mode it prevents. Engineer A opens a PR at 4pm Tuesday. No one responds. By Thursday morning, main has moved on — three other PRs have merged. Engineer A rebases. The rebase introduces a subtle conflict in a test fixture. The PR finally merges Thursday afternoon. The deploy pipeline runs. Production breaks on a code path nobody reviewed in the rebase commit.
That entire incident was a review-latency problem disguised as a deployment problem.
One-business-day responsiveness flattens that risk. PRs merge while main is close to the state they were written against. Conflicts stay small. Deploys stay safe.
For teams whose deploy cadence is faster than once per business day, the SLA needs to be tighter still. A daily-deploying team probably needs four-hour review turnaround as a working norm. The Google number is a floor, not a ceiling.
Once review latency is no longer the bottleneck, the deploy step determines how fast you actually ship. DeployHQ's build and deploy pipelines take a green PR and turn it into a production deploy in minutes — no manual SSH, no did we run migrations
, no surprises after merge.
The CL author owns the rollout
Google's documentation places clear responsibility on the CL author, not the reviewer, for the integrity of the change. The reviewer's job is to ask good questions and catch failures of judgement. The author's job is to actually understand the code and own the consequences.
For deployment teams, this resolves the most expensive failure mode in modern engineering: the merged and forgotten
PR.
The pattern is familiar. PR opens Friday afternoon. Reviewer approves. Merge button hit. Deploy goes out Monday morning. Something breaks. The author is on a different ticket. The reviewer never owned the change. Neither person remembers the context. Mean time to recovery: hours.
The Google rule kills this by making the author responsible end-to-end. The author opens the PR. The author addresses review comments substantively. The author merges. The author watches the deploy. The author is on the hook when the alarm fires.
This maps cleanly to the modern observability practices most deployment teams have adopted: the deployer is the responder. If you have AI code review catching mechanical issues before each deployment, and the author owns the runtime behaviour, your incident response gets dramatically faster — the person who shipped it knows where to look first.
Where Google's playbook breaks down for smaller teams
This is the section where most write-ups about eng-practices end. We are going to keep going, because the more useful question isn't what does Google do
but what should I do, given that I am not Google
.
Google has reviewer redundancy that small teams don't. Three failure modes break the playbook at smaller scale:
No reviewer pool to draw from. Google's one-business-day SLA assumes any of a dozen qualified reviewers can pick up your CL. A five-person startup might have one person qualified to review the auth layer. If that person is on holiday, the SLA is a fiction.
The reviewer is also the deployment owner. At Google, code review and operational ownership are decoupled by sheer scale. On a small team, the same person reviews the PR and gets paged when it breaks. That creates an incentive to over-review — to mentally substitute
did I check every line
forcan I sleep tonight
.The codebase is small enough that everyone touches everything. Google's review process assumes a stable ownership map per directory. Small teams don't have one. The reviewer is often re-learning a file at the same time as the author.
The honest translation: small teams should keep the spirit of the Google playbook — small CLs, fast turnaround, ownership-by-author — but accept that the implementation will look different. Pair-programmed PRs, async voice-note reviews, sometimes a ship now and review after the deploy
policy for genuine emergencies. These aren't deviations from the playbook. They're adaptations of it.
What does not adapt: the LGTM means good enough
principle. That one scales down perfectly. In fact it matters more on a small team, where one perfectionist reviewer can single-handedly throttle the entire deploy cadence.
Pair fast review with automated deploys
Once code review stops being the bottleneck, the deploy step becomes the next constraint.
Most teams reach this point and discover their deploy process is the embarrassing part. PRs merge in minutes; deploys take a half-hour of manual SSH steps. The math doesn't work — a 200-line PR reviewed in fifteen minutes, sitting behind a 45-minute deploy queue, gives back all the velocity gains from fast review.
Closing the loop requires deploy automation that's as disciplined as the review process. Atomic zero-downtime deployments, automatic config templating, and one-click rollback when something does go wrong are the deploy-side equivalent of Google's review rules. Our practical guide to implementing continuous deployment covers the prerequisites, the five-stage pipeline pattern, and the DORA metrics worth tracking once review velocity is no longer the bottleneck.
If you're already running a tight review process and your deploys feel slower than the rest of your engineering loop, DeployHQ connects your Git repository directly to your servers and turns every merge into a deploy. The review you just finished is the last manual checkpoint — everything after merge is automated.
For tool selection on the review side itself, our AI code review tools comparison covers what we use in production. AI tools catch the mechanical issues so human reviewers can do what the Google playbook is actually asking for: judgement calls, not nitpicks. We wrote separately about our hands-on experience using CodeRabbit before each deploy if you want the real-world numbers.
What to do with the playbook this week
Google's eng-practices repository is one of the few public documents that codifies how a large engineering org actually keeps its codebase deployable. The principles aren't magic — they're disciplines, and most of them scale down to teams of any size if you're honest about which parts of the playbook your scale supports.
The single highest-leverage move for any team reading it: stop treating perfect
as the review bar. Start treating moves the codebase in a better direction
as the review bar. That one shift, applied for a quarter, will do more for your deploy cadence than any tooling change.
When you're ready to make the deploy step keep up with your faster review process, start a DeployHQ trial and connect your first repository. The first deploy takes about ten minutes — and from then on, every merge is one click from production.
Questions, feedback, or war stories from your own review process? Reach us at support@deployhq.com or find us on @deployhq.