Your Monorepo Is Saving Build Time. Your Org Chart Is Eating It.
Three years ago your engineering team adopted a monorepo. The pitch was coherent: shared tooling, atomic commits, unified CI, no more dependency versioning nightmares across twelve separate repos. You used Nx or Turborepo. Your build times dropped. Your dependency graph got clean. The blog posts wrote themselves.
Then something strange happened. The meetings got longer. PR reviews slowed down. Teams started having conversations about ownership they'd never needed to have before. Your platform engineers began spending more time managing cross-workspace concerns than building platform features.
The build problem was solved. The coordination problem had just begun.
The Narrative Was Always About Build
The monorepo tooling renaissance — Turborepo, Nx, Bazel for the ambitious — was fundamentally a story about build performance and dependency coherence. Cache shared tasks. Run only what changed. Stop rebuilding the world when one package updates. All of this is real and measurable, and the gains are genuine.
But build performance was never the expensive problem. It was the legible problem. You can benchmark it. You can show the before and after in CI dashboards. It's a compelling slide for engineering leadership.
Coordination costs don't show up in dashboards. Nobody charts the time spent in a 40-minute Slack thread arguing about whether a change to a shared utility package requires two approvals or three. Nobody tracks the cognitive load of a senior engineer who now needs to understand the ripple effects of a refactor across six consuming services she doesn't own.
The monorepo made those ripple effects possible. The tooling didn't account for what happens when ripple effects scale with headcount.
Blast Radius Is a Feature Until It Isn't
In a polyrepo world, blast radius is bounded by the service boundary. A change to Service A requires deploying Service A. The blast radius is Service A's problem. If something breaks, you know roughly where to look.
In a monorepo, a change to a shared utility can touch everything that imports it. That's the point — you wanted coherence, and coherence means everything that depends on the thing you changed is now in scope. Turborepo's incremental build knows what changed; it reruns the graph of affected packages automatically.
The build system handles this. The social system — the humans who need to review changes, understand their impact, and maintain the mental model of cross-workspace dependencies — does not handle this automatically. It scales with the complexity of the graph.
As the graph grows, the question "is this change safe?" gets harder to answer without involving more people. Which means more review cycles. Which means more time between merge and deploy. Which is the opposite of what the monorepo was supposed to deliver.
AI-Assisted Development Made This Worse
There's a specific 2025-2026 pattern worth naming. AI coding tools — Copilot, Cursor, Claude — dramatically lowered the friction of writing code across unfamiliar files and packages. A developer who would have paused before touching a shared library now touches it freely, because the AI autocomplete handles the syntax and the tests write themselves.
In a polyrepo, this is mostly fine. The cognitive boundary of "I shouldn't touch the auth service without understanding it" still exists and is reinforced by repository access and deployment gates.
In a monorepo, the boundary is softer. Everything is one checkout. A developer using AI assistance can generate a change to a shared utility they've never deeply understood, with confidence, because the code is syntactically correct and the tests pass. The change ships. Three weeks later, a downstream consumer breaks in a way nobody predicted.
This isn't a hypothetical. It's the emerging pattern behind AI-generated code debt and the accountability gap now visible in teams that adopted AI coding tools without updating their review processes. The monorepo amplifies the blast radius. AI coding tools amplify the rate of change. The combination creates a debt accumulation that's faster than any single team's visibility.
The Conway's Law Reversal Nobody Planned For
Conway's Law says your system architecture will mirror your communication structure. The practical application: design your org chart, and your codebase will follow.
Monorepos introduced a reversal that most teams didn't anticipate. The shared codebase is now defining the org chart rather than reflecting it. When package A lives next to package B in the same repository, the implicit message is that they're related — that the team owning A and the team owning B should talk. Whether or not that's true in practice, the structure creates an expectation.
This generates phantom coordination. Teams feel obligated to review each other's changes because they're in the same repo, even when the packages are genuinely independent. This is the opposite of what good team topology produces: clear ownership, minimal coordination surface, and high autonomy within a domain.
The monorepos that work well — at companies like Google and Meta, which have had decades to develop the practices around them — have extensive internal tooling for code ownership, automated routing of reviews, and explicit deprecation paths for shared utilities. They built organizational infrastructure to match the technical infrastructure. Most teams adopting monorepos in 2024-2025 took the tooling, skipped that part.
What the Teams That Do It Well Actually Do
A monorepo without ownership clarity is a shared technical commons. The tragedy of the commons is predictable: everyone uses it, nobody maintains it, it degrades.
Teams that avoid this solve three problems that tooling won't:
Explicit ownership at the package level. CODEOWNERS is not enough. Every package in the repository should have a named maintainer or team who is responsible for its API contract, its deprecation path, and its breaking changes. When that's unclear, the overhead becomes distributed across everyone who uses the package.
A policy for cross-workspace changes. If a change touches more than one team's packages, who approves it? What's the escalation path? Most teams don't have this written down, which means it gets resolved case by case, which means it's resolved inconsistently, which means it causes friction every time.
A version discipline for internal packages. Not semver necessarily, but something. Some signal that distinguishes "I updated the implementation" from "I changed the interface." Monorepos make it easy to skip this — you can just update the source and bump every consumer simultaneously. That convenience becomes a problem when the consumer is in a different quarter's roadmap and can't absorb the change on your timeline.
None of this is about tooling. All of it is about the humans working inside the structure.
The Real Question
The value proposition of a monorepo isn't wrong. Unified tooling, atomic changes, dependency coherence — these are real benefits that polyrepos make difficult. The problem is that the benefits are legible and the costs are not.
Before you adopt a monorepo, or before you give up on one, ask this: can every engineer on your team name who to talk to when a shared package breaks? Not "probably the platform team" or "the people who last touched it." A specific name or team, with a defined escalation path.
If the answer is no, the tooling isn't your bottleneck. The organizational clarity is. And no build cache in the world makes up for that.
Photo by pipop kunachon via Pexels.