What is Conway’s Law?

This week we’re diving into the concept of Conway’s Law, and its relation to psychological safety. Conway’s Law essentially describes the “force” that means how a team or organisation is structured will affect what the organisation does.

In 1967, Mel Conway submitted an article titled “How Do Committees Invent?” to the Harvard Business Review. HBR rejected it, so Mel submitted it instead to an IT Magazine called Datamation, who published it in April 1968.

In that piece, which you can read here on Mel’s own website, Mel describes:

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

I.e. we’re destined to build things that look like the teams that built them.

The Mythical Man Month

Fred Brooks then cited the piece in “The Mythical Man-Month,” (which we covered in a previous newsletter) and called it “Conway’s Law.” (See page 111 if you have the book). The name stuck.

Also known as the mirroring hypothesis, Conway’s Law shows the connection and the dependency between the social structures of an organisation, and what they create. The products created by organisations, which includes software, literature, machines, processes and governance all end up shaped like the organisational structure they are created in. Conway’s Law is best known in the field of software architecture, but Conway perceived it more broadly and applied it to most technical fields.

What this means in the real world is that even though we think we’re designing our products and systems, in practice, it’s often the organisational structure that designs them for us.
 

There’s a reasonable evidential basis showing Conway’s Law to be true at least in software development, as well as other fields. Here’s a great piece by Chris Fleming that addresses Conway’s Law in digital health.

There are a few key reasons for this:

Mechanisms Behind Conway’s Law:

• The coupling of teams is reflected in the coupling of their products. If teams are tightly coupled to each other, the components of the system they produce will be too.
• Teams build what they’re tasked to build. A database team builds a database, an electric motor team build an electric motor.
• The size of the team influences the size of the product they create. Big teams may produce big (and more complex) products. Small teams tend to produce small (and less complex) products. 

I’ve illustrated this in the graphic below. Solid lines indicate tight coupling, dotted lines indicate looser (less dependent) coupling.

 

Personally, I prefer to think of Conway’s Law more as a “force” than a “law”. It’s something that we need to be aware of, and we can either try to ignore it, fight against it, or use it to our advantage, as in the table below.

How to work with Conway’s Law:

The Inverse Conway Manoeuvre

The Inverse Conway Manoeuvre requires us to think about what we want to create – whether it’s software, hardware, a book, a building or anything else, and design our teams, and our interaction modes to match. We can do that by using Team Charters, Team APIs and structuring our teams intelligently. It can be very powerful to define explicitly how teams are expected to communicate with each other, and a great way to do this is by using the Team Topologies “Interaction Modes”:

Collaboration requires us to be tightly bound: it’s a highly dependent way of working. Facilitation is rather more like coaching, assisting and guiding: less dependent but still very interactive. X-as-a-Service is the least dependent mode of interaction between teams, and is more like a customer/supplier relationship, where a team can provide and consume resources from another without the need for heavyweight communication.

The concept of DevOps practices reflects these different approaches well: as we saw through the history of DevOps, it emerged from the perceived need to break down the silos between “Dev” and “Ops” teams, and applying these principles to help define how teams can work more effectively together is one of the core principles of DevOps.

Conway’s Law and Psychological Safety

A neat side effect of defining how teams, and the people in them are expected to interact and depend on each other, is that it also fosters psychological safety. It makes it easier for us to know what’s expected of us in our communication, and if we do communicate, how it will be received, and what we can expect in return.

An excerpt from Matthew Skelton’s mini-book “How to choose tools for DevOps and Continuous Delivery“

Several studies have confirmed the core message of Conway’s Law. There are many subtleties to this in practice, but it boils down to this: If the intercommunication between teams does not reflect the actual or intended communication between software components, the software will be difficult to build and operate.

You can use “Reverse Conway”— changing the team structure to match the required system architecture —together with techniques such as domain-driven design (DDD) and code forensics, to reshape team responsibilities to align with the software architecture you need to produce in order to clarify boundaries and improve the development and operation of your systems.

We also need to be mindful of the effect of shared tools on the way in which teams interact. If we want teams to collaborate, then shared tools make sense, but if we need a clear responsibility boundary between teams, separate tools may be best.

This newsletter is sponsored by Conflux

Conflux is the leading business consultancy worldwide helping organizations to navigate fast flow in software. We help organizations to adopt and sustain proven, modern practices for delivering software rapidly and safely.

‘The Fearless Organization’ by Amy Edmondson is considered by many to be essential reading on the topic of psychological safety. In this article, Sophie Weston, Principal at Conflux, has put together some key takeaways from the book.

Psychological Safety in the Workplace

I was really honoured to be featured in this excellent piece on psychological safety in the Financial Times, by Andrew Hill. I spoke to Andrew, as did a few of my wonderful clients from Warner Music and Abri, along with Amy Edmondson, about how refreshing it is to see psychological safety being addressed seriously and so widely. But along with that surge in interest comes a risk of the term being watered down and misinterpreted. 
 

-Note: the FT is paywalled, so you may need a subscription to read the article in full. 
 

We often cite Google’s Project Aristotle as a key resource in psychological safety evidence and practice. Unfortunately, Google themselves have their own troubles, and this is an excellent piece from Praveen Seshadri on what those problems are, and what’s required to deal with them.
 

I love this graphic from happystrokes.in on Instagram. Reframing is key to moving from a fixed mindset to a growth mindset.
 

Here’s a great piece from Amy Gallo in HBR on psychological safety – what it is, what it isn’t, and busting some myths about it, including that psychological safety doesn’t mean feeling comfortable all the time.
 

Amy’s elves have been hard at work again! 

Finally, this, from Work Chronicles. If we’re to be expected to stay late when there’s work to do, we can also expect to be able to finish early when there isn’t. 

Things to do and try:

Field Theory, based on social psychologist theories from Kurt Lewin in 1951, describes the current level of performance or being as a state of equilibrium between the driving forces that support change and the restraining forces that hamper it.

From that theory, Force Field Analysis is now used as a tool for making and communication decisions, and analysing decisions after the fact, to examine what may have contributed to that decision being made.  

Next time you’re making a difficult decision, or if you’re trying to work out why a decision was made, try this. Write the decision in the centre, and forces for on the arrows to the left, and forces against to the right. Consider how many forces are pushing one way or the other, and the relative strength of those forces.
 

This week’s poem:

“There will come Soft Rain” by Sara Teasdale

There will come soft rain and the smell of the ground,
And swallows circling with their shimmering sound;

And frogs in the pools singing at night,
And wild plum trees in tremulous white;

Robins will wear their feathery fire,
Whistling their whims on a low fence-wire;

And not one will know of the war, not one
Will care at last when it is done.

Not one would mind, neither bird nor tree,
If mankind perished utterly;

And Spring herself, when she woke at dawn
Would scarcely know that we were gone.