Sergio Caredda
Many years ago, Melvin Conway observed that the way organisations are structured impacts any system they create. In his article How Do Committees Invent (Conway, 1968), he wrote:
Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.Melvin Conway
At the time, the Harvard Business Review rejected his original paper because he hadn’t proved his hypothesis. The law became well-known after Fred Brooks cited the article and the idea in his classic book “The Mythical Man-Month,” calling it “Conway’s Law” (Brooks, 1995). The name stuck and spread, particularly among software developers.
Despite the author’s remark (to apply this not just to information systems), a lot of research that has validated this principle came from software developers (Bevan, 1999), including—a study by Microsoft (Nagappan et al., 2008). In many ways, the law is often referred to by stating that software is the product of the developing organisation communication structure.
This has led many organisations to experiment with more distributed teams agile methodologies. But at the same time, there is still a consideration that a group of disconnected programmers could infuse their work with their individual biases(Watts, 2020).
The organisational value of Conway’s Law
The reality is that this statement has a much broader validity. In all my work in organisation design and beyond, the feeling that this law holds is a constant.
Scholars often refer to the law by two related concepts:
- Homomorphism or Isomorphism (Kelly, 2006). I won’t discuss the difference in the two terms, but essentially is a mathematical principle by which one structure holds a structure-preserving map of another structure. In simpler terms, a system replicates recognisable elements of the organisation that developed it. This leads to what Allan Kelly (Kelly, 2014) defined as the Reverse of Conway’s law: Organisations with long-lived systems will adopt a structure modelled on the system.
- In simpler terms, some (MacCormack et al., 2008) call it the Mirroring Effect, by which a system produces a mirror image of the organisation that made it.
For the moment, it is sufficient to say that multiple researchers have validated these principles in various fields, not just in software design.
But why is this important?
The reason is that if we move away from one second from software products into something broader, we can immediately see many relationships with concrete cases out there:
- We have seen already how a massive aeroplane accident has resulted from a faulty communication structure in an organisation in theory designed to be entirely focused on safety and the importance of engineering.
- Several large scandals in organisations (think of Enron) have resulted from conscious organisational decisions that ultimately reflected the failure of an entire system.
- Think also of the minor everyday issue you might have with customer support for a product when you’re getting handed over from one department to another. Isn’t that the result of the internal organisation structure?
This is becoming more and more relevant today because the acceleration aspect of VUCA makes all these aspects more visible.
An example: Retail
Having had several experiences in retail, I see the actual effects of Conway’s Law whenever I enter a store. Physical stores (and, notably, e-commerce sites) deeply reflect how the organisation is structured and its communication structure. Think of apparel: few cases come immediately to mind.
- Apparel stores are mainly organised across gender (men/women) differentiations and age clusters (kids/adults). In most cases, this reflects a distinction that runs deep into the organisation, from style to product development, to merchandising and sourcing. This distinction immediately creates issues the moment genderless fashion comes into play and limits blur: small sizes, another area grouped under “kids”, even if adults also buy them.
- So-called “omnichannel” services. Ever tried to buy online and return something in store? I’m sure you all have experienced at least a pair of rolled eyes by the chair when asking for this service. The issue is that most organisations are still organised by channel; thus, returning to a physical store means that something sold online will end up in the stock count of a physical store. In most cases, business control mechanisms, resource allocation, incentives all are still by channel, despite the promise of an omnichannel experience.
- I have already mentioned the example of customer support before. How often did it happen to have had a technical problem with a product you bought, and while seeking assistance, you get bumped from the retailer to the producer, from the customer service department to the technical one.
All these examples reflect how broad the implications of Conway’s Law are, especially if we intend the concept of “system” in its most enormous possible sense, precisely as Conway himself intended.
A possible corollary to Conway’s Law.
This is why we should look at the critical output that an organisation produces, the experience delivered to its customers. This makes me think we can extend Conway’s Law with a corollary.
The quality of customer experience delivered by an organisation will inevitably be the product of its organisational design.
And I intend all elements of organisational design. Communication structure is one (and probably the most relevant), but what emerges here is another layer of meaning for the concept of intentionality in organisation design: you want to provide consistency across all your organisational elements.
There are cases of organisations that have reviewed their design with this principle in mind (Gilson, 2021). But we need to be careful here. The idea to go by a shortcut by applying what is called Inverse Conway Maneuver solely to a part of your organisation framework can be equally dangerous if not done strategically (Durand, 2021). The example is for those organisations that started distributing teams in an area to discover how many political issues arose, with individual groups still guided by old-framed values of power linked to size (Woods, 2017).
Another call for Intentionality
A few years ago, in his book How Google Works, Eric Schmidt (Schmidt, 2014) casually referred to the outputs of Conway’s Law.
You should never be able to reverse engineer a company’s organizational chart from the design of its product.Eric Schmidt, How Google Works.
I found d this quote to be illuminating back when I read it, exactly because of the load of consequences that Conway’s law brings with it. How often by buying a product, or experimenting a service, you are clearly able to see the defects of the organisation that produced it?
The above strikes a new chord for the Intentional Approach to Design that I am exploring and should include the following steps.
- Adopt an outside-in perspective, understanding customers and critical stakeholders in your design. This means moving away from the idea that the environment is simply an external factor, moving entirely into an Ecosystem logic.
- Always consider communication flows within the organisation as what will make or break your design. This means thinking both in terms of formal Organisational Model and Operating Model, but also in terms of the informal collaboration channels.
- Make sure you understand your own bias as the organisation’s designer. This is the most challenging part because we often underestimate the role of our ideas and how much they influence the design.
- Remember that Intentional Example will be the route for propagating the new design. As we discovered last week, it is paramount that change is implemented by intentionally giving the correct examples as needed.
- Last but not least, make sure you intentionally decide which organisation components will not be designed and leave the emergence. Choosing not to choose is a critical element of Conway’s Law because the property to which the law refers is latent, not intentional.
A Loop of Continuous Intentionality
When I originally posted this article as part of my newsletter, I received quite a lot of feedback. Antonio di Stefano referred to the concept of Lemniscate, an algebraic figure where all the points of the curve have a consistent relationship with their focus. The resulting figure is akin to the symbol of infinite we often use.
Why is this relevant? Essentially what this figure represents is that for any internal point there is an external representation of it. And vice-versa. So, for any intentional decision, we do on the design, there is an unintentional consequence externally, at the same time for any external situation that affects our organisation, there is an unintentional consequence internally.
The way we design (or chose not to design) the way we organise ourselves, generates images of us in all successive projections or systems. And everything that impacts from outside influences our design
This really makes Intentional Design an endless pursuit of consistency between intentional design action and external system of reference. With Conway’s Law being somewhat the engine of propagation, so deeply linked with consistency.
Have you seen Conway’s Law in action? What are your thoughts about it? Is it something we should exploit instead of battling?
Comments and Feedbacks
References
Bevan, N. (1999). Usability issues in website design (p. 9). ExperienceLab. https://experiencelab.typepad.com/files/usability-issues-in-website-design-1.pdf
Brooks, F. P. (1995). The mythical man-month: Essays on software engineering (Anniversary ed). Addison-Wesley Pub. Co.
Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(5), 28–31.
Durand, C. (2021, June 25). How to deal with an Inverse Conway Maneuver? – A talk by Romain Vailleux at Duck Conf 2021 | OCTO Talks ! Octo Talks. https://blog.octo.com/how-to-deal-with-an-inverse-conway-maneuver-a-talk-by-romain-vailleux-at-duck-conf-2021/
Gilson, N. (2021, August 18). What is Conway’s Law? Work Life by Atlassian. https://www.atlassian.com/blog/teamwork/what-is-conways-law-acmi
Kelly, A. (2006). Return to Conway’s Law. Allan Kelly Associates. https://www.allankellyassociates.co.uk/archives/1169/return-to-conways-law/
Kelly, A. (2014, January 26). Conway’s Law & Continuous Delivery. https://www.slideshare.net/allankellynet/conways
MacCormack, A., Rusnak, J., & Baldwin, C. (2008). Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis. HBS Working Knowledge, 08–039. http://hbswk.hbs.edu/item/exploring-the-duality-between-product-and-organizational-architectures-a-test-of-the-mirroring-hypothesis
Nagappan, N., Murphy, B., & Basili, V. (2008). The influence of organizational structure on software quality: An empirical case study. Proceedings of the 30th International Conference on Software Engineering, 521–530. https://doi.org/10.1145/1368088.1368160
Schmidt, E. (2014). Google: How Google works (First edition). Grand Central Publishing.
Watts, S. (2020, June 2). Conway’s Law: A Primer. BMC Blogs. https://www.bmc.com/blogs/conways-law/
Woods, D. (2017, August 15). How Platforms Are Neutralizing Conway’s Law. Forbes. https://www.forbes.com/sites/danwoods/2017/08/15/how-platforms-are-neutralizing-conways-law/
More posts like this
