Conway’s law and communication networks

I’ve been working in this (stealth as of now) startup for more than a month now and although it’s smaller than the one where I had worked prveviously, I’m quite intrigued by the communication structures and the inefficiencies that I perceive because of them.

One key difference here is that I have to coordinate across mutliple teams (two as of now) with different skills and specializations and as such, I can see certain patterns of communication emerging and which also makes me think of Conway’s law:

Conway’s Law

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

• Melvin Conway, https://en.wikipedia.org/wiki/Conway%27s_law

In the context of Conway and in general a system can be any tool for assisting or automating an organization workflow. Here we consider only business workflows, as an organization can be non-profit, educational or simply a collection of individuals working on a shared task.

A business organization on the other hand would have defined outcomes (usually in terms of products or financial metrics) and roles according to specialization (a la industrial revolution). There are certain other interesting aspects of such an organizational structure, for example:

• Monotony: Human brains haven’t really evolved to do one task repetitively, though there may be certain brains more wired to it than others
• Social Hierarchies
• Monetary Incentives and issues surrounding them: How much does one get paid and how to ensure fairness or perceived fairness
• Actualization: Human beings need to feel they have (or need to have) a purpose in life or their lives have meaning which becomes hard if you think you’re a cog in a big machine.

Now we can talk about the communication structure as:

1. Overview of the communication structure
2. Mathematical modeling of the communication and task patterns

Patterns of Communication

Mathematical modeling we leave for a later date and let’s get back to communication patterns and systems. Here I note down the patterns and some observations related to those patterns emerging:

1. Messages are localized within the departments in an org
2. Messages are further localized within the teams in a department
3. Inter team and inter department communication happens usually through few intersection points (or interfaces).
4. Localization of messages leads to separate codes being developed for each team/department.

Now, at this point it seems that the communication networks are behaving like the Real World Networks explored by Barabasi in (Barabasi 2021) and I’m curious if the networks mentioned in the book are natural or man made? I’ll have to read the book for that.

Getting back to communication in an organization, another thing I’ve noticed is that we as software engineers have modeled the systems based on the network patterns. For example, contrast the Java ecosystem with Emacs.

Java is:

1. Used primarily in enterprise software
2. Known for robustness
3. Follows the OO paradigm

Now think of the enterprise communication. Like Java we have information hiding between team and there may be information hiding among classes (say representing individuals) and the teams (packages in java). Communication among them in both cases happens via public functions.

Similarities between Java and Enterprise organizations:

1. Java: Rigidity due to enforced structure and typing in Java

   Enterprise: Similar to bureacracy and standards in an enterprise org.

2. Java: Difficult to change advanced projects

   Enterprise: Again similar to lumbering caricature of enterprise orgs.

3. Java: A lot of people hate working with it

   Enterprise: Nothing to explain here

4. Java: Classes and packages are built on encapsulation and information hiding

   Enterprise: Hierarchies are built on such principles as well. All information isn’t accessible to everyone.

5. Java: Projects are robust and can last for decades

   Enterprise: Enterprises also have to last for very long and have to be resistant to failures.

Now consider Emacs and its open source Lisp implementation and similar nature of its functions, modules and packages.

1. Elisp: Dynamic typing, pluggable modules. Change at any stage is easy.

   OSS: OSS movement and orgs are similar. Dynamic and ever changing

2. Elisp: People love working with it.

   OSS: People love working with OSS also.

3. Elisp: Everything is global and all variables and functions are accessible to everyone. This is the opposite of information hiding! Yet Emacs is huge and it works in cooperation with certain conventions.

   OSS: Code and docs are open. Standards are open. Comments are open. Knowledge is shared.

4. Emacs: Ease of modification can lead to instability.

   OSS: Projects can be chaotic and unpredictable.

5. Elisp: Things can get ugly if bad code is introduced

   OSS: Projects can die quickly if the driving people aren’t good. Though that can be said of enterprises also but it’s more true for OSS projects because of lack of structure. A top exec can be replaced but it’s more difficult to replace a BDFL in an OSS project.

Modern Trends

Curiously the modern trend has been to have a bit of a hybrid approach of the two. Permit wide variation within components but strict communication protocols across components. Such patterns can emerge in Microservices where the implementation of each microservice is not only independent but could use any framework or design pattern. While the communication between the microservices is usually strict and follows certain patterns.

The question then to ask is, can we adapt this pattern to an organization? Have these patterns already been adapted? Agile and related methods have already evangelized small teams, documentation and TDD etc. Companies like Amazon have focused on small teams for fast evolution of new features. We have to then think of how the communication patterns should be analogous to microservices architecture.

Traps

Of course all of these dictums won’t hold in all cases. Certain assumptions can simply be not true in the given context. For example:

1. Humans are not machines For example, we can’t always assume that a human acting as a mediator will be highly available.
2. Humans aren’t fully rational Humans can have skewed incentives like social constraints and objectives or other psychological factors.
3. Humans need motivation While a machine will simply perform its task, humans will need to have motivation to perform it and money may not always be motivation enough.

References