Conway’s Law of Engineering Management
October 4, 2024
Conway’s Law of Engineering Management
By: Tal Mor, CTO
Conway’s Law, a principle coined by computer programmer Melvin Conway in 1967, states that “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” In simple terms, the way teams are structured within a company directly influences the architecture of the software they build. If teams are siloed or fragmented, the software systems they create will reflect that disjointedness, and vice versa – collaborative teams tend to build more cohesive systems. This is best explained via the following simplistic illustration:
At Nexxen we’ve witnessed this law in action many times, both in positive and challenging ways. Below are a few real-world examples where Conway’s Law was applied, intentionally or otherwise, and how it shaped our technical architecture and teams structure.
The Monolith
Several years ago, Nexxen acquired a successful ad-tech firm that had built an impressive and feature-rich platform. However, it came with one significant architectural challenge: it was built as a monolith. A single, unified codebase where all functionality is tightly coupled. While such systems may be easier to develop in the early stages, they come with several long-term downsides. Such applications usually demonstrate slower development and scaling limitations given the butterfly effect, where for example, changing one line of code in the UI may impact the data-science codebase.
It was clear we needed to break down this monolith and transition to a distributed architecture with microservices. Distributed services allow different components of the system (e.g., runtime, front-end, data) to operate independently, making the system easier to scale, maintain, and deploy.
To make this transition, we reorganized the original monolithic development teams into several smaller groups, each focused on a specific domain – such as runtime, front-end, and data. These new teams, now more autonomous, were incentivized to take ownership of their respective areas, leading to the natural evolution of independent services. Each group began decoupling their domain from the monolith and building it as a standalone service. As Conway’s Law dictates, as our communication structure shifted, the software followed, evolving from a monolithic architecture into distributed microservices.
Distributed teams lead to misalignment
Not all outcomes of the newly distributed team structure were purely positive. As teams became more independent, we noticed an increase in the rate of production defects. The issue wasn’t with the teams’ capabilities but rather with a lack of alignment between them. As each team focused on its own service, communication across teams diminished, and this misalignment led to inconsistencies, integration issues, surfacing as bugs.
Because the teams were operating in silos, the systems they built reflected that disconnection. The architecture had become fragmented, with services not always communicating well or adhering to shared practices, leading to more integration issues.
Fearing the return of the monolith, we introduced a more structured communication framework, leaving the teams independent. For example, we implemented a rigid Slack structure, ensuring all teams had dedicated channels for cross-team collaboration, changes, and feedback. We created clear guidelines for communicating changes early and soliciting feedback across teams. Another example would be the enforcement of regular cross-team meetings and a shared incident response system improved communication, leading to faster resolution times and better alignment across services.
By improving the communication structure, we were able to reduce production defects and bring the architecture into better alignment with the business’s needs.
By improving the communication structure, we were able to reduce production defects and bring the architecture into better alignment with the business’s needs.
By improving the communication structure, we were able to reduce production defects and bring the architecture into better alignment with the business’s needs.
Freedom vs. Alignment
Another example of Conway’s Law at play can be seen in our front-end development teams. Nexxen operates several independent product lines, each with its own front-end application. Each product line is supported by its own development team, leading to a natural separation in how teams approach their work. Over time, this autonomy led to diverse tool choices – teams were using different logging frameworks, testing tools, monitoring solutions, and even CI/CD pipelines.
There are clear advantages to allowing teams to choose their own tools, such as increased ownership and innovation, however it raise the challenge of inconsistent practices. Each team’s differing choices in tools led to inconsistencies that made it harder to maintain, monitor, and support these applications at a company-wide level.
To address this, we reorganized the teams under a single department, while maintaining the independence of each team’s product line. This shared management layer ensured alignment on core tools and protocols (logging, testing, monitoring, etc.) while preserving the benefits of autonomy where it made sense. This approach allowed us to standardize critical infrastructure while giving teams the freedom to innovate within their domains.
Conclusion
Conway’s Law has been a guiding principle at Nexxen, sometimes intentionally and other times revealed through experience. Whether breaking down a monolith, dealing with the challenges of distributed teams, or balancing autonomy with alignment, we’ve learned that organizational structure and communication are just as critical to system design as the technologies we choose. By being mindful of how teams interact, we’ve been able to shape our architecture to better serve the business – and ultimately, our customers.
Read Next
