“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.” – Melvin Conway
Conway’s Law is a principle in software engineering and organizational theory that suggests that the structure of a software system is inherently tied to the communication structures of the organization that develops it. The law is named after Melvin Conway, who introduced the idea in 1967.
Conway’s Law implies that the way a team or organization is structured and communicates will influence the design and architecture of the software they develop. This means that if a team is organized into separate departments or teams, the software they build may end up being divided into separate components that correspond to those teams, even if such division might not be the most logical from a technical standpoint.
For example, if a company has separate teams for frontend and backend development, their software architecture might naturally reflect this separation, resulting in a frontend that’s tightly integrated with the corresponding backend components developed by different teams.
Conway’s Law has important implications for software development methodologies, team organization, and communication strategies. Teams that want to achieve a specific software architecture might need to reevaluate their organizational structure and communication patterns to ensure they align with their architectural goals. Conversely, changes in the software architecture might necessitate adjustments in the way teams are organized and communicate.
In essence, Conway’s Law serves as a reminder that the interactions and dynamics within a development team can have a significant impact on the quality, modularity, and maintainability of the software they produce.
So what can you do to ensure your team has the communication structure in place to reflect the products you want to build?
1. Observe the current team structure and how team members communicate. Also, observe the dependencies and the design of the software.
2. Explore the opportunities to form cross functional teams with minimal dependencies.
3. Encourage the team members to acquire the skills that they depend on from the external team or explore the opportunity to bring in a team member with the skulls that are missing on the team.
How Coveros Can Help
Looking to make cultural or organizational structures that enhance delivery? We’d love to chat about your current challenges and opportunities and how our experts can help.
