What I got wrong about monorepos

I spent two years arguing that we should split our monorepo. Build times were creeping up, CI queues were backing up on Fridays, and every proposal to add a new service got tangled in questions about where the code should live. I had graphs. I had a plan. I was, in retrospect, arguing about the wrong thing.

The boundary I was actually protecting wasn’t technical — it was social. Two teams had grown apart in how they reviewed code, how fast they wanted to move, and how much risk they were willing to carry on a Friday afternoon. A repo split would have let each team set its own pace, but I was pitching it as a build-performance fix, and build performance turned out to be the easiest part to solve.

We fixed the actual build problem with better caching and a task graph that only rebuilt what changed — a few weeks of infrastructure work, not a migration. The social boundary took longer: separate CODEOWNERS, separate release cadences, a shared library with an actual deprecation policy instead of “just don’t break it.” None of that required a second repository.

If I were making the case again, I’d start with the org chart, not the folder structure. The tooling question is almost always answerable; the question of who owns what, and how much friction they’re willing to accept from each other, is the one that actually decides whether a split helps.