In 1968 Melvin Conway wrote a paper that contained the following statement:

organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations

You might already know this as Conway’s Law.

Or maybe you’ve heard someone say “Don’t ship the org chart!” which, roughly, points at the same problem: your organizational structure has an effect on the software the people in the organization produce and ship.

Think about it: the structure of an organization – who’s in which team and how they talk to other teams, who needs to report to whom, and so on – has an effect on the software it produces. No, really, think about it: it’s not about the individuals, their talents and skills; it’s purely about the structure.

That’s kinda mind-blowing, no? One would think that software, “only slightly removed from pure thought-stuff”, stands above such earthly constraints such as how the people who write it talk to each other. And yet, it happens.

A couple of years ago, people said that you can see the org chart when you open the Spotify desktop app. It looked like there was one team responsible for building the desktop app hull, the skeleton, and other teams built the separate views inside the app. One team built the search view, another one built the home page, another one built the artist page, and so on.

I’ve heard the same thing being said about Facebook from 10 years ago: one team built the news feed, another team built the events page, another one built groups page, and then there were teams for the games, for photos, for messenger, and so on. In the navigation bar on the left side you could see a list of engineering teams.

When I first heard about Conway’s Law, I shrugged it off: yeah, makes sense, I guess? The companies I worked at were either so small that there was no org chart inside the engineering org to speak of (all of engineering would fit into a single team at a FAANG company, I bet) or the org chart was dictacted by the product itself.

We built SaaS web applications that served three clients: an iOS app, an Android app, and the web frontend. There’s your org chart right there: one backend/web team, one iOS team, one Android team. Done. What’s next on the agenda? I didn’t have a strong feeling of the org chart influencing our product, because, well, we did want an iOS app and an Android app, right? There was no friction between what we wanted to ship and the org chart.

Looking back, though, I can see Conway’s Law standing in the corner of the room, smiling, waiting, while we were idly discussing whether web frontend should be a separate team from our backend team.

Now, years later, I’m starting to think that Conway’s Law might be the most powerful law in software. I spent the last four years working at Sourcegraph. Joined when we were around twenty employees, now we’re in the hundreds. I’ve seen Conway’s Law.

One part of the product well-engineered, another part dormant – one had a team, the other didn’t. Bug reports that fall into the cracks and disappear, because there was no clear team to assign them to. Directory structures and filenames that make you think of the org chart. Teams kicking ass because they can focus on their own slice of the product, undisturbed by the concerns of what goes on over there, or over there.

Again: one would think that software – intangible, weightless constructs that can be willed into existence, shaped to match dreams, sent around the world in a second, destroyed or replicated millions of times, all with a single push of a button – floats above it all. But is there a greater force in the room in which software is written than the person writing it? And don’t we all know that, while we say we aren’t, we are influenced by which title you give us, which role we are supposed to play, who we work with, what we are measured by?

We also know what happens to a codebase when you hire someone who’s really, really, really into functional programming right now; or when an ex-Java programmer joins a Ruby team; or when you hire a DevOps person that loves Kubernetes and doesn’t really love your simple Heroku stack; or what your admin area will look like when it’s owned by engineers that dare not to touch CSS or JavaScript.

That is Conway’s Law, but zoomed in. Zoom out: what happens to a product and engineering org, when you say there shall now be a dedicated frontend team, or a dedicated SRE team, or a Q&A team, or a platform team, or a Kubernetes team? Your product will look like it.

It’s the most fascinating thing to me: Conway’s Law is not just something that happens to you, it’s something you can see and influence and steer. If you’re building a new product, the structure of engineering teams you decide to have will have much influence on the product as any wireframe.

There’s a million interesting things to ponder: how long does it take until the org structure puts its stamp on a product? Are some products easier to influence than others? Don’t the platforms you deploy to already give you an org chart to start with? What about the programming language and its tooling? Aren’t there individuals who escape the constraints of teams and put their own unique brand on the software, no matter who they report to? Where do you put them, to maximize effect?

Pure thought-stuff, indeed, man.