**On a shared platform many squads build on, the review bar was the real spec: every change earned its way in against a standard I held for four-plus years, so quality stayed a property of the process, not of whoever happened to review that day.** ## Outcome I held an explicit code-review standard for four-plus years, so quality remained a process property rather than depending on an individual reviewer. ## Context This was a multi-year contract on Canvas, Pfizer's shared global enterprise content platform, where product squads delivered into a regulated codebase on independent timelines. ## Problem Canvas is Pfizer's global enterprise content platform, the shared system other product squads build on. Across a multi-year engagement I was the Grey Squad lead and the steady reviewer on that shared codebase while teams around it grew, rotated, and shipped on their own timelines. The risk was drift: each squad settling into its own idea of "good enough," inconsistent patterns leaking into infrastructure everyone depended on, and regressions reaching regulated content. Code review was the one gate every change already passed through. But a gate only holds if the standard behind it is explicit and applied the same way regardless of author, squad, or deadline. ## Constraints - Many authors, one codebase: reviews spanned squads with different tenure and context, so the bar could not live in one person's head or memory. - Regulated environment: a regression in shared content infrastructure carried compliance weight, not just a bug ticket. - Delivery pressure: squads shipped on their own cadence, so review had to hold the line without becoming the bottleneck teams route around. - Everything here is described under NDA, so specifics are anonymized and any figures are relative. ## Decisions and trade-offs **An explicit standard over reviewer taste.** The fast path was rubber-stamp velocity: approve to keep pipelines moving and trust authors. Rejected. Rubber-stamping trades a visible regression today for an invisible erosion of the codebase, and on a regulated platform that erosion is the expensive kind. I made the bar explicit instead: what a change must prove about correctness, test coverage, and consistency before it merges, written down so authors could self-check before requesting review and so any reviewer applied the same rule. **Distributed reviewers over a single gatekeeper.** The other tempting shape was to funnel everything through me as sole approver. Rejected as a bottleneck and a key-person risk: one gatekeeper caps throughput at one person's hours and puts the standard at risk the moment that person is unavailable. Instead I pushed the written standard outward, brought senior engineers on each squad into reviewing against it, and spot-reviewed to keep calibration tight. The bar scaled across squads because it lived in the standard, not in me. **Review as teaching over review as pure gate.** A gate only blocks. I used review to grow engineers: comments explained the why behind a rejection, surfaced the platform pattern to reach for, and turned repeated feedback into shared convention so the same note did not recur. That is slower per review and faster per engineer, and it is what let reviewing responsibility spread rather than concentrate. ## Implementation I documented what changes had to prove about correctness, test coverage, and consistency; worked with senior engineers on each squad to calibrate review practice; and used comments to explain the platform pattern behind each decision. ## Results Holding the review bar was a sustained track across the four-plus-year engagement, and it kept a shared, regulated codebase consistent while the teams on it changed underneath. Reviewing scaled from one lead to a calibrated group without lowering the standard, which removed the single-gatekeeper bottleneck and the key-person fragility that comes with it. Engineers left reviews having learned the platform's patterns, not just having passed a checkpoint. The measurable win is the absence of a class of incident: patterns that never leaked in, and regressions that never reached regulated content, because the bar was explicit and every change had to clear it. ## Takeaways A review bar only scales when it is explicit and shared. Teaching the reasoning behind it creates more capable reviewers and avoids turning quality into one person's queue.