People create architectures that mirror their communication structures

AKA Conway’s law.

Sometimes, when I am confronted by people who haven’t thought deeply about systems, they accuse me of overthinking things. “Sarah,” they ask, “Do we really have to do any architecture? I’ve worked on things without thinking about architecture for years. Don’t things just happen?”

Oh things sure do happen. And in 1968, as Xerox was gearing up to control the architecture of information, a young mathematician named Mel Conway was noticing some things about how they happen. 

He wrote his theory up and submitted it to the Harvard Business Review, which rejected it for being unproven. So he published it in Datamation, an industry magazine aimed at people “doing” computers professionally, which in 1968, was not a big group of people.¹ ⊕ ¹ Incidentally, in looking Datamation up in The New Hacker’s Dictionary, I found out it apparently used to be quite the burn to ask, “Did you read that in Datamation?”

So in Conway’s paper, he makes an observation: “Things” do happen. In fact, they happen in an extremely predictable way. He argues that the act of organizing humans predisposes those humans to a certain answer to any architectural problem they encounter. Very simply, “Conway’s Law” states that the architectures people make will mirror the structure they already have: the social structure they already have.

You see this all the time. The “default” choice as you arrange a website is a menu item for each team. I worked on a website for the boating company, West Marine, once, and they had a category for “Coolers, Bikes, and Boating Accessories.” I couldn’t make this up, here’s a screenshot. It had a subcategory for “Bikes, Seasickness, and Sunscreen.” How does this happen? In West Marine’s case, it was because one guy was in charge of all those things, so that category was basically just “Kevin’s stuff.” But: Can we really blame Kevin?

Conway says no. Once you are doing something more complex than an inventor tinkering in their garage alone, you’re getting a group of people together to solve some problem, to make some defined thing happen. By defining a problem and getting some people in order to solve it, Conway argues, you’re doing some major architecture. That architecture removes lots of solutions from your options, and the thing has barely been defined. 

So, for example, If you have a group organized around writing a paper about Library of Congress Subject Headings together, you’re unlikely to end up with a presentation. That stands to reason. But what this also means is that if you, as you’re organizing your group to write that paper, assign one person to cover the history, another to cover the current state, and a third to cover interactions with other indexing and classification systems, you’re going to end up with a paper that has those major sections. You won’t end up with a paper organized around themes, for instance, drawing on all three. And maybe that’s okay, but you made that decision before you knew anything about it. 

To be clear, Conway is not arguing that the assignment will make you divide yourselves that way, the argument is that dividing yourselves that way will lead to a similar structure in the paper. If you have a group organized to solve a problem, you have a basic architecture, for better or worse. And every time you delegate again, this process continues. 

Let’s imagine this paper really gets out of hand (I know this isn’t how group projects work, but it is how jobs work, so bear with me,) and you realize that the history section is really going to be a beast, we need to get someone in here to help with this. How do you have them help? You carve a piece off, say, here: You do history since 1960, I’ll do the part before. What do you think that’s done to the structure of your paper?

The upshot here is that for both the initial scoping and every subsequent architectural decision someone makes, there is a family of solutions that could work. Who knows which of them is the best? For that paper, what would the most effective structure be? We don’t know, because it’s going to have the one that’s already decided. But it’s not just that this is done in one fell swoop as you assign things. There’s nothing actually stopping you from putting a paragraph in someone else’s section of the document, so there are ongoing structural decisions being made. 

Conway argues that those decisions will echo the communication structures of the people making them. Going back to our paper example, this is easy to see. If you’re writing the current state section of your paper and your roommate is writing the connections to other systems sections, you two might talk about it and trade some ideas back and forth, creating a connection. If the other members of the group hardly know each other, they’ll probably keep to their own sections more. 

This is because communication between nodes takes longer than communication within a node. This makes sense, it’s basically free for you to think about something, but if you have to work with another person, that takes time, energy, scheduling, the chance of being misunderstood, etc. That carries on with larger nodes. It’s easier for your group to communicate among yourselves than it is for you as a whole to communicate with another group. It’s easier to communicate in your household than with another household.

The higher the cost of communication, the less work will happen across that gulf of communication. So the further two things are in a social structure, the less you expect them to have to do with each other, because it takes too long and too much effort to make them be interdependent. I’ve seen this happen time and again in my work. 

When I worked at Microsoft, the site I worked on had both documentation and training on it. But it also had a lot of other things. One of those was code samples. These are bits of code that someone at Microsoft has written to do something or illustrate something, with the idea that you should be able to copy and paste it into something you’re working on, and it’ll work. Developers love these, they’re a great way to illustrate how something works. So we built a way to publish code samples and a page to sort and filter them. But the problem was, the person who was responsible for them was on the Documentation team. So when I pointed out that code samples would be useful for training too, the response was always “No, that’s documentation.” When I put it in the navigation at the same level as documentation and training, because it was its own thing, I heard, “No, that’s documentation.” The organization had already made the decision.

This makes me think, because, Conway and most of the people who come after him argue that communication is the central issue here. Things will be the same where there’s easy communication and different where communication is harder, thus giving us a structure. And I don’t think communication is unimportant, but I think they’re all missing something. 

I think this also happens because the conceptual architecture of the domain has already been figured out once. We thought about code samples, and we decided to do them as part of documentation, ergo, they are documentation. We decided to sell bikes and we decided where to do it already, with coolers, obviously.

This happens all the time. The Free Energy Principle is a concept from neuroscience that states the brain is a prediction machine, constantly guessing what’s going to happen next. The thing is, the energy to make those predictions is expensive, so it’s also trying to stop all the time, and assume what will happen next. Psychologist Daniel Kahneman expressed a similar idea pithily, saying “The brain is a machine for jumping to conclusions.” I think this is a little glib, but in this case, it’s saying something important.

Labels, assigning things to a category, function as permission to stop thinking about that thing. And the brain is always looking for a chance to stop thinking about something. So it’s very hard to both put something in a structure and simultaneously keep that structure open and able to be played with. 

So, because of the communication structures and the mental models that organizing people creates, there’s no such thing as a group of people that’s both organized enough to do something and simultaneously free to create the best architecture for the situation. 

References

Conway, Melvin. 1968. “ How Do Committees Invent? ” Datamation.