Decoding Conway's Law: Is Your Company Structured for Success?

There's a phrase attributed to a well-known Argentinian politician that states:

If you want something not to get done, create a committee.?

Conway's Law in Action

Coincidentally enough, between that politician's periods in office, a programmer named Melvin E. Conway published a paper titled "How Do Committees Invent?" whose most remarkable feature is now called Conway's law:

Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.

Let's unpack that.

Have you ever seen a busy home page that looked like the result of a power struggle between business units?

That's Conway's law at play.

Have you experienced software development teams bottlenecked by waiting on each other? Or building services whose names resemble their inner workings rather than the domain boundaries of the business model? That's probably because they are playing against Conway's law.??

Subconsciously -or not- businesses will create systems that closely mirror how they communicate internally -or get blocked trying to develop systems that go against that communication structure-. And that problem has been exacerbated ten-fold by companies going remote without adequately and explicitly designing that structure to account for async work, time differences, or even leadership styles.?

It amazes me how many companies undergoing a digital transformation are still trying to transplant "squads" or "agile" concepts over organizational silos and hierarchical structures. And I sympathize with the?engineers and managers involved in those processes because no amount of software architecture or design will enable fast flow in teams organized in a way that introduces friction and bottlenecks.

Architecture modernization and transformation projects usually imply migrating from a monolith to a microservices architecture or from on-premises to the cloud, and that's never a purely technical endeavor.

For instance, the overhead of a microservices architecture won't be worth it if your team is a single large unit. And even if you have multiple autonomous teams, the design of those teams' communications will likely dictate your software architecture, not vice versa.

Take the following example from the book Team Topologies. Say that you have four teams comprised of FE and BE developers that hand over changes to a central DBA for database changes:

The software architecture most likely to emerge from such a team design, would have separate frontend and backend components for each team, and a single, shared core database:

A shared DBA team will promote using a single shared database, and separate frontend and backend developers will likely create separation between UI and app tiers.

If you don't want a single shared database, that's a problem.

The Inverse Maneuver

So, how can one increase the chances of building highly cohesive, loosely coupled architectures optimized for fast flow?

In the Accelerate book Jez Humble and Gene Kim research supports the "Inverse Conway Maneuver", which states:

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.

Taking the example from the previous section, if we want to achieve a microservices architecture with independent data stores, we can design the teams to match it by having separate developers for the client apps and the API, and a database developer within each team:

The Team Topologies book also introduces four fundamental topologies and three interaction modes to help approach team design.

The challenge is understanding what software architecture is needed before organizing the teams.

How to Start the Journey

Ideally, starting a digital transformation or an architecture modernization requires investing time to collaborate across silos and connecting architectural decisions with strategy and business outcomes. Wardley maps, business modeling, JTBD, OKRs, and many other tools and frameworks can help to design and align teams and their work. But more often than not, I've witnessed technical teams wanting to jump immediately into a monolith to microservices migration, and, in my experience, the "divide and conquer" algorithm rarely works in those situations. On the contrary, it risks becoming an integration hell down the road, because it is challenging to determine the boundaries of the domain/services upfront.

So, if you really can't dedicate time or prefer to do product discovery along the way, it's usually better to do "conquer and divide", and keep the monolith until there's enough visibility of those boundaries:

In XP, we don’t divide and conquer. We conquer and divide. First we make something that works, then we bust that up and and solve the little parts.

Kent Beck

The other suggestion would be applying a strangler pattern to progressively sunset the monolith, rather than migrating to a microservices architecture in one go.

That way, the teams' cognitive load can increase progressively instead of becoming overwhelming too fast. And, if you want to assess the team's cognitive load, there's a template that the Team Topologies team has made available.

Key Takeaways

• The structure of systems designed by an organization will mirror that organization's internal communication.
• Many companies attempt to adopt modern practices such as "squads" or "agile" without addressing the foundational organizational and communication structures, leading to inefficiencies and bottlenecks. Companies transitioning to remote work face amplified challenges related to Conway's Law.
• Designing teams properly is crucial for a successful software architecture. Understanding the desired architecture before organizing the teams is essential.
• Rushing from a monolithic system to a microservices one without proper preparation can lead to integration issues and increase cognitive load.

Have you experienced some of these problems?

If you need help with a digital transformation or an architecture modernization project, drop me a line and let's have a chat!

Alternatively, if you're not yet convinced, check out my experience tackling challenges like this at: https://fractionalcto.com.ar/digital-transformation