Have you ever read Conway's law before:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
— Melvin E. Conway, How Do Committees Invent?
And considered how it relates to your experience upon entering a new organization and seeing its entire architecture? We will explore the different levels where Conway's law impacts and how to mitigate its effects if desired.
Conway's Law & Alternatives
The Status Quo (Conway's Law)
Conway's Law, proposed by Melvin Conway in 1967, has withstood the test of time. It asserts that a system's design will mirror the structure of the organization that designed it. In other words, if a company has independent teams, the final product will likely consist of distinct components that function independently. Understanding this law can help organizations predict their system architecture based on their internal structure.
If we let Conway's law take the lead, regardless of our system design knowledge, the outcome may not meet our expectations, as we'll see in various layers where Conway's law can influence.
The Other Side (Inverse Conway Maneuver)
The Inverse Conway Maneuver is a method of restructuring an organization to align better with the desired system architecture, which involves intentionally restructuring the organization to match the desired system architecture. This process can be challenging and disruptive, but it can lead to a more efficient and effective organization.
Key steps to successfully implementing the Inverse Conway Maneuver include:
Define the desired system architecture. This should align with the organization's goals and objectives.
Analyze the current organizational structure. Identify where the current structure does not align with the desired system architecture.
Develop a restructuring plan. This plan should include a timeline and a communication strategy.
Implement the plan. This should be done in phases to minimize disruption.
Monitor the results. Track the restructuring progress and make adjustments as needed.
Middle Ground (User-Centric Conway Maneuver)
Conventionally, profitable software is based on user needs. Many organizations claim to be user-centric but fail to organize around them. User-centric Conway Maneuver involves focusing on our client's process and needs, which will impact the organizational structure and systems architecture.
Key steps to successfully implementing the User-Centric Conway Maneuver include:
Understand your Target User. This should align with the organization's goals and objectives.
Analyze the current organizational structure. Identify where the current structure does not align with the desired system architecture.
Analyze the current architecture. Identify where the current structure does not align with the desired system architecture.
Develop a restructuring plan. This plan should include a timeline and a communication strategy.
Implement the plan. This should be done in phases to minimize disruption.
Monitor the results. Track the restructuring progress and make adjustments as needed.
⚠️ Note that any transformation is complex and challenging and should only be undertaken with careful planning and execution
Layers of Influence
Conway's Law is not just about high-level architecture; it influences various facets of system design and team collaboration. Here, we detail the layers where Conway's law manifests:
Global Architecture
At the Global Architecture level, Conway's Law suggests that the technical and non-technical organization definitions can affect your high-level architecture. Let's look at some examples:
Non-technical departments: In a company with separate marketing and operations departments, the marketing department is likely the primary stakeholder for systems related to the customer funnel, while the operations department is likely the primary stakeholder for systems related to customer care. If there is no communication between departments, your company might make promises it can't keep, or provide a poor customer experience.
Technical departments: In a company with technical organizational departments where horizontals exist, your teams will reflect that structure. If not careful, you might implement very similar functionalities or overwhelm other teams with too many requirements.
Product Architecture
In the context of a User-Centric Conway Maneuver, the product architecture level requires you to focus on how the various teams collaborate to deliver a product that fulfills user needs. You need to assess how the teams are structured and how their communication patterns align with the user journey you have defined.
For instance, if you have separate teams for front-end and back-end development, you may need to foster better communication and collaboration between these teams to ensure that your product provides a seamless user experience. This could involve regular cross-team meetings, joint planning sessions, or even restructuring teams to be cross-functional.
Your architecture may have to evolve to support this more integrated approach. For example, you may decide to use a full-stack development approach where each team is responsible for both front-end and back-end development for a certain part of the user journey. This can lead to a product architecture that is more aligned with the user's needs and can adapt more quickly to changes in those needs.
Code Architecture
At the code level, the User-Centric Conway Maneuver involves considering how the communication and collaboration styles of individual team members can influence the design of system components. This is where the understanding of your target user and their journey can guide the design of individual features or components.
If a developer tends to work in isolation on a feature, this could result in a component that does not integrate well with the rest of the system or does not meet user needs effectively. To address this, you may need to encourage more collaboration and communication within your team.
For instance, you could use pair programming or code reviews to ensure that all team members have input into feature development. This can lead to code architecture that is more cohesive and adaptable, and that better reflects the needs of the user.
Remember, these are just examples, and your actual actions will depend on the specific needs and structure of your organization.
User-Centric Conway Maneuver Action Plan
You should now be aware that Conway's law can impact your organization unconsciously. Based on our multi-layered view, let's focus on the user-centric Conway maneuver:
Global Architecture
In this layer, you need to know what your business value is for your users to align to it, as it will likely change the least after you achieve a product-market fit. This knowledge can fuel your organizational and architectural changes. The knowledge required is not technical, but you should at least have defined your target user and their journey.
After defining these models, we will understand the business better, and we can map some new knowledge to reorganize and re-architect. Some possible actions from the examples we saw in the previous section:
Reorganize Non-technical departments: If there is no communication between marketing and operations, they need to work closer. This could involve having weekly syncs or a common leadership/organization, so their objectives are aligned.
Technical departments: In the case of horizontal slicing, moving to a more user-centric environment could reorganize teams to be multifunctional and value stream aligned.
Product Architecture
In the context of a User-Centric Conway Maneuver, the product architecture level requires a focus on how the various teams collaborate to deliver a product that fulfills user needs. This could involve regular cross-team meetings, joint planning sessions, or even restructuring teams to be more cross-functional.
Code Architecture
At the code level, the User-Centric Conway Maneuver involves considering how the communication and collaboration styles of individual team members can influence the design of system components. This is where understanding of your target user and their journey can guide the design of individual features or components.
Conclusion
In conclusion, Conway's Law provides valuable insight into how an organization's structure can impact the design of its systems. While the experience and skill of your hires certainly contribute to the quality of work, the architecture of the systems you develop will be significantly influenced by your organizational communication patterns. Hence, you will have to apply the maneuver or none depending on if you accept, mitigate, or want to pivot on the tradeoffs.