I Watched Two Dev Teams Fight a Mono-Repo War. A Manager Started It.
A true story about how one "efficient" non-technical decision doomed two projects, ignited a team conflict, and cost us a mountain of technical debt.
(Note: To protect everyone's privacy, I will not be naming the organization, the projects, the managers, or the teams involved in this story. The lessons are universal, and that's what matters.)
The "Efficient" Promise
It was my first major project in a new capacity. I was in the middle of transitioning from being a developer in a team to a Tech Lead overseeing teams.
The project seemed straightforward: rebuild a website with new tech. We were finally decoupling the front-end from the back-end (yes, I know, it's amazing this is still a 'new' thing in some organizations) and using GraphQL. It was exciting.
The budget and deadline, of course, had already been set by management.
Then came the meeting. The 'Big Idea' meeting.
A project leader pointed out, "You know, Website B uses 90% of the same data as Website A. It would be incredibly efficient if we just... build them both at the same time? In the same project?"
The non-technical managers in the room nodded. They saw spreadsheets. They saw synergy. They saw a '2-for-1' deal.
My teammate and I looked at each other. We saw the disaster from miles away.
We knew we had to speak up, even though we didn't want to be the "party poopers." We explained that architecturally this wasn't a good idea. That forcing two different teams with two different goals into one repo would create massive challenges.
And then we fell into the classic developer's trap.
A manager asked, "But... setting the challenges aside, is it technically possible? Can you manage it?"
As engineers, we answered honestly: "Well... technically... yes, we can make it work. But it's not the right way to do it."
They only heard the "yes." They ignored the rest.
Our technical honesty—the distinction between what is possible and what is wise—was just used as a green light. They heard "technically manageable." We meant "architectural nightmare."
That was the real "Oh... SHIT" moment. The decision was made.
The Setup: Two Teams, One Arena
Here was the fatal structure the non-technical managers had designed:
The Arena: A single mono-repo. (Because: 'shared code' = 'efficient').
Team A (Internal): My team. Our Goal: Build a sustainable, scalable, and maintainable solution. We were the craftsmen. We would own the platform long-term.
Team B (External): The hired guns. Their Goal: Hit the deadline, at all costs. They would send an invoice and then disappear.
They had put two teams with exact-opposite incentives in the same cage and expected them to collaborate.
The Conflict: The Mono-Repo War
This wasn't an immediate explosion. It was a slow-motion tragedy in three acts.
Act 1: The First Cracks To be fair, it didn't start as a war. The first few sprints were actually collaborative. We were all figuring out the new architecture, communicating, and building.
The cracks began to show when my team (Internal) started building the core, sustainable, shared components. As craftsmen, we were building them properly—thinking about accessibility, scalability, and reusability. This is the crucial work that saves you from a year of pain later.
But this kind of "doing it right" takes time.
The external team, and the PO, didn't see 'quality'. They saw 'slowness'. They had a deadline to hit. Our craft was a blocker for their velocity.
This was the first real crack. Frustrated, Team B did what they were incentivized to do: they started cutting corners to get around our "slow" process. They began writing one-off, unsustainable code to 'just get the feature out'.
Act 2: The Political Coup The conflict quickly escalated from the code editor to the meeting room. And let's be clear: I don't blame the external team. They were simply executing on their goal (speed). The friction was inevitable because their goal was fundamentally in conflict with our goal (sustainability).
The manager of the external team, frustrated by our 'quality gates', went directly to the Product Owner (PO).
Their argument was as simple as it was deadly: "The internal team is blocking us. They are the reason we're going to miss the deadline."
They had successfully reframed the narrative. Our quality control wasn't 'guarding the architecture' anymore; it was 'a blocker to progress'.
And the PO, who was under immense pressure to hit the (already unrealistic) deadline, zwichtte. They made a fatal error: as the owner of functional priorities (the "what"), they stepped out of their role and made a technical decision (the "how").
They chose speed.
Act 3: The Banishment It all culminated in a meeting I will never forget. The PO, now fully allied with the 'speed-at-all-costs' manager, made the final call.
My teammate and I—the two developers fighting hardest for the long-term sustainability of the platform—were officially removed from the project by the Product Owner.
We were the problem. The 'difficult' developers who were 'slowing things down'.
The Reckoning: The Real Cost of "Efficiency"
With 'the blockers' (us) out of the way, the external team had free rein. They slammed the code through. They 'hit' the deadline (with massive stress and overtime). The manager was 'satisfied'. The PO was 'relieved'.
And now, months later, the real bill is here.
Team B is long gone.
And the backlog from the external team? That's our backlog now. A toxic, open sewer of bugs, performance issues, and architectural sins that my internal team now has to live and work in, every single day.
The "fast" solution created an endless maintenance burden.
The only saving grace? The internal developers who remain. They are, to a person, craftsmen who believe in building sustainable solutions, and I am incredibly lucky to work with them. But they are the ones now paying the price, forced to clean up a mess they never made.
The Lesson: The Birth of My Role as a Tech Lead
This disaster wasn't just a 'bad project.' It was the end of my role in a team and the beginning of my role as a Tech Lead.
My own team leader was furious. He saw exactly what had happened:
A non-technical manager had created an architectural disaster by forcing two conflicting goals into one codebase.
A Product Owner had stepped out of their role, making a technical decision (speed/debt) instead of a functional one (priority).
Craftsmanship had been sacrificed for short-term politics.
His solution was to create my new role. A Tech Lead, positioned outside the project silos, with one clear, organization-wide mandate:
"This can never happen again."
My Lesson for Every Manager
My role was born from that conflict. And that is what I, and the amazing internal team, are fixing to this day. We're not just cleaning up the mess; we're building a better way to work.
We are defining our quality standards. Not "perfection"—perfection is a trap. We are defining sustainable and stable standards. We are building the guardrails that make it easier for teams to maintain quality, even when project pressure builds.
Here is my simple, yet unbreakable, lesson for every manager, project leader, and Product Owner out there.
Never. Ever. Make a technical decision.
That's what your Tech Leads and developers are for. They are more than capable of handling it.
And if your tech team does ask you to make a choice—like "Do we choose Speed or Quality?"—your only job is to let them advise you. Ask them to explain the consequences. They are the only ones who truly understand the long-term technical effects of each choice.
Listen to them. Trust their craft. You may not hear the answer you want, but you'll hear the one that's true. And you'll save yourself from starting a war you can't win.
What do you think? Have you seen a "logical" decision doom a project? How do you guard the line between technical and non-technical decisions in your organization?
