TL; DR: A concept originally coined in the late sixties is now taking the business world by storm. Conway’s Law, an adage that stresses the importance of team communication to produce successful products, is transforming how we view work and how teams should organize to make incredible ideas a reality.
Is there such a thing as the perfect working environment? Imagine if you had the opportunity to create an organization from scratch. What systems would you put in place? How do you organize work? Ensuring communication, transparency, efficiency, and best practices are challenging in every field, but software development stands out for its particularities.
Technology consultant Kenneth Reilly considers software development one of the least understood fields in the world. If you had the opportunity to look at a software development project halfway, you wouldn’t understand it like you observe a house under construction. “There are infinite ways of building applications and services,” he says, “and it’s difficult for all but the most experienced professionals to see what’s going on under the hood.” Building software takes more than just having good ideas and good professionals.
In 1967, computer scientist Melvin Conway spoke amply about such an idea and summarized it in an adage known to many as “Conway’s Law.” Let’s explore what it is and analyze its implications for modern software development companies.
An overview of Conway’s Law
Conway’s main thesis, published in one of the most important IT magazines at the time, states that “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” According to the original version, because communication structures have important implications in system design, they should be a relevant criterion when organizing any system.
His original article focused only on the connection between communication and the system itself; it didn’t go as far as stating that the product resulted from the type of communication. In other words, for two software modules to integrate correctly, both developers need to speak to each other well.
How did this idea spurred that communication structures affect a system design? It developed from the subsequent interpretations of the article, starting with computer scientist Fred Brooks, the person responsible for calling it “Conway’s Law.” Experts who have cited Conway’s Law go beyond the author’s original intent and observe a clear relationship between an effective product and the flexibility of the organization that designed it.
Why designing your organization is more important
Eventually, Conway’s Law helped develop and prove the hypothesis that the organization and the product are closely related. This idea, tested by a group of MIT and Harvard engineers as the “Mirroring Hypothesis,” proves that an organization’s governance and culture set the space and limits to the work performed.
Instead of being plagued with common issues, such as siloed information that takes far longer to reach people who need it, a confused team, or leadership that doesn’t consider critical feedback from key stakeholders, an understanding and application of Conway’s Law helps prevent common communication issues. It emphasizes training, best communication practices, proper documentation, and encouraging feedback in leadership positions.
The connection between communication and the overall human organization and design helps explain why certain products work and exist. They mirror the people who created them. This means that an architectural decision can affect how a team works, as well as the other way around. And it makes sense.
How Conway’s Law works in real life
Conway’s Law doesn’t simply make sense on paper or a screen: developers can ensure better products when their processes and communication channels are clearly stated. CBInsight’s “The Laws Driving Success in Tech” provides two case studies of two well-known tech companies to explain how this concept goes beyond the realms of theory.
The first example is Apple, which uses an organizational structure known as Unitary Organizational Form. Their main objective is “that the company should be organized around functional expertise rather than products.” In other words, instead of dividing their company into products, they prefer to organize it into disciplines. The end result is a unified experience where no product steers away from the company’s vision and feel.
There’s no single way of following Conway’s Law. GitHub’s case offers a piece of great evidence to the point that differs from Apple. According to the CB Insights report, the company is “intentionally structured like one of the open-source projects the service hosts: decentralized, autonomous, and asynchronous.” What does this mean? There’s no entry time, and work is self-directed. Instead of having daily stand-ups, people use only chat or email.
Although this latter concept may seem a bit extreme for many managers, let’s remember that GitHub is a tool created for developers based on decentralized collaboration. In that sense, GitHub successfully mirrors the product they offer. They allow their teams to work collaboratively and in a decentralized manner.
And we go back to the employee experience
We’ve spoken several times about the importance of the employee experience at Blankfactor and how good relationships with your team members can reflect on successful client relationships. Blankfactor’s take on Conway’s Law is to create also an attractive Employee Value Proposition (EVP) centered on employee-centric processes.
A people-centered approach motivates leaders and teammates to actively collaborate and support each other. They do their best to apply their interpretation of the company message. The result is not only a product everyone is proud of but also a team that enjoys working together.