Over time, different people have articulated Conway’s Law in various different ways. This is an overview of the variations I found when recently going over Conway’s Law literature.
Update May 25, 2021: Add the Inverse Conway Manoeuvre.
Update June 27, 2021: Add how incremental software development impacts the organisation.
The original definition of Conway’s Law by Melvin Conway.
Organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations.
-— Melvin Conway, How Do Committees Invent?, 1968
Yourdon and Constantin rephrased Conway’s Law more firmly.
The structure of any system designed by an organization is isomorphic to the structure of the organization.
– Edward Yourdon and Larry L. Constantine, Structured Design, 1979
Eric Raymond restated Conway’s Law as follows.
The organization of the software and the organization of the software team will be congruent.
-— Eric Raymond, The New Hacker’s Dictionary (3rd ed.), 1996
Summarising the COBOL example from the paper.
If you have 4 groups working on a compiler, you’ll get a 4-pass compiler.
-— Eric Raymond, The New Hacker’s Dictionary (3rd ed.) p. 124., 1996
Adding Tom Cheatham’s Amendment to Conway’s Law.
If a group of N persons implements a COBOL compiler, there will be N−1 passes. Someone in the group has to be the manager.
-— Eric Raymond, The New Hacker’s Dictionary (3rd ed.) p. 124., 1996
James Coplien and Neil Harrison expressed it as follows.
If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationships between organizations do not reflect the relationships between product parts, then the project will be in trouble …
Therefore: Make sure the organization is compatible with the product architecture.
-— James Coplien & Neil Harrison Organisation patterns of agile software development, 2004
Allan Kelly’s Corollary:
Organisational design is system design.
-— Allan Kelly, 2005
Or put differently by Ruth Malan.
If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.
– Ruth Malan, Conway’s Law, Feb 13, 2008
Ruth Malan has always been good at formulating Conway’s Law in catchy ways.
The architecture of the system gets cemented in the forms of the teams that develop it.
…
Conway’s Law also kicks in if we take an initial guess at the system decomposition, allocate subsystems to teams, and sally forth–the team boundaries will tend to become boundaries within the system.
– Ruth Malan, Conway’s Law, Feb 13, 2008
This relates to two points raised by Melvin Conway in his seminal paper:
- At the very beginning: “the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise.”
- And towards the end as a closing thought: “The initial design of a system is never the best. The system may need to change. Therefore it requires flexibility of the organisation to design effectively.” This in turn suggests the requirement for Conway’s Corollary which we will get to further down the article.
Anything else will be a feat of architectural heroics; hard to accomplish, when architectural heroics have to compete with schedule heroics driven by the steady beat of integration clocks.
Architecture needs to happen across the interfaces, and this also means across the system/organization interfaces. It means that system architects (who we call architects) and business architects (who we call managers) should not work as if one has no impact on the other.
– Ruth Malan, Conway’s Law, Feb 13, 2008
Which nicely winks towards Team Topologies that discusses team interfaces in depth.
Over beer and food, Martin Thompson and Pieter Hintjes came with the following definition.
Conway’s Law, which states, roughly, that the things an organization produces will reflect how the organization communicates.
Martin Tompson or Pieter Hintjens, Sex in Title, and Other Stories, Dec 16, 2013
In the same article, Pieter Hintjes continues …
A large scale system is one that stretches across time and space. A large organization similarly, stretches across time and space. Conway’s Law ties the two. How we organize defines how we think collectively, and thus what we make collectively.
– Pieter Hintjes, Sex in Title, and Other Stories, Dec 16, 2013
Again Ruth Malan.
We can expect continued evolution not just in the systems we create, but the organizational forms that create them.
As we create more systems-of-(themselves complex)-systems, we can expect the organizational forms to have to evolve to accommodate the greater system-level challenges in the system and in the organization.
They [system and organization] will co-evolve, because if they don’t, Conway’s Law warns us that the organization form will trump intended designs that go “cross-grain” to the organization warp.
– Ruth Malan, Conway’s Law, Dec 17, 2013
According to Michael Nygard system architecture is a good source for archaeological research on past enterprise decisions which opens an interesting discussion on technology and politics.
You can read the history of an enterprise’s political struggles in its system architecture.
@mtnygard A history of Conway’s Law
– @SteveSmith_Tech, May 8, 2013
@mtnygard That’s some sort of corollary to Conway’s Law.
@jmbroad Definitely! It is the effect of changes in structure over time. (Credit goes to @mfeathers for the original thought there.)
@mtnygard @mfeathers Unsurprising. I esteem you both as masters of software sociology. I recommend Arch w/o End State to everyone I know. :)
Architecture without an end state means accepting that “changes you’re starting now will co-exist with changes that started last year and the year before. If you adopt that perspective, then you stop trying to rip up the pavement and do something completely new, and you focus a lot more on incremental change”. And here starts your history of decisions.
Software, like all technologies is inherently political. Code inevitably reflects the choices, biases and desires of its creators” J Cascio
Politics plays a huge role. And a lot of the role it plays is in what it silences. But we don’t know the stories of silence.
– Ruth Malan, Conway’s Law-ish, Aug 5, 2013
Interestingly, this discussion on history and politics lays the foundations on how piecemeal growth or incremental software development impacts the organisation.
Incremental software development is an essential condition to growing IT systems based on feedback and learning. It is the only way we can satisfy what is required to support users of IT systems the right way.
Piecemeal growth, or incremental development, is not just desirable but a fact of life in software. Even so, we need to build more learning into our process. More learning when it is cheaper to find and fix problems with the vision (doing course corrections toward “right system”) and structure (built right).
Then, accepting that we will continue to learn and evolve our system, we need to invest in fixing the mistakes. Incrementally adding functionality yes, but repairing structural defects too. This investment is the crucial dual to piecemeal growth that we too often forget in software.
When we keep marching to a frenetic “add value” drumbeat, we get into a situation where the system threatens to crumble under the mass of deferred structural issues.
…
Going from the messiness of our discovery-oriented process to the well-factored, tested integrity of our engineered system shouldn’t be considered rework or waste! Unless we leave it until after it has sorely impacted users and our business viability. That is waste.
As we proceed in the fog of uncertainty, entropy grows – and produces more fog! Under uncertainty we “give things a try”; accept good enough, and try the next thing. As entropy grows, it introduces its own uncertainty…
– Ruth Malan, Conway’s Law Reverb, May 5, 2014
But incremental software development has a consequential corollary. As software grows, entropy grows. To contain entropy, we need to refactor systems. In the end, many refactorings result in a significant redesign of systems. Incremental software development requires growing and redesigning the organisation to fit the new system. It is a consequence of the Inverse Conway Manoeuvre. We will come back to this at the end of the article. Grow the organisation alongside the growing systems.
Refactoring is the corollary to piecemeal growth, allowing entropy containment. But we have to refactor the organization too? If it would subvert the system (re)design and evolution.
…
There is a relationship between the architecture of the organization (and its communication flows) and the architecture of the system (and its boundaries and flows). We need to take this into account, to reap synergies rather than doing the harder thing, trying to “swim against the current.”
…
Integrating across organizational divides is a challenge. When left to happy accident, may well have all the smack of accident rather than design - as in, designed to get more what we want, looking for consequences so we get less unintended side-effecting from being system-blind.
– Ruth Malan, Conway’s Law Reverb, May 5, 2014
All this naturally follows Allan Kelly’s advice: “Grow the team with the system. Small teams, small systems, piecemeal growth. Start as small as you can and grow as you need too. Don’t start thinking big.”
According to Michael Feathers, when you ship your product, you ship your organisation.
Conway’s Law by @mfeathers - or “you always ship your organization, so design your organization well” #craftconf
Again from Michael Feathers.
In capsule form, Conway’s Law implies that if you have, say, three teams, chances are you will end up with three subsystems whether you intend to or not.
When the cost of communication goes up we, often unconsciously, organize our work to minimize it.
If it’s easier for me to share a vision and communicate within my local team, we end up producing something cohesive that is a bit detached from other teams’ work.
-— Michael Feathers, Twitter, Reddit and Conway’s Law, 2017
Lastly, I found in Dan Slimmon’s slides Conway’s Law: The Skeleton of Devops this one from Adam Jacob (we assume the one from Chef).
Your org structure isn’t solving your problem.
It’s an artifact of how you’ve solved it before.
– Adam Jacob
Which is again an expression of the Inverse Conway Manoeuvre.
This seemingly flows into Mel Conway’s observation:
The importance of [Conway’s Law] … is not that your design organization determines the things you can design.
The importance of the principle … is … that your design organization is keeping you from designing some things that perhaps you should be building.
The principle creates an imperative (1) to keep asking: “Is there a better design that is not available to us because of our organization?” and (2) to be open to changing the organization if a better design is found.
– Mel Conway, Toward Simplifying Application Development in a Dozen Lessons, 2016
To change the organisation you need Conway’s Corollary:
And then there is what I call Conway’s Corollary:
“organizational flexibility is important to effective design”.
IMO this is the the most profound part of his article.
Without organisational flexibility, as Ruth Malan says, “[when] architecture of the system and the architecture of the organisation are at odds, the organisation wins”.
The organisation will always be limited to produce designs that match the real, on-the-ground communication structure of the organisation. Note that the real on-the-ground communication structure are not necessarily the ones depicted on the traditional organisation chart. People do not restrict their communications only to the lines on the org chart. Teams reach out to whomever they depend on to get their work done. Again team interfaces from Team Topologies.
This brings us gracefully to the Inverse Conway Manoeuvre.
… 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.
– Nicole Forsgren, PhD, Jez Humble and Gene Kim, Accelerate, 2018
Therefore we need to understand what software architecture is needed before we organise the teams.
Team assignments are the first draft of the architecture.
Michael Nygard, Release It!, 2007
This means that anyone who makes decisions about the shape and placement of engineering teams is strongly influencing the systems architecture. And here we have Ruth Malan again.
Another implication of Conway’s Law is that if we have managers deciding on teams, and deciding which services will be built, by which teams, we implicitly have managers deciding on the system architecture.
– Ruth Malan, Conway’s Law, Feb 13, 2008
Thus organisation design and software design are communicating vessels and both need to be tackled by the same informed group of people, i.e. managers and architects.
Ultimately a big part of architecture isn’t about the technical or solution detail. It’s about putting in the right structures, ways of working, lines of communication and overall conditions
Therefore …
More then ever I believe that someone who claims to be an architect needs both technical and social skills, they need to understand people and work within the social framework. They also need a remit that is broader than pure technology – they need to have a say in organizational structures and personnel issues, i.e. they need to be a manager too.
Allan Kelly, Return to Conway’s Law, Jan 6, 2006
To conclude …
When I think of the really good technical people I know … sooner or later they all come to the point where they realise that to solve technical problems requires them to work outside of the technical domain.
Allan Kelly, Return to Conway’s Law, 2006
But …
I’ve had mixed experiences on this. Leadership that understands it has supported me in making the necessary structural changes. Leadership that does not understand… I run into problems with very quickly.
“Why are you hacking my org? Aren’t you a tech person? Stay in your lane”
Alright, what started as just summarising the various ways different people have articulated Conway’s Law as a sort of note-taking for myself, became a cross-reference of thoughts, observations and links between this whole mix. This article seems to become a never ending work.
Acknowledgment
I want to thank Paul Hammant for nudging me to include the Inverse Conway’s Manoeuvre and for saying this is a great article. Thank you, Paul!
I also would like to thank Ruth Malan for writing down and sharing her reflections on Conway’s Law. A lot of the above content is influenced by the traces Ruth wrote in the sand.
Bibliography
- The Talk: Shades of Conway’s Law
- How Do Committees Invent?, Melvin Conway, 1968
- Structured Design, Edward Yourdon and Larry L. Constantine, 1979
- The New Hacker’s Dictionary (3rd ed.), Eric Raymond, 1996
- Organisational patterns of agile software development, James Coplien & Neil Harrison, 2004
- What do I think about Conway’s Law now?, Lise Hvatum and Allan Kelly’s at EuroPLoP 2005
- Return to Conway’s Law, Allan Kelly, 2006
- Release It!, Michael Nygard, 2007
- Conway’s Law, Ruth Malan, 2008
- Conway’s Law-ish, 2013
- Conway’s Law Reverb, Ruth Malan, 2014
- Continuous Delivery and Conway’s Law, Allan Kelly, 2014
- Toward Simplifying Application Development in a Dozen Lessons, Mel Conway, 2016
- Twitter, Reddit and Conway’s Law, Micheal Feathers, 2017
- Team Topologies, Matthew Skelton and Manuel Pais, 2019
- Conway’s Law on Wikipedia