Also called: Conway's Law, Melvin Conway's Law, Information Flow Law, Organizational Design Law, Communication Structure Law, Law of Organizational Design, Law of System Design, and Law of System Evolution
See also: Hackman's Law, Parkinson's Law
Relevant metrics: Productivity, Team Collaboration, Time to Market, Quality of Deliverables, and Customer Satisfaction
What is Conways Law?
Conway’s Law states that the structure of a system is determined by the communication patterns of the people who design it. This means that the way in which people communicate and collaborate when designing a system will have a direct impact on the structure of the system itself. For example, if the people designing a system are organized into separate teams, then the system will likely be divided into separate components.
The structure of a system is determined by the communication patterns of the people who design it
Conway’s Law is an adage in software engineering which 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.” It was formulated by Melvin Conway in 1968. The law is often used to explain why many large software projects fail to meet expectations.
Conway’s Law is an important principle to keep in mind when designing a system, as it highlights the need for effective communication and collaboration between product managers and user experience designers. By understanding and applying this principle, product managers and user experience designers can ensure that the system they are designing is optimized for user experience.
Where did Conways Law come from?
Conway’s Law was first proposed by Melvin Conway in 1968 in an article titled “How Do Committees Invent?”. In the article, Conway argued that the structure of a system reflects the structure of the organization that created it. He argued that the organization’s structure and communication patterns will be reflected in the design of the system.
He also argued that the organization’s structure and communication patterns will determine the complexity of the system. Conway’s Law has since become an important principle in software engineering and has been used to explain the complexity of software systems.
A Guide to Understanding Its Impact on Software Development
Conway’s Law is often used to explain why certain software projects fail. It suggests that if the organization is structured in a way that does not promote collaboration and communication between teams, then the resulting software product will be of poor quality. This is because the teams will not be able to effectively work together to create a cohesive product.
Conway’s Law can also be used to explain why certain software projects succeed. If the organization is structured in a way that encourages collaboration and communication between teams, then the resulting software product will be of high quality. This is because the teams will be able to effectively work together to create a cohesive product.
Conways law and designing teams for low software coupling
Effective communication between developers leads to better understanding and interaction between their codes. Shared assumptions and ways of thinking about the problem domain can make code coupling more implicit than explicit. As a result, ignoring Conway’s Law can lead to twisted system architectures, causing tensions and complications in the software structure. Teams responsible for certain modules can be at odds, leading to miscommunication, reduced collaboration, and missed opportunities for beneficial design alternatives.
Conway understood that software coupling is enabled and encouraged by human communication
Conway’s Law also highlights the importance of team size and communication frequency. Smaller teams that communicate frequently and informally tend to create a monolithic structure. In contrast, when humans need to be organized, Conway’s Law should be a significant factor in decision making.
Dealing with Conway’s Law requires accepting it rather than fighting against it.
As an example: If you have seven teams in different cities worldwide, recognizing the impact of location on human communication and accounting for it in your technical design would translate into having seven major subsystems, recognizing that components developed in different time-zones needed to have limited and well-defined interactions.
Should you design teams around your product life-cycle?
Conway’s Law is not only limited to issues with communication structure, but it can also lead to a common mismatch between Activity-Oriented team organizations and feature development. When teams are organized by software layer or life-cycle activity, it can create a lack of collaboration between teams responsible for different parts of the system, leading to delays in delivering a feature to production.
The Inverse Conway Maneuver
However, over the last decade, a third way of responding to Conway’s Law has emerged. This approach is called the Inverse Conway Maneuver and involves deliberately altering the development team’s organizational structure to encourage the desired software architecture. The idea is to build small, long-lived Business Capability Centric teams that contain all the skills necessary to deliver customer value. By organizing autonomous teams in this way, Conway’s Law can be employed to promote similarly autonomous services that can be enhanced and deployed independently of each other.
The Inverse Conway Maneuver has been particularly effective in the realm of microservices architecture. In this approach, microservices are considered primarily as a tool for structuring a development organization. By organizing teams around business capabilities and creating autonomous services, developers can build, test, and deploy independently, without needing to coordinate with other teams. This allows for greater agility in responding to changing customer needs and market conditions.
This approach has been gaining traction in recent years, particularly among companies that rely heavily on software development for their operations. The success of the Inverse Conway Maneuver hinges on the ability of development teams to communicate effectively and collaborate on the delivery of customer value.
Responses in organizational design to Conway’s law
| Response | Description |
|---|---|
| Ignore | Don’t take Conway’s Law into account, because you’ve never heard of it, or you don’t think it applies (narrator: it does) |
| Accept | Recognize the impact of Conway’s Law, and ensure your architecture doesn’t clash with designers’ communication patterns. |
| Inverse Conway Maneuver | Change the communication patterns of the designers to encourage the desired software architecture. |
Conway’s Law emphasizes the importance of concurrently designing the system’s modular structure and the development team’s organization. This process isn’t a one-time event, but rather an ongoing process that involves continuously evolving the architecture and restructuring the human organization throughout the enterprise’s lifespan.
Conway’s Law in action
The way a company is structured and communicates internally will inevitably have a significant impact on the design of the software they produce. Let’s explore various examples of Conway’s Law in action.
- Unix. One classic example of Conway’s Law in action is the development of the operating system Unix. Unix was developed by a group of programmers at Bell Labs in the 1960s and 1970s. The group was organized into small, autonomous teams that were responsible for different parts of the operating system. As a result, Unix ended up being a modular system made up of many small components that could be easily combined to form larger applications. This modularity and flexibility were a direct result of the way the development team was organized.
- AWS. Another example of Conway’s Law in action is the development of Amazon Web Services (AWS). AWS is a cloud computing platform that was developed by Amazon in the early 2000s. Amazon was already a well-established e-commerce company at the time, and their internal communication structures were built around the concept of services. Each team was responsible for a specific service, such as the shopping cart or the payment system. When Amazon decided to build a cloud computing platform, they used the same organizational structure, with each team responsible for a specific service. As a result, AWS is made up of many small services that can be easily combined to form larger applications.
- Linux. Unlike the Unix and AWS examples, there was no formal organizational structure in place for the development of Linux. Instead, the project was structured around the code itself. Developers would submit patches to the codebase, and its founder, Linus Torvalds, would review and merge them. As a result, Linux ended up being a highly modular system with a large number of contributors.
Despite these differences in organizational structure, all of these examples demonstrate how Conway’s Law can have a significant impact on the design of software systems. In each case, the software ended up being modular and flexible, which allowed it to be easily adapted to changing requirements. This modularity and flexibility were a direct result of the way the development team was organized.
There are also examples of Conway’s Law having negative impacts on software design. For example, if a company’s organizational structure is hierarchical and siloed, it may lead to a software system that is overly complex and difficult to maintain. Similarly, if a company’s communication structures are weak, it may lead to a software system that is poorly documented and difficult to understand.
Examples
Unix
Unix was developed by a group of programmers at Bell Labs in the 1960s and 1970s. The group was organized into small, autonomous teams that were responsible for different parts of the operating system. As a result, Unix ended up being a modular system made up of many small components that could be easily combined to form larger applications. This modularity and flexibility were a direct result of the way the development team was organized.
Amazon Web Services (AWS)
Amazon’s internal communication structures was built around the concept of services. Each team was responsible for a specific service, such as the shopping cart or the payment system and when Amazon decided to build a cloud computing platform, they used the same organizational structure, with each team responsible for a specific service. As a result, AWS is made up of many small services that can be easily combined to form larger applications.
-
What is the purpose of applying Conways Law?
Hint The purpose of applying Conways Law is to ensure that the structure of the organization reflects the structure of the system being developed. -
How will Conways Law help to improve the current system?
Hint Conways Law can help to improve the current system by ensuring that the organization is structured in a way that is conducive to the development of the system. This can help to reduce complexity and improve communication between team members. -
What are the potential risks associated with applying Conways Law?
Hint The potential risks associated with applying Conways Law include the potential for increased complexity and a lack of flexibility in the system. -
What are the potential benefits of applying Conways Law?
Hint The potential benefits of applying Conways Law include improved communication between team members, increased efficiency, and improved system architecture. -
How will the application of Conways Law affect the team dynamics?
Hint The application of Conways Law can affect the team dynamics by creating a more structured environment and encouraging collaboration between team members. -
What are the potential challenges that may arise from applying Conways Law?
Hint The potential challenges that may arise from applying Conways Law include the need to adjust the organization structure to accommodate the system architecture, and the need to ensure that team members are aware of the implications of the law. -
How will the application of Conways Law affect the overall system architecture?
Hint The application of Conways Law can affect the overall system architecture by ensuring that the organization structure reflects the system architecture. This can help to reduce complexity and improve communication between team members. -
What are the potential implications of applying Conways Law?
Hint The potential implications of applying Conways Law include improved communication between team members, increased efficiency, and improved system architecture. -
How will the application of Conways Law affect the timeline of the project?
Hint The application of Conways Law can affect the timeline of the project by ensuring that the organization structure is in line with the system architecture. This can help to reduce complexity and improve communication between team members. -
What are the potential longterm effects of applying Conways Law?
Hint The potential long-term effects of applying Conways Law include improved communication between team members, increased efficiency, and improved system architecture.
You might also be interested in reading up on:
- David Heinemeier Hansson @dhh
- Martin Fowler @martinfowler
- Kent Beck @kentbeck
- Robert C. Martin @unclebobmartin
- Eric Evans @ericevans0
- Conway's Law by Melvin Conway (1968)
- Kanban: Successful Evolutionary Change for Your Technology Business by David J. Anderson (2010)
- Team Topologies: Organizing Business and Technology Teams for Fast Flow by Manuel Pais and Matthew Skelton (2019)
- Leading Lean Software Development: Results Are Not the Point by Mary Poppendieck (2009)
- Peopleware: Productive Projects and Teams by Tom DeMarco (1999)
Want to learn more?
Receive a hand picked list of the best reads on building products that matter every week. Curated by Anders Toxboe. Published every Tuesday.
No spam! Unsubscribe with a single click at any time.
Community events
Product Loop
Product Loop provides an opportunity for Product professionals and their peers to exchange ideas and experiences about Product Design, Development and Management, Business Modelling, Metrics, User Experience and all the other things that get us excited.
Join our communityMade with in Copenhagen, Denmark
Want to learn more about about good product development, then browse our product playbooks.