Large organizations like Google enforce a strict 'one version of everything, everyone builds at HEAD' policy across a single enormous monorepo. What makes that policy tractable at their scale, and under what organizational conditions would adopting the same strict single-version policy be the wrong call for a smaller company?

## The policy Google's monorepo (famously covering the vast majority of the company's server-side and much client-side code in one enormous shared repository) enforces what's sometimes called 'one version' or **'live at HEAD'**: for any given external or internal dependency, there is exactly one version in use across the entire codebase at any point in time, and every team's code is expected to build against the current state of everything it depends on, not a pinned snapshot. This is the single-source-of-truth and atomic-cross-project-change philosophy taken to its logical extreme across a codebase with (as of public accounts) billions of lines of code and millions of build targets. The reason this doesn't collapse under its own weight is that Google built, and continuously invests in, infrastructure specifically engineered to make it survivable, and it's worth being concrete about what that infrastructure actually does. ## What makes it tractable 1. **First, the build system.** Bazel, and internally Blaze, models dependencies as an explicit, fine-grained graph and only rebuilds and retests the transitive closure of targets actually affected by a given change, not the whole repository — this is what keeps CI cost from growing unboundedly as the repo grows, and it's paired with aggressive remote build caching and distributed/remote execution so that even a large affected graph builds in parallel across a fleet rather than serially on one machine. 2. **Second, pre-submit infrastructure.** It runs that affected-graph build and test automatically before a change is allowed to merge, which is what actually enforces atomicity in practice — a change that breaks any downstream consumer in the affected graph simply cannot land, so the 'everyone always builds at HEAD' invariant is a continuously-checked guarantee, not a hope. 3. **Third, large-scale-change (LSC) tooling.** Automated codemods plus workflow infrastructure that can generate, test, and land coordinated edits across thousands of files and many different ownership boundaries is what makes lockstep upgrades of foundational APIs actually executable rather than theoretically nice. Without LSC tooling, 'update all 5,000 call sites of this function across 400 teams' is not a realistic ask of any single engineer or team; with it, it becomes a mostly-automated, reviewable, days-to-weeks project instead of an organizational-scale negotiation. ## When it is the wrong call Given all that infrastructure investment, when is the same policy the wrong call for a smaller organization? A few concrete conditions matter. 1. **First, capacity.** Building and maintaining an affected-graph-aware build system, remote caching, and codemod/LSC tooling is itself a substantial, ongoing engineering investment — a 30-person startup adopting a strict single-version monorepo policy without any of that tooling typically ends up hand-rolling the coordination cost instead (every dependency bump becomes a manual, all-hands scramble), which is strictly worse than either a well-tooled monorepo or a normal polyrepo with versioned packages. 2. **Second, organizational boundaries.** If different teams genuinely need independent release cadences — a mobile team shipping to app-store review cycles, a regulated-industry team that must freeze dependencies for a compliance audit window, or teams acquired via M&A with genuinely separate roadmaps — forcing them onto one shared version removes exactly the autonomy those teams need, and the coordination cost isn't buying anything since the teams weren't trying to move in lockstep anyway. 3. **Third, graph shallowness.** Single-version enforcement earns its keep specifically when the dependency graph is deep and highly shared, so that avoiding version skew prevents a large number of latent diamond conflicts; if most internal projects share few or no dependencies with each other, there's little skew risk to prevent, and the enforcement overhead (blocking a team's independent work behind an unrelated build failure elsewhere in the graph) has little corresponding benefit. ## The practical middle ground The practical middle ground many mid-sized companies land on is a **hybrid**: - internal libraries that are tightly coupled and frequently co-changed live in a shared workspace with the source-import, no-version-pin model (getting atomicity where it matters most), - while more independent components — especially ones with genuinely different release cadences, like a mobile client versus a backend service — keep normal semantic-versioned package boundaries, sometimes even within the same physical repository via workspace tooling (pnpm workspaces, Nx, Turborepo) that supports both patterns side by side rather than forcing an all-or-nothing choice. The lesson generalizes: single-version coordination is a tool for eliminating a specific failure mode (silent version skew and diamond conflicts across tightly coupled code), and like any tool it should be applied where that failure mode is actually expensive, not treated as an ideology to apply uniformly regardless of an organization's shape, size, or tooling budget.