Learning Loop Playbooks Learning Loop

Engineering, Product management

Conway's Law

The structure of a system is determined by the structure of the organization that created it.

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, Team Topology

Relevant metrics: Productivity, Team Collaboration, Time to Market, Quality of Deliverables, and Customer Satisfaction

In this article

What is Conway’s Law?

Conway’s Law states that the structure of a system will mirror the communication patterns of the people who design it. In simpler terms, the way teams communicate and collaborate directly impacts how the system or product is organized. For example, if development teams are divided into separate groups, the product is likely to be built as independent components that reflect these divisions.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” – Melvin Conway, 1968

Conway’s Law emphasizes the importance of effective communication and collaboration between product managers, designers, and developers in shaping a user-focused product. By understanding this principle, product teams can better align their processes and structures to avoid the pitfalls of disjointed product development.

Where did Conway’s Law come from?

Conway’s Law was first introduced by Melvin Conway in his 1968 article, “How Do Committees Invent?”. He noted that an organization’s structure and communication dynamics inherently influence the design of the systems they build. Later reflections on his work, such as in the book Team Topologies (2019), suggest another critical aspect:

“Is there a better design that is not available to us because of our organization?” – Melvin Conway

This prompts organizations to consider how their internal structures may be limiting innovation. Ruth Malan, a prominent figure in software architecture, also builds on Conway’s insight:

“If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.”

This underscores the idea that an organization’s setup often dictates what can be achieved in software design. It raises the need to evaluate whether the current organizational structure fosters or hinders effective and innovative product architecture.

How organizational structure shapes software development

Conway’s Law is often used to explain why certain software projects fail. When an organization’s structure does not promote collaboration between teams, the resulting software will reflect this fragmentation. For example, if the teams are siloed (e.g., frontend, backend, and testing teams working in isolation), the product may end up as a set of loosely connected modules that don’t integrate well, leading to a poor user experience.

This is why merely focusing on technical aspects without considering organizational structure can result in system architectures that are mismatched and difficult to maintain.

Conversely, projects where the organization fosters strong communication and collaboration are more likely to succeed. Cross-functional teams aligned around product features can build a more cohesive and user-friendly system. When a team shares a common understanding of the product vision, the software architecture reflects this unity, resulting in a product that is both adaptable and scalable.

Designing teams for low software coupling

Effective communication among developers, designers, and product managers leads to an implicit understanding of the system, reducing unnecessary code coupling. When there is a shared way of thinking about the problem domain, interactions between code modules can be managed more effectively.

Ignoring Conway’s Law can lead to system architectures that don’t align with the natural flow of communication, causing friction between teams. For instance, if a product has several components developed by geographically dispersed teams, those components will likely need well-defined interfaces and minimal interdependence. Without this alignment, miscommunication and missed design opportunities can occur, leading to technical issues and reduced collaboration.

“Software coupling is enabled and encouraged by human communication.” – Melvin Conway

Team size and communication frequency also play a role. Smaller teams that communicate frequently and informally tend to create monolithic structures. In contrast, larger, more structured teams, especially those across different time zones or locations, tend to build more modular systems with clear interfaces.

Should you design teams around your product lifecycle?

A more proactive approach to Conway’s Law is the “Inverse Conway Maneuver.” This strategy involves deliberately designing team structures to shape the desired software architecture. Instead of letting the organizational setup dictate the system design, you reorganize teams around business capabilities and desired architectural outcomes. This tactic gained traction around 2015 and has been endorsed by studies like those in the book Accelerate: The Science of DevOps:

“Organizations should evolve their team and organizational structure to achieve the desired architecture. The goal is for your architecture to support the ability of teams to get their work done — from design through to deployment — without requiring high-bandwidth communication between teams.”

Organizing teams around business capabilities or features can foster better collaboration, reduce dependencies, and speed up development. To explore more about effective team organization, refer to team topologies.

Applying the Inverse Conway Maneuver means creating small, cross-functional, long-lived teams with end-to-end ownership of specific business capabilities. By doing so, you create autonomous services that can evolve independently, supporting fast flow and innovation.

Responses to Conway’s Law in organizational design

Response Description
Ignore Proceed without considering Conway’s Law, leading to misaligned software structures that reflect the communication gaps in the organization.
Accept Acknowledge the impact of Conway’s Law and design the architecture in alignment with existing communication patterns.
Inverse Conway Maneuver Proactively change the team structures to influence and shape the software architecture in the desired way.

Conway’s Law emphasizes the need to design both the system architecture and the team structure concurrently. This isn’t a one-time task; it’s an ongoing process that requires continuous refinement as the organization and its products evolve.

When an organization is hierarchical and siloed, the software it produces often becomes overly complex and difficult to maintain. For example, if communication structures are weak, the resulting system might suffer from poor documentation, convoluted interfaces, and fragile integrations. This is why designing your teams in line with your desired system architecture is crucial to success.

Conway’s Law shows that the structure of your teams and the ways they communicate have a direct impact on your product’s architecture and quality. Product managers, tech founders, and leaders should design team structures, choose communication tools, and define collaboration practices with this principle in mind.

By understanding and leveraging Conway’s Law, you can shape a product that is modular, cohesive, and adaptable, ultimately ensuring that the system’s design aligns with both the organization’s goals and user needs.

Why can it be hard to innovate?

Innovation is challenging because the current team structures and their communication patterns may limit the scope of possible designs. As Conway stated:

“Given any team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist.”

These “communication paths” are the interactions between teams and engineers. Formal reporting lines and inter-team boundaries can restrict innovative solutions and perspectives.

Strategies to enable change

To encourage a new software architecture, the organization must reconfigure how teams communicate before building the software. One strategy is to facilitate temporary collaboration modes between teams and “enabling teams” that operate in a facilitating role. This way, any problems with new boundaries can be identified and adjusted early in the process.

Conway’s Law underscores that a well-designed architecture should resemble the flows of change it enables. To facilitate this:

  • Loose Coupling: Components should have minimal dependencies on each other.
  • High Cohesion: Components should have clearly defined responsibilities and closely related internal elements.
  • Clear Version Compatibility and Testing: Establish processes for cross-team testing and version management.

By designing teams around these principles, you create a team-first architecture that supports fast flow, autonomy, and accountability. However, a new architecture won’t emerge instantly after a team structure change. Existing software architectures often “push back” against new team structures, so ongoing effort and strategic collaboration are essential.

The Team Topologies book outlines key interaction modes to help define an effective organizational design:

  • Collaboration: Working closely with another team to achieve a common goal.
  • X-as-a-Service: Consuming or providing services with minimal direct collaboration.
  • Facilitating: Helping or being helped by another team to clear impediments.

Understanding these interaction modes can help create an initial team design that aligns with the desired software architecture.

Frequently Asked Questions

How does Conway’s Law relate to Agile software development?

Conway’s Law aligns closely with Agile software development principles, which emphasize collaboration, cross-functional teams, and iterative delivery. In Agile, teams are designed to be self-organizing and empowered to make decisions quickly. This structure naturally encourages communication and cooperation within the team, leading to software architectures that reflect these collaborative patterns.

Agile methodologies, such as Scrum and Kanban, break down silos by creating cross-functional teams responsible for delivering end-to-end features. When teams own entire product features or modules, the software’s architecture tends to become more modular and cohesive, reflecting the close communication within these small, focused groups. Additionally, Agile promotes continuous feedback loops, which means that the software is frequently adapted and improved based on user feedback, customer needs, and team insights. This ongoing process encourages software designs that are flexible and user-centric.

However, if an organization adopts Agile without considering Conway’s Law, problems can arise. For example, if Agile teams are still siloed by function (e.g., separate frontend, backend, and testing teams), the software might end up fragmented, reflecting these divisions. To align Agile practices with Conway’s Law, organizations should focus on creating small, cross-functional teams that work together on features or business capabilities, mirroring the desired architecture in their communication patterns.

How does Conway’s Law relate to the design of microservices?

Conway’s Law has a direct impact on the design of microservices architectures. Microservices are built around small, self-contained services that can be developed, deployed, and scaled independently. This design principle reflects the communication structures of autonomous, cross-functional teams. When organizations structure their teams around business capabilities, each team becomes responsible for a specific microservice or a set of microservices, which often leads to a cleaner, more modular software architecture.

In practice, implementing microservices requires that teams have clear ownership of their respective services and that inter-service communication is managed effectively. If teams are not structured correctly—for example, if they are siloed by technical specialties rather than business domains—microservices can become overly complex, with tightly coupled dependencies that are difficult to manage. This is a violation of Conway’s Law and leads to a tangled web of services that are hard to maintain and scale.

By structuring teams to align with microservices’ desired architecture, organizations can take advantage of Conway’s Law to promote autonomous, loosely coupled services. This enables teams to iterate quickly, improve deployment processes, and independently adapt to changing requirements without affecting other parts of the system.

How does Conway’s Law relate to User Experience (UX) design?

Conway’s Law extends beyond technical architecture to influence the user experience of a product. If a product team is fragmented into isolated departments (e.g., design, development, and testing operating separately), the final user experience is likely to feel disconnected and inconsistent. This is because the communication gaps between these departments often result in misaligned design elements, fragmented workflows, and inconsistencies in how the product interacts with users.

To create a cohesive user experience, it’s important to have cross-functional teams that include designers, developers, and product managers working closely together. By aligning team communication with the desired user experience, the product design will naturally become more consistent and user-friendly. For instance, if the goal is to create a seamless end-to-end user journey, the team working on that journey needs to collaborate effectively throughout the entire design and development process.

In short, the way teams are structured and how they communicate directly shapes the user experience. When designers, developers, and product managers operate within a unified, collaborative framework, they can create a product that reflects a well-thought-out and integrated user experience.

How can we practically transition from our current team structure to one that aligns with our desired software architecture?

Transitioning to a new team structure is a gradual and deliberate process that requires strategic planning. Here are some practical steps to guide this transition:

  1. Assess current state Begin by mapping your current team structures, communication patterns, and software architecture. Identify the areas where the current organization might be misaligned with the desired software architecture.

  2. Define the target architecture Clearly define the software architecture you want to achieve, focusing on business capabilities, modularity, and flexibility.

  3. Design the new team structure Organize teams around business capabilities or features, ensuring that each team has cross-functional expertise (e.g., product managers, developers, UX designers, QA). The goal is to have teams that can own their part of the system end-to-end.

  4. Create communication pathways Set up formal and informal communication channels that align with the new architecture. Regularly hold meetings and reviews that encourage cross-team collaboration.

  5. Start with pilot teams Introduce the new structure with a small subset of teams as a pilot. This allows you to experiment, identify issues, and refine processes before a broader rollout.

  6. Monitor and adapt Use feedback and metrics to assess how well the new team structure is working. Be prepared to iterate on team composition, communication practices, and collaboration tools to better align with the desired architecture.

  7. Address cultural changes This transition often requires a cultural shift towards more collaborative and autonomous ways of working. Leadership should encourage open communication and support teams in taking ownership of their services or product features.

What are the common pitfalls when attempting to implement the Inverse Conway Maneuver, and how can we avoid them?

Common pitfalls when implementing the Inverse Conway Maneuver include:

  • Lack of clear vision Without a clear understanding of the desired software architecture, reorganizing teams can lead to confusion and misalignment. To avoid this, define the target architecture in detail before restructuring.

  • Insufficient communication During the transition, communication gaps can arise if teams are not adequately informed about changes. Maintain open lines of communication throughout the process to ensure everyone understands the new team structure and goals.

  • Resistance to change Team members and managers may resist changes due to uncertainty or discomfort with new roles and workflows. Overcome this by involving teams in the planning process, explaining the benefits of the change, and providing training and support.

  • Overlooking existing dependencies Existing technical dependencies between systems can hinder the desired modular architecture. Before restructuring, identify and address these dependencies through refactoring, API development, or establishing integration protocols.

  • No iteration Attempting a “big bang” transformation can overwhelm teams. Instead, iteratively apply the changes, starting with small experiments, and continuously adapt based on feedback.

How long does it typically take for the benefits of the Inverse Conway Maneuver to become apparent?

The time frame for seeing the benefits of the Inverse Conway Maneuver varies depending on the organization’s size, complexity, and the degree of change required. For small to mid-sized organizations, noticeable improvements can often be seen within 3 to 6 months, particularly in team collaboration, development speed, and reduced technical debt.

In larger enterprises, where multiple layers of management and legacy systems are involved, the process can take longer—often 12 to 24 months—to see significant shifts in both team dynamics and software architecture. Regardless of organization size, incremental changes and continuous feedback are key. It’s common for initial challenges and resistance to arise, but as teams adapt to their new structures and communication patterns, the benefits of improved alignment, autonomy, and faster flow of work become evident.

What specific challenges should we anticipate when attempting to realign our team structures with a new software architecture?

Key challenges include:

  • Dealing with legacy systems Legacy systems often reflect the historical communication patterns and are tightly coupled, making it difficult to fit into the new modular architecture. This may require extensive refactoring or rewriting to align with the new team structure.

  • Managing dependencies Existing dependencies between teams and software components can slow down the transition. Establishing well-defined interfaces and APIs can help manage these dependencies during and after the reorganization.

  • Cultural resistance Shifting team structures can meet cultural resistance as people are pushed out of their comfort zones. Encouraging a culture of experimentation, learning, and open communication is crucial to overcoming this challenge.

  • Maintaining productivity During the transition, productivity may temporarily dip as teams adjust to new ways of working. Setting realistic expectations, monitoring progress, and offering support can mitigate this impact.

Are there situations where the Inverse Conway Maneuver is not advisable, and how can we recognize those scenarios?

The Inverse Conway Maneuver may not be advisable in the following situations:

  • Highly regulated environments In industries with strict regulatory requirements (e.g., healthcare, finance), changing team structures and software architectures may introduce compliance risks. In such cases, changes need to be carefully planned and aligned with regulatory standards.

  • Extensive legacy systems When an organization relies heavily on complex legacy systems that are difficult to modify, implementing a new team structure may not be practical without first addressing technical debt. A gradual approach that includes refactoring legacy systems might be more effective.

  • Lack of clear architectural vision If the organization does not have a well-defined target architecture, attempting the Inverse Conway Maneuver can lead to confusion and misalignment. Clear goals and architectural guidelines are prerequisites for this strategy to succeed.

  • Cultural resistance to change If there is significant resistance within the organization to adopting new team structures or ways of working, forcing a change could be counterproductive. In such cases, it may be better to work on building a more collaborative culture first.

As our organization scales, how can we ensure our team structures and software architecture remain aligned?

As an organization grows, it’s crucial to continuously assess and adapt both team structures and software architecture. Here are some practices to consider:

  • Regular reviews Conduct periodic reviews of team topologies and communication patterns to identify any misalignment with the software architecture.

  • Use metrics Monitor key metrics such as deployment frequency, cycle time, and incident rates to gauge how well the architecture supports team workflows.

  • Flexible team structures Maintain flexibility in team structures by avoiding rigid silos. Adopt a dynamic model where teams can reorganize around emerging business needs and changing product requirements.

  • Promote cross-team collaboration Encourage cross-team collaboration through shared goals, open communication channels, and regular cross-functional meetings to maintain alignment.

  • Architectural guardrails Establish architectural principles and guidelines that act as guardrails, helping teams make decisions that align with the desired system design.

Are there established methodologies (Agile, Lean, etc.) that naturally align with Conway’s Law and the Inverse Conway Maneuver?

Yes, several methodologies align with Conway’s Law and the principles of the Inverse Conway Maneuver:

  • Agile Agile’s emphasis on cross-functional teams and iterative development naturally aligns with Conway’s Law. By structuring teams around features or business capabilities, Agile supports the creation of modular, flexible software architectures.

  • Lean Lean principles, such as reducing waste and promoting continuous improvement, encourage breaking down silos and enhancing communication flows. This supports team structures that align with efficient software design.

  • DevOps DevOps practices, such as continuous integration and continuous deployment (CI/CD), foster collaboration between development and operations. This collaboration often leads to service-oriented architectures that reflect the communication and workflows between integrated DevOps teams.

  • Domain-Driven Design (DDD) DDD involves dividing the system into bounded contexts, each managed by a dedicated team. This aligns with Conway’s Law by structuring teams around specific business domains, promoting modular software design.

What practices should we put in place to continuously evaluate and adapt team structures as the company evolves?

To ensure ongoing alignment, implement these practices:

  • Retrospectives Conduct regular retrospectives within and across teams to assess current structures, workflows, and communication patterns. Use insights from these retrospectives to adjust team configurations as needed.

  • Cross-functional reviews Hold periodic cross-functional reviews to discuss the alignment between team structures and software architecture. Involve stakeholders from various departments, including product, design, engineering, and operations.

  • Feedback loops Establish feedback mechanisms that allow teams to provide input on organizational changes and their impact on software development.

  • Metrics tracking Track key metrics such as deployment frequency, lead time, and defect rates to identify areas where misalignment may be affecting productivity or quality.

  • Management support Encourage management to actively support changes in team topologies by providing resources, removing obstacles, and fostering a culture of continuous improvement.

How should organizations deal with legacy systems that don’t align with current or future team topologies?

Dealing with legacy systems requires a strategic approach to gradually transition towards the desired architecture:

  • Assess and prioritize Start by identifying the most critical legacy systems and prioritize them based on business impact, technical debt, and alignment with future goals.

  • Introduce facade patterns Use architectural patterns like the “facade” or “adapter” to create interfaces around legacy systems, allowing new systems to interact without directly coupling to the old architecture.

  • Incremental refactoring Rather than a complete rewrite, break the legacy system into smaller components. This involves refactoring one part at a time and gradually aligning the software with the new team topologies.

  • Enabling teams Create enabling teams that specialize in refactoring legacy code and work alongside product teams to support the transition. These teams can provide guidance and tools to facilitate the migration.

  • Short-term collaboration modes Use short-term collaboration between new and existing teams to transfer knowledge and address integration challenges during the transition.

How does Conway’s Law apply in businesses with non-software products?

While Conway’s Law is most commonly referenced in software development, its principles apply to any organization that creates complex systems or products. In non-software businesses, Conway’s Law implies that the way teams are structured will influence product design, manufacturing processes, and customer experiences.

For example, in a hardware company, if design, engineering, and manufacturing teams are siloed, the final product might suffer from design flaws that could have been avoided with more integrated communication. Conversely, if cross-functional teams are established (e.g., combining design, engineering, and quality assurance), products are likely to be more cohesive and better aligned with market needs.

In service-oriented businesses, the organizational structure and communication patterns can impact the design of customer experiences. For instance, if marketing, sales, and customer support operate in isolation, the service offering may feel fragmented to customers. Aligning team structures around customer journeys or service touchpoints ensures a more seamless and consistent customer experience.

In summary, regardless of the industry, Conway’s Law highlights the importance of aligning team structures with desired outcomes, ensuring that the organization can deliver products and services effectively and coherently.

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.

Microsoft Windows

The development of Microsoft Windows historically reflected the internal organization of Microsoft. Different teams within Microsoft were responsible for different components of the operating system, such as the file system, user interface, networking, and more. As a result, older versions of Windows, especially around the 1990s and early 2000s, had a modular structure with a wide range of features that sometimes appeared fragmented or inconsistent. Features and modules within Windows often mirrored the internal boundaries between teams. This led to challenges in integration, inconsistencies in user interface design, and occasional issues with performance and reliability.

Spotify's Feature Squads

Spotify’s development model, known as the “Spotify Model,” uses autonomous “squads,” each responsible for different features or aspects of the product, such as the music recommendation engine, playlist management, or the mobile app interface. Each squad operates like a mini-startup within the company, with its own goals and roadmaps. This structure has led to a product design where various features and components of Spotify function relatively independently. While it allows for fast development and iteration, it sometimes results in varied user experiences across different parts of the platform due to the unique approaches taken by each squad.

Facebook's Early Social Features (Meta)

In its early years, Facebook’s product reflected the organizational structure, where different teams worked on separate features like messaging, photos, news feed, and advertising. Each team developed its component with some degree of autonomy, leading to a fragmented user experience. Features often had different interfaces and interaction models, reflecting the lack of unified design standards across the company’s various development teams. Over time, Facebook has made efforts to integrate these elements into a more cohesive platform, but remnants of the original structure-influenced design can still be seen.

Nokia's Mobile Phone Product Line

Before the smartphone era, Nokia was organized into separate divisions, each responsible for different types of mobile devices, such as basic phones, feature phones, and high-end devices. Each division had its own design, software, and development teams. This structure led to a diverse product lineup with numerous models, often with different operating systems (e.g., Series 40, Symbian). The fragmented approach to product development eventually made it difficult for Nokia to transition into the unified smartphone market, contributing to its decline in the face of competition from more integrated platforms like iOS and Android.

IBM Mainframe Systems (IBM)

IBM’s organizational structure in the early days of computing led to the creation of monolithic mainframe systems. Different departments within IBM focused on specific parts of the product, such as hardware, operating systems, and applications. This resulted in mainframe products that were complex and tightly integrated, mirroring the company’s segmented internal structure. While this worked well for large-scale enterprises requiring tailored solutions, it made IBM’s products less flexible and more challenging to adapt in an era that shifted toward more modular, user-friendly computing systems.

Google's Alphabet Restructuring (Google/Alphabet)

When Google restructured into Alphabet Inc., it allowed different product lines (such as Google Search, YouTube, Waymo, and others) to operate more independently, with each unit functioning as a separate company. This organizational structure led to products that are largely independent of one another in terms of design, function, and business model. For example, while Google Search and YouTube share some integration, they also have distinct user interfaces and features, reflecting the semi-autonomous nature of their development teams.

Relevant questions to ask
  • How is the product development team structured?
    Hint A cross-functional team structure might lead to more integrated products, while siloed teams could result in fragmented product features. Distributed teams might introduce challenges in maintaining unified design. Are you structured as cross-functional teams with clear product ownership? As siloed functional teams (e.g., separate design, engineering, and testing departments)? As distributed teams across different geographical locations.
  • What are the main communication channels between teams?
    Hint Frequent and open communication channels often result in a cohesive product design. Limited communication can lead to isolated modules or inconsistencies. Are you doing regular stand-ups, do you use digital collaboration tools, do you have occasional inter-departmental meetings (or emails), do you use documentation tools (e.g., Confluence) with limited direct communication?
  • How often do teams collaborate on product decisions?
    Hint Regular collaboration supports a unified product vision. Infrequent or milestone-based collaboration may cause misalignment in design and functionality. Daily, weekly, monthly? Or only during key milestones and product launches?
  • Are there formal processes for cross-team collaboration?
    Hint Formal collaboration processes can help align product design with customer needs. Lack of structured collaboration might result in a product that reflects internal structures rather than user requirements.
  • How is decision-making authority distributed across teams?
    Hint Collaborative decision-making encourages holistic product design, while highly autonomous teams may create disjointed features. Centralized decision-making can sometimes disconnect the product from user requirements if not managed carefully.
  • Is there a shared understanding of the product vision among teams?
    Hint A shared understanding of the product vision fosters a cohesive design. A lack of alignment can result in a product that feels fragmented or inconsistent.
  • How does the organization handle dependencies between teams?
    Hint Proper dependency management leads to a more integrated product. Poor management can cause delays, miscommunication, or fragmented product development.
  • How is customer feedback integrated into the product development process?
    Hint Regularly incorporating customer feedback helps ensure that the product reflects user needs rather than internal team structures. Infrequent consideration of feedback might result in a product that aligns more with internal processes than customer expectations.
  • What are the common communication challenges between teams?
    Hint Identifying communication challenges is crucial for addressing Conway's Law implications. Resolving these issues can lead to a product design that better aligns with customer needs rather than organizational constraints.
  • How adaptable is the current team structure to changes in product requirements?
    Hint An adaptable team structure can shift focus based on evolving product needs, reducing the risk of the product design being overly influenced by the current organizational structure.

You might also be interested in reading up on:

People who talk about the topic of Conway's Law on Twitter
Relevant books on the topic of Conway's Law
  • 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 community

Made with in Copenhagen, Denmark

Want to learn more about about good product development, then browse our product playbooks.