# I Watched Two Dev Teams Fight a Mono-Repo War. A Manager Started It. > *(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: 1. A non-technical manager had created an architectural disaster by forcing two conflicting goals into one codebase. 2. A Product Owner had stepped out of their role, making a *technical* decision (speed/debt) instead of a *functional* one (priority). 3. 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?*