Utilise Conway’s Law

What is Conway’s Law?

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

Originally part of a paper by Melvin Conway published in 1968, then quoted and made famous by The Mythical Man-Month by Frederick Brooks from 1975, where it was coined as “Conway’s Law” and still relevant today. It is most often used in the context of software systems, but it applies to systems in general.

It’s based on the observations that the software architecture design is a reflection of how an engineering team is organised. The most known anecdotal story is about the COBOL and ALGOL compilers. Five people were assigned to create the COBOL compiler, and three were assigned to create the ALGOL compiler. The COBOL compiler ended up consisting of five passes, the ALGOL had three passes.

Let’s stick to some other simplified examples:

• A single small team building a product will likely end up with a monolithic architecture.
• Multiple teams will likely end up with multiple sub-systems or service-oriented architecture.

Don’t defy it

With laws of nature, such as gravity, we don’t need to be reminded of their effects as we constantly get to experience them, and we usually don’t try to escape them either. Conway’s Law, in contrast, might be something you didn’t know about or might be tempted to ignore at first. Yet, when you try to defy Conway’s Law, you’ll likely be spending a lot of resources as it keeps pulling on your organisation and system’s design while trying to achieve your business objectives.

Let’s start with the first example mentioned in the previous section; if a single small team builds a system using a microservices approach, they’ll likely struggle with lots of overhead and increased complexity of building and maintaining it.

When you look at the example of multiple teams, and if you would have them all contribute to a monolithic architecture, they are more likely to end up clashing with each other as there might not be clear boundaries in the system. Yet, they do have a barrier in communicating with each other as they’ll communicate much more within the team than outside of it. There is a high chance they’ll feel restricted and annoyed by being bound to the other team due to their shared code base, certain design decisions, and release cadence.

Even though the examples are overly simplified, I have experienced some of those negative effects first-hand. And I can tell you they really don’t benefit the teams or business outcomes.

Utilise it

Either let your system’s design evolve according to your organisation or let your organisation grow towards a desired system design. The latter is sometimes referred to as The Inverse Conway Manoeuvre as it seeks to use Conway’s Law as a tool to get to your desired system design/architecture by evolving your organisation.

The most prominent example of this inverse approach is the microservices architecture, as a way to set up autonomous teams who can deliver business value independently of each other. These teams will benefit from separate services and, depending on the scale of the organisation, microservices which can evolve and be deployed separately.

Adapt

Always keep the business outcome in mind first. If you have reasons for your organisation or system’s design to change, it should stem from that thought first and how to facilitate that most efficiently. And by taking Conway’s law into account, not just your business outcomes will likely be better in the long term, but your team members will also be thankful as they’ll probably experience less friction.

When a change is needed, it is not something you can do overnight; you can’t just copy or implement something like “The Spotify Model” or “microservices architecture” and expect immediate or short-term results. Each company and system have their intricacies, adapt to your organisation’s needs and remember to keep adapting to your organisation’s evolving needs. But do it in increments, allowing for feedback and adjusting along the way.

Feel free to take inspiration from something like The Spotify Model, but adapt it to your organisation’s needs. To do this, it’s essential to fully understand the underlying ideas and any alternatives. For this, I highly recommend the book Team Topologies by Skelton and Pais as it contains a wealth of information that you can use to decide which structures make the most sense for your context.