What is it?

Conway’s Law

In April 1968, Melvin Conway published a paper called “How Do Committees Invent?” to a then-popular IT magazine called Datamation. The paper says:

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

The year before, the Harvard Business Review had rejected it on the grounds of the thesis not being proven. Forty years later, in 2008,  Alan D. MacCormack, John Rusnak and Carliss Y. Baldwin of Harvard Business School reported on a study called “Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis”. They concluded along the same lines as Conway did four decades earlier: 

“[..] A product’s architecture tends to mirror the structure of the organisation in which it is developed.”

In simpler words, the way your people communicate closely aligns with the way your code communicates. Unsurprisingly, the paper also reaffirmed that business codebases tend to be tightly coupled. At the same time, open-source projects turn out to be more modular and decomposed – a result of the different communication structures surrounding them.

The term ‘Conway’s Law’ was coined by Fred Brooks when discussing Conway’s ideas in his essential book “The Mythical Man-Month”. 

Going Inverse

The concept of Conway’s Law can also be applied in a reverse manner. For example, having a target architecture in mind, we can explicitly evolve communication structures within the organisations, influence the resulting system, and achieve our planned design. This tactic is called the “Inverse Conway Manoeuvre” and was first mentioned by Jonny Leroy and Matt Simons from ThoughtWorks in the December 2010 issue of the Cutter IT Journal.

Putting the ‘Why’ aside, consider a requirement to run a service-based architecture where each component is developed and managed independently from each other. To achieve the desired system’s design, the organisation’s structure should follow the same logical grouping and isolation as the preferred services: Individual teams will be responsible for an individual service, having complete and independent decision-making capabilities.

Collaboration across those teams would follow a rather strict process, e.g. using prioritised feature requests. Such a process will become the team’s collaborative interface (equal to a service API). When communication is bundled through those interfaces and spontaneous collaboration is limited simultaneously, it will look a lot like inter-service communication in your technical system’s design. 

Why it matters

Understanding and applying Conway’s law is a crucial building block of a modern tech company, which, to be successful, needs to bring organisation and technology together as closely as possible. However, thinking about both such building blocks in separate silos can lead to different communication flows that don’t go well together and often hamper the ability to create and keep velocity. It will therefore limit a company’s ability to compete in its market successfully. Or as Leroy and Simons put it:

“Dysfunctional organisations tend to create dysfunctional applications.“

The Inverse Conway Manoeuvre gives you a tool to tackle the organisational and systems-design challenge at hand from a different perspective. It puts technical and architectural requirements on eye-level with corporate design and becomes an essential building block of a tech company.  

When you take those ideas further, the Inverse Conway Manoeuvre can also be used to drive organisational change. It becomes appealing when a change process from within is hard to implement and to progress the technical system into a different form is more straightforward, cheaper or quicker to realise. A deliberate architectural choice can influence the organisation’s design towards the desired outcome in such a case.

Consider a microservice-based architecture and a fragmented or cluttered company. Both designs are linked and have influenced each other. Imagine further that the company has many defunct communication channels and knowledge is not travelling as expected. Evolving such a service architecture towards a more condensed system – by merging services, removing APIs and coupling components – will influence the organisation’s design towards fewer boundaries and more fluid communication. However, it only works as long as the organisation is willing to adapt and learn.

Where next?

Most organisations are composed of disconnected systems.  By looking at it through the eyes of Conway’s law and applying the Inverse Conway Manoeuvre, we can create organisations and technical systems that are well connected and allow for a more seamless communication and collaboration experience. 

For additional reading, Team Topologies by Matthew Skelton and Manuel Pais suggests a whole set of ideas, tools and structures, to take Conway’s thinking further and apply it to optimise organisation and technology for fast flow.

***

Want to hear from more thought leaders in the tech space? Join us and some incredible speakers at our forthcoming CTO Craft Con: The Strategic CTO on 23– 24 May. Find out more and get your tickets here!

If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top or email us here and we’ll be in touch!

Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more.