, , , ,

The other day I read Melvin E. Conway’s How do Committees Invent for the first time. The main thesis of his article is that “organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” So, for instance, during the time of the Apollo programme, one expected to find one teams for each of the three propulsion stages and at least two teams for the lunar module and the command module. Interestingly, Apollo’s stages were not only designed by different teams, but they were even produced by different companies at different locations in the US.

I had heard about Conway’s so-called law several times in the past, and before that I had even re-discovered it myself. My version was: show me your architecture and I can draw the organisational diagram of your organisation. The other day I thought it was about time to read Conway’s original contribution, and it was a fun read. The above quote not only states the observed “law” but it also explains it: the reason for the homomorphism between organisational structures of companies and the systems they design is the organisation’s communication structure. Let me explain this with an example: the new product of a company is intended to comprise three tightly knit functional parts: human user interface, web services for accessing the enterprise data base, and the enterprise data base itself. Assume that originally all three parts are designed on location in the US. However, after some few months, management decides to move the development of the data base to Europe. The final design of the system would in this case exhibit tightly knit human interfaces and web services (they might even be seamlessly integrated), while the interfaces between the former two and the database would be rather slim and clean. In other words: instead of the originally intended monolith, one would rather end up with a two-part system, and the main reason for this is that communication between the two US teams is easier than that between the US teams and the European team.

Since its conception, Conway’s “law” has passed multiple tests (see, for instance, Naggapan et al.‘s study), and it is probably about time to accept it as a fact. However, I agree with the EuroPLoP 2005 Focus Group in that Conway’s finding is not a law, namely inevitable. Rather Conway identified a force in that the patterns he unearthed can be overcome. There are other forces that control design, for instance political forces (norms, regulations …). One way to do this, as identified by the above focus group, is the following: if one increases communication between geographically separated teams by, for instance, enforcing daily web meetings, the “disjunction”of the system will be much smaller.

Note well that Conway’s force are not necessarily a bad thing. If the goal is to actually create a highly modular system, the easiest way to achieve this is to assemble distinct teams for the modules and to make the teams responsible for the modules over the entire life-cycle. This approach is being recommended when pursuing a micro-service architecture style, which is characterised by very high modularity.

When reading the focus group’s report I was struck by how everyone in this domain assumes that communication between development teams is fully transparent and that everyone is always aware of what they are communicating and why. But this is rarely the case. By this I do not allude to scheming and power struggles, rather that we humans are often unaware of how limited our conversational style is and how it can inhibit change. Let me illustrate this with a hypothetical example. A company wants to change the style of their products from monolithic service-oriented architectures to a micro-service style (see above). In order to do that, they want to resolve old team structures and align their developer along business-oriented service topics instead of more technical topics, as was the case in the past. An example for such a redistribution is to dissolve the team for databases and database access and to distribute the members among the new business-oriented teams, which are responsible for micro-service topics such as ordering, inbound logistics, customer communication, etcetera. The anxiety felt by the members of the database team will, according to my experience, not directly be vented as in “I am not comfortable with this change.” Rather, the team members will focus on technical and organisational reasons for why this is a bad idea (“micro-services are just a fad”, “we will lose valuable engineering knowledge over time if we database folks do not longer belong to one team and exchange our experience on a daily basis”, etcetera). The reasons for why anxieties are avoided and the discussion is diverted toward seemingly sound “rational” arguments, can be manifold. For instance, the system-development management might not be amenable to emotional arguments. But in my experience another factor plays an important role: engineers usually have not learned how to express emotions. For instance, identifying and communicating emotions is not part of most engineering syllabuses, and there seems to be a self-recruiting trend of emotionally “cold” people in engineering. So, instead of communicating their emotions, engineers have, in my experience, a tendency to communicate factual statements instead of emotional “appeals”. For instance, an engineer rather says “conversations are not allowed in the office area” to his chit-chatting colleagues instead of “I cannot concentrate when you talk while I work, and that makes me nervous and angry”.

So what has all this to do with Conway’s force and how human communication factors into it? Well, I submit to you that simply increasing the frequency of communication does not always help when trying to overcome Conway’s force. Rather, one also needs to look at what actually is said and what should be said instead. If aversion is one of the reasons behind change roadblocks in an organisation, then discussing semi-rational objections is a waste of time. Not addressing the emotional, vulnerable elephant in the room will actually reinforce Conway’s force irrespective of how much effort an organisation invest in communication to overcome Conway’s force.

That’s all I had on my mind for today.


If you like this blog post please click the below “like” button.

If you want to stay up to date with my island letters please use WordPress’s “follow” function or the email option provided in the panel on the right.

Also, please share your thoughts in the comment section; letters can and should be sent both ways.