![[Conway's Law#^definition]] I begin this section with one of my favorite laws—one that perfectly illustrates how most project issues are ultimately communication issues, which in turn are reflected in the organization’s structure. And structure is the first and easiest thing to observe. This was particularly important because, at the start, structure was the only thing I had access to. Since this was Martyna’s audit, my role was to analyze what she had observed, without direct interaction with their team—essentially making it a **black box** situation.  ^black-box At first, this might seem like an impossible challenge, but Martyna had described their problems with remarkable precision. In fact, I wasn’t even the one asking the questions—she was. And her questions were spot on. ### PM + team split The first questions considering frontend and backend team split she started with: > *It's not about a **technical** separation of FE and BE (!),* > *but about **separate meetings, plannings, and siloing of both parts**.* ^fe-be-communication This was the perfect remark—because it didn’t just focus on the technical differences between frontend and backend teams but rather on why they had become siloed in the first place. What’s more, task-level coordination between developers was being handled by the Project Manager, which, as you can imagine, led to potential problems. ![[Team vertical split.png|400]] So the obvious next question was: **Why was the team structured this way? What led to this setup?** And the answer? Well, it wasn’t hard to guess...  ^but-why-nobody-knows ### [[Lattice team]] The key issue wasn’t just the theory behind why organizations make such splits—it was whether anyone in the team actually knew why this decision had been made. Did the team understand the reason behind it? Because this directly shaped how they communicated. And that led to the next critical question: HOW does the FE team communicate with the BE team? > *They **don’t even know what their [BE] structure looks like**...* > > *[...] One developer works on **FE dashboards** and has one assigned BE developer for **BE dashboards**—that’s how they coordinate.* ^vertical-division ![[Team lattice.png|400]] As mentioned earlier, task synchronization between both teams was managed by their PM. But an even more interesting pattern emerged: - Some individuals **did** communicate across teams, - But **only within specific feature silos**, - And barely with others inside their own team. ^communication-patterns ### Silos This created a network of isolated feature silos rather than an integrated team. The frontend and backend weren’t just technically separated—they operated as distinct units, each with their own meetings, plannings, and internal flows. The division wasn’t driven by architecture, but by communication boundaries. ![[Silo#^definition]] ![[Lattice team.png|400]] In practice, this meant that some individuals did collaborate—but only within the context of specific features. They rarely communicated across silos and, surprisingly, not even consistently within their own. The result was a fragmented web of micro-teams, each solving its own problems in isolation. The consequences were predictable: ![[Silo#^consequences]] Silos don’t just slow you down—they compound risk. Decisions made in isolation tend to optimize locally rather than globally. And when issues arise, they’re harder to diagnose because no one has the full picture. ### [[Brooks’s Law]] Meanwhile, Martyna and I noticed something else—their **backend team was significantly larger than their frontend team**. This might have made sense, but we wanted to confirm if **they actually knew why**. ![[Team scalability.png|600]] > *[...] Things were moving too slowly.* > *So they hired more backend developers, but now there’s **no budget left for FE**.* ^be-bigger This wasn’t just a management failure—it also highlighted a fundamental misconception - Scaling a team does not immediately scale delivery. Hiring more developers does not automatically increase output proportionally—in fact, it can slow things down before it speeds them up, as new people need onboarding, which affects the productivity of the existing team. ![[Brooks’s Law#^definition]] ![[Brooks’s Law#^explanation]] ![[Brooks’s Law#^visualized]] It ultimately exposed poor management and a lack of understanding that weak or missing processes become even more visible during scaling. Some gaps simply can't be shortcut—without the right foundations, growing the team only makes things worse. ### Overscaled siloed monolith What we were looking at wasn’t just a communication failure. It was a structural one: - **Siloed [[Monolith|monolith]]**, - A structure that no one fully understood, - Teams that barely knew each other, - And severe communication breakdowns.  In short, the organization had scaled in the wrong places, without the right foundations. And it was now paying the price in delivery speed, cohesion, and morale. So, when looking at this through the lens of [[Conway's Law]], the picture becomes crystal clear: The architecture mirrored the org chart. And the org chart mirrored their communication failures.