How do committees invent?

How do committees invent?, Conway, Datamation magazine 1968

With thanks to Chris Frost for recommending this paper – another great example of a case where we all know the law (Conway’s law in this case), but many of us have not actually read the original ideas behind it.

We’re back in 1968, a time when it was taken for granted that before building a system, it was necessary to design it. The systems under discussion are not restricted to computer systems either by the way – one of example of a system is "the public transport network." Designs are produced by people, and the set of people working on a design are part of a design organisation.

The definition of design itself is quite interesting:

That kind of intellectual activity which creates a whole from its diverse parts may be called the design of a system.

When I think about design, I more naturally think about it the other way around: how to decompose the whole into a set of parts that will work together to accomplish the system goals. But of course Conway is right that those parts do have to fit together to produce the intended whole again.

There are two things we need at the very beginning of the process:

  • An (initial) understanding of the system boundaries (and any boundaries on the design and development process too) – what’s in scope and what’s out of scope.
  • A preliminary notion of how the system will be organised. Without this, we can’t begin to break down the design work.

Given a preliminary understanding of the system, it’s possible to begin organising the design team. Decisions taken at this early stage, with limited information, can have long-lasting consequences:

…the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise. Given any design team organisation, 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.

These days its less likely that you’ll have a dedicated design team – even the seemingly obvious statement that it makes sense to (at least partially) design something before building it can feel like a controversial statement! But of course we do undertake design activities all the time, perhaps informally and implicitly, sometimes more explicitly. We’ve just learned to take smaller steps with each design increment before getting feedback. If it helps, then in the software context if you mentally substitute ‘design and development’ every time Conway talks about design and the design organisation I don’t think you’ll go too far wrong.

Once you’ve got your initial organisation of the design (and development) team done, delegation of tasks can begin. Each delegation represents a narrowing of someone’s scope, with a commensurate narrowing of the class of design alternatives that can be considered. Along with the narrowing of individual scopes, we also make a coordination problem:

Coordination among task groups, although it appears to lower the productivity of the individual in the small group, provides the only possibility that the separate task groups will be able to consolidate their efforts into a unified system design.

It’s a rare team that re-organises in the light of newly discovered information, even though it might suggest a better alternative.

This point of view has produced the observation that there’s never enough time to do something right, but there’s always enough time to do it over.

The two most fundamental tools in a designer’s toolbox are decomposition and composition. The system as a whole is decomposed into smaller subsystems which are interconnected (composed). Each of these subsystems may in turn be further decomposed into, and then composed out of, parts. Eventually we reach a level that is simple enough to be understood without further subdivision. Of course therefore the most important decisions a designer can make involve the criteria for decomposing a system into modules, but that’s another story!

The different subsystems talk to each other through interfaces (a newly emerging term in 1968). Now, if we think about systems composed of subsystems interacting via interfaces, we will find a parallel in the organisation by making the following substitutions:

  • Replace ‘system’ by ‘committee’
  • Replace ‘subsystem’ by ‘subcommittee’
  • Replace ‘interface’ by ‘coordinator’

Or to put that in more modern terms, I think you can also:

  • Replace ‘system’ by ‘group’
  • Replace ‘subsystem’ by ‘team’
  • Replace ‘interface’ by ‘team leader’

We are now in a position to address the fundamental question of this article. Is there any predictable relationship between the graph structure of a design organization and the graph structure of the system it designs? The answer is : Yes, the the relationship is so simple that in some cases it is an identity…. This kind of structure-preserving relationship between twos sets of things is called a homomorphism.

By far my favourite part of the paper is the second half, where the implications of this homomorphism are unpacked. It was Fred Brooks who actually coined the term ‘Conway’s Law’ in The Mythical Man Month when referring to this paper. The mythical thing about the man person month of course is the illusion that person-months are fungible commodities – a very tempting idea from the management perspective, but utterly wrong! Conway shows us why. The ‘resource units’ viewpoint would say that two people working for a year, or one hundred people working for a week are of equal value…

Assuming that two men and one hundred men cannot work in the same organizational structure (this is intuitively evident and will be discussed below) our homomorphism says that they will not design similar systems; therefore the value of their efforts may not even be comparable. From experience we know that the two men, if they are well chosen and survive the experience, will give us a better system. Assumptions which may be adequate for peeling potatoes and erecting brick walls fail for designing systems.

We all understand this at some level, but it’s easy to forget. Plus, there are organisational forces that work against us:

  1. We come to the early realisation that the system will be large, with the implication that its going to take more time than we’d like to design with current team size. Organisational pressures then kick in to "make irresistible the temptation to assign too many people to a design effort".
  2. As we add people, and apply conventional management structures[^1] to their organisation, the organisational communication structure begins to disintegrate.
  3. The homomorphism then insures that the structure of the system will reflect the disintegration which has occurred in the design organisation.

The critical moment comes when the complexity has not yet been tamed, and the skills of the initial designer are being tested to the maximum:

It is a natural tempatation of the initial designer – the one whose preliminary design concepts influence the organisation of the design effort – to delegate tasks when the apparent complexity of the system approaches his limits of comprehension. This is the turning point in the course of the design. Either he struggles to reduce the system to comprehensibility and wins, or else he loses control of it.

Once an organisation has been staffed and built, it’s going to be used. Organisations have an incredible propensity for self-preservation.

Probably the greatest single common factor behind many poorly designed systems now in existence has been the availability of a design organisation in need of work.

I’ve always had a preference for smaller teams consisting of highly-skilled people over larger groups. Revisiting Conway’s law as I put this write-up together, the more often overlooked observation that the design organisation structure doesn’t just direct the design, but actually constrains the set of designs that can be contemplated strikes me most forcibly. Every person you add reduces your design options.

Perhaps the most important thing therefore, is to "keep design organisations lean and flexible." Flexibility of organisation is important to effective design, because the design you have now is rarely the best possible for all time.

And so finally, in the 3rd to last paragraph, we find the formulation that has come to be known as Conway’s Law:

The basic formulation of this article is that organisations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

[^1]: Conway refers to the military-style organisational structure of each individual having at most one superior and at most approximately seven subordinates – pretty much the rule of thumb we still use today.