The Monorepo Decision That Unified an Engineering Organization

The Monorepo Decision That Unified an Engineering Organization

The Problem That Wouldn’t Go Away

When Sarah Chen joined Meridian Technologies as a Staff Engineer in 2021, the company had 40 microservices spread across 40 separate repositories. On paper, this looked like modern architecture. In practice, it was engineering chaos.

“Every change touching multiple services required opening 4-6 pull requests,” Sarah recalls. “Engineers spent more time managing git branches and coordinating deployments than writing code. We had version skew issues constantly—Service A would deploy with incompatible changes before Service B was ready.”

The pain was measurable:

But here’s the thing—nobody thought the repository structure was the problem. Teams blamed process, communication, planning, tooling. The 40-repo structure was just “how things were.”

The Observation That Changed Everything

Sarah’s breakthrough came from an unexpected place: onboarding.

“I was mentoring a new senior engineer,” she explains. “Smart person, experienced. But watching them try to set up their development environment was painful. They needed to clone 12 repositories, each with different tooling versions, different build commands, different test runners.”

It took 3 days to get a working development environment.

That’s when Sarah saw the pattern: The multi-repo structure wasn’t just slowing down cross-team changes—it was multiplying complexity across every single engineering activity.

“I realized we weren’t dealing with a process problem or a communication problem,” Sarah says. “We were dealing with a structure problem that made every other problem harder to solve.”

Building the Case Without Authority

Sarah had no direct authority over engineering infrastructure. She couldn’t mandate a monorepo. She couldn’t force teams to change. But she had something more powerful: data and a compelling narrative.

Phase 1: Measure the Invisible Cost

Sarah spent two weeks collecting data:

The headline number: Engineers spent approximately 8-12 hours per week on repository coordination activities that added zero product value.

Across 80 engineers, that was 640-960 hours per week burned on coordination overhead. At $150/hour loaded cost, that’s $5-7.5M annually.

Phase 2: The Prototype That Proved It Was Possible

Numbers got attention. The prototype got buy-in.

Sarah spent evenings and weekends migrating five related services into a monorepo prototype. She:

The result: A cross-service change that previously took 2 days with 5 PRs now took 3 hours with 1 PR.

“I recorded a 15-minute demo video,” Sarah says. “Showed the old way vs. the new way for the exact same feature change. The difference was visceral.”

Phase 3: Finding the Right Moment

Sarah didn’t push immediately. She waited for the right organizational moment.

That moment came when the company started planning Q3 OKRs. The VP of Engineering asked teams to commit to ambitious cross-platform features. Every single team highlighted “cross-service coordination” as a major risk.

Sarah saw the opening.

She scheduled 30 minutes with the VP, came prepared with:

  1. The cost analysis ($5-7M annually in overhead)
  2. The demo video (undeniable evidence it could work)
  3. A phased migration plan (starting with opt-in pilot)
  4. Risk mitigation strategies (what could go wrong and how to handle it)

“I didn’t ask for permission to do a monorepo,” Sarah reflects. “I presented a solution to the problem he was already worried about. The repository structure was my answer to his question about velocity.”

The VP gave the green light for a pilot.

The Implementation: Going Slow to Go Fast

Sarah’s migration strategy was deliberately gradual:

Pilot Phase (Q3 2021): 5 Services, 2 Teams

Results after 6 weeks:

Expansion Phase (Q4 2021): 15 Services, 6 Teams

The key insight: “I made it opt-in but inevitable,” Sarah says. “Teams that migrated immediately saw productivity gains. Teams that didn’t started feeling left behind—they were doing manual coordination while monorepo teams just… shipped faster.”

By end of Q4, 12 of 15 teams had voluntarily migrated.

Completion Phase (Q1 2022): All Services

The Impact: Numbers and Culture

Measurable Outcomes:

Cultural Shifts:

“The monorepo changed how teams thought about ownership,” Sarah observes. “Before, each team protected their repo like territory. After, teams realized they were all building the same product—just different parts of it.”

The Career Lesson: Technical Leadership Through Structure

Sarah’s promotion to Senior Staff came six months after the monorepo migration completed. In her promotion packet, her manager wrote:

“Sarah demonstrated the highest form of technical leadership: she changed the structure of our systems to make good outcomes easy and bad outcomes hard. She didn’t mandate better communication—she removed the need for coordination. She didn’t ask teams to work harder—she removed obstacles that slowed them down.”

The lessons Sarah shares with other Staff engineers:

  1. Look for structural problems, not people problems. When everyone is struggling, the system is usually broken, not the people.

  2. Make the invisible visible. The cost of poor structure is often hidden in “coordination time” and “context switching”—quantify it.

  3. Prototype before proposing. A working demo is worth 100 architectural diagrams.

  4. Wait for organizational energy. The best technical decisions need organizational readiness. Sarah’s timing—when leadership was worried about velocity—was crucial.

  5. Make change gradual and voluntary. Forcing adoption creates resistance. Making success visible creates momentum.

  6. Infrastructure changes are cultural changes. Sarah’s monorepo wasn’t just a technical decision—it changed how teams collaborated and thought about ownership.

The Follow-On Effects

Three years later, Meridian’s monorepo has become a competitive advantage:

“People ask me if I regret not doing it sooner,” Sarah says. “But I don’t think it would have worked earlier. The organization needed to feel the pain first. My job wasn’t to have the idea—plenty of people talked about monorepos. My job was to recognize the moment when the organization was ready to change, and provide the path.”

That’s Staff engineering in a nutshell: seeing the problem, building the solution, and navigating the organization to make it real.

../