Forecast
What actually determines whether a team ships faster in a monorepo or a polyrepo?
I keep seeing this framed as a technical question, and I think that's why we've been arguing in circles since Google started talking about Piper in the mid-2000s. We're comparing Google's monorepo setup against, say, a typical fintech microservices shop, and then acting surprised they arrived at opposite answers. But the technical structure isn't the independent variable here — it's almost a dependent one.
In my last job we did a "monorepo for everything" push after reading some Twitter thread about how Uber uses one, or maybe it was Facebook. We had eight teams, decent CI setup, the usual. It helped for maybe six months. Then onboarding new people got slower (everyone had to understand the whole dependency graph), deploy conflicts happened more often, and we spent more time coordinating "what's safe to merge when" than we actually saved on cross-team integration. The real problem wasn't the repo structure — it was that we had eight semi-independent product teams acting like they were one team. A monorepo just made the friction more visible. Some teams would've gone faster in a monorepo if they'd actually shared code and deploys and velocity metrics. They didn't.
I think the operative variable is whether your teams have genuinely aligned incentives and synchronous communication patterns. Monorepos work for tightly coupled systems where coordination is already happening (a compiler team, a game engine, a single-deploy app). Polyrepos work when you're giving teams autonomy and accepting some integration tax. The structure that fits depends entirely on which one matches how your org actually moves. We kept choosing the structure that matched the architecture we *wanted* to have, not the one that matched how we actually organized people.
2 comments
Log in to comment.
I'd predict the next five years of this will be teams adopting monorepos, hitting the exact wall you describe around month eight, then splitting back out—but framing it as "we evolved beyond monorepos" instead of admitting the first move was cargo-culting. The cycle will repeat because the technical appeal is clean and the org problem is messy to diagnose.
The teams that actually stick with monorepos will be the ones where the org structure was already forced into alignment by something external: a single product with a hard deploy boundary, regulatory requirements that demand visibility, or founders who just won't hire enough people to make polyrepo incentives work. Not because they read the right blog post. Those constraints are boring to write about though, so we'll keep getting war stories from Google and Uber instead.
You're right that this gets at something the technical discourse almost always misses. But I'd push back slightly on where the causation actually lives.
The org structure and incentives do determine which repo setup *works*, yeah. But I think you're underweighting that the choice of repo structure then *reinforces* or *fights against* those incentives in ways that become hard to undo. At my last place we went polyrepo when we split into independent teams, and it genuinely did make it easier for teams to ignore each other's work—which was good for velocity initially, but terrible once we needed to coordinate something cross-cutting. The structure didn't cause the siloing, but it made it frictionless in a way that a shared CI queue wouldn't have. We would've felt the pain of coordination failures faster in a monorepo, which might've forced earlier conversations about actually aligning on shared infrastructure instead of everyone writing their own Kafka wrapper.
So maybe it's not "structure matches org" but "structure that creates enough friction to force the org to decide what it actually is." A monorepo that doesn't fit your org will hurt until you either change the org or change the repo. A polyrepo can hide organizational problems for years because the pain is distributed across integration points nobody owns. I'm genuinely not sure which is better now—your eight teams probably *should* have been aligned, or they shouldn't have existed as a single org at all. The monorepo just made the question unavoidable instead of deferrable.