On the relationship between systems and the organisations that build them
System design is a creative activity, but one that is subject to a variety of constraints. Many of these constraints are obvious: for example, when tasked with designing a new software product, a team might be asked to work within a budget or use a particular technology. These constraints place boundaries on the design activity; they force designers to work within parameters specified by the constraints. But there are other less obvious constraints too. In a paper entitled, How Do Committees Invent, published in 1968, Melvin Conway described a notion that is now called Conway’s Law: An organisation which designs a system will inevitably produce a design that mirrors the organisation’s communication structure. This post is a summary of the key points of the paper.
Conway begins the paper with the observation that the system design is an activity that involves specifying how a system will be built using a number of diverse parts. Many elements of the act of design are similar, regardless of the nature of the system –be it software or a shopping mall. The objective of a design team or organisation is to produce a specification or blueprint based on which the system can be built.
Much of design work is about making choices. Conway points out that these choices may be more than design decisions:
Most design activity requires continually making choices. Many of these choices may be more than design decisions; they may also be personal decisions the designer makes about his own future. As we shall see later, the incentives which exist in a conventional management environment can motivate choices which subvert the intent of the sponsor.
The paper is essentially an elaboration and justification of this claim.
The preliminary stages of design work are more about organizing than design itself. First, the boundaries have to be understood so that the solution space can be defined. Second, the high-level structure of the system has to be explored so that work can be subdivided in a sensible way within the organisation that’s doing the design. This latter point is the crux of Conway’s argument:
…the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise. Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist. Therefore, there is no such thing as a design group which is both organized and unbiased.
There are a couple of important points here:
- The act of delegating design tasks narrows the scope of design options that can be pursued.
- Once tasks are delegated to groups, coordination (via communication) between these groups is the only way that the work can be integrated.
Further, once established, it is very hard to change design idea (or a project team, for that matter).
The system mirrors the organisation
Most systems of any significance are composed of several subsystems that communicate with each other via interfaces. According to Conway, these elements (italicized in the previous sentence) have a correspondence with the organisation that designs the system. How so? Well, every subsystem is designed by a group within the organisation (call it a design group). If two subsystems are to communicate interact with each other, the two groups responsible for their design must communicate with each other (to negotiate the interface design). If subsystems don’t interact, no communication is necessary. What we see from this argument is that the communication between subsystems roughly mirrors the communication paths within the organisation.
As any system designer knows: given a set of requirements, there are a number of designs that can satisfy them. If the argument of the previous paragraph is true then the structure of the design organisation (or project team) influences the choice that is made.
Managing systems design
Conway points out that large system design efforts spin out of control more often than those for small systems. He surmises that this happens when the design becomes too complex for one person (or a small, tightly-knit group of people). A standard management reaction to such a situation is to delegate the design of component to sub-teams. Why? Well here’s what Conway says:
A manager knows that he will be vulnerable to the charge of mismanagement if he misses his schedule without having applied all his resources. This knowledge creates a strong pressure on the initial designer who might prefer to wrestle with the design rather than fragment it by delegation, but he is made to feel that the cost of risk is too high to take the chance. Therefore, he is forced to delegate in order to bring more resources to bear.
A major fallacy in this line of thinking is that more resources means that work gets done faster. It is well known that this isn’t so – at least as far as software systems development is concerned. Conway points out that politics also contributes to this effect. In most organisations, managerial status is tied to team size and project budgets. This provides an incentive to managers to expand their organisations (i.e. project teams), making design delegation almost inevitable.
Large teams have a large number of communication paths between their members. Specifically, in a team consisting of N people, there are N(N-1)/2 possible communication paths – each person can communicate with N-1 people making N(N-1), but this has to be halved because paths between every two individuals are counted twice. Organisations deal with this by restricting communication paths to hierarchical management structures. Because communication paths mirror organizational structures, it is almost inevitable that system designs will mirror them.
The main implication of Conway’s thesis is that a project team (or any organisation) charged with designing a system should be structured in a way that suits the communication needs of the system. For example, sub-teams involved in designing related subsystems should have many more communication channels than those that design independent components. Further, system design is inherently complex, and the first design is almost never the final one. A consequence that flows from this is that design organisations should be flexible because they’ll almost always need to be reorganized.
In the end it is less about the number of people on a team than the communication between them. As Conway mentions in the last two lines of his paper:
There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity. The development of such a philosophy promises to unearth basic questions about value of resources and techniques of communication which will need to be answered before our system-building technology can proceed with confidence.
This is as true now as it was forty-odd years ago.