Uncle Melv

The holidays are coming, for those that celebrate. For this occasion, let me share one of my own family’s old holiday traditions.

One that, I have to admit, was recklessly ruined by uncle Melv in the late ‘60s.

We don’t speak of uncle Melv anymore in our family. We don’t speak of him, nor do we speak with him. In our family he’s generally referred to as the Uncle-that-shall-not-be-named.

You’ll understand why later.

The family tradition I’m speaking of is a family game called OrgChartionary.

In the (unlikely) event that you’re not familiar with this excellent game, here’s how it works:

Everybody sits around in a circle with pencil and paper ready. Somebody is named the Org Master. The Org Master yells out the name of a company.

Then, everybody fervently starts to sketch out that company’s organizational chart on their piece of paper: CEO, departments, teams — that sort of thing. Whoever gets the closest to the company’s actual org chart wins.

It’s educational. You’ll laugh. You’ll cry. It’s just plain old holiday fun.

At least it was, until our uncle-that-shall-not-be-named figured something out.

You look confused.

You seem not to be familiar with this game just yet. Perhaps that’s because uncle Melv got to your family before OrgChartionary could properly take off.

So, let me propose we play a simplified version of this game together. This simplified form is usually something we played with the kids in the family only, but I suppose it can serve as a good way to get started.

This variant is called OrgChartionary Lite.

OrgChartionary Lite doesn’t require drawing, it basically turns the whole thing into a multiple choice exercise. Quite appropriate for today’s TikTok generation. Simplify things as close to plain stupidity as possible. May as well flip a coin. Oh well.

In OrgChartionary Lite, you simply need to pick between two high-level organizational structures:

1. Horizontal: where a company is primarily organized by function, for instance: marketing, sales, design, engineering, QA.
2. Vertical: where a company is primarily organized by product and teams are cross-functional.

Sounds like fun?

I thought so. Let’s go.

Let’s practice with two random examples:

1. Apple
2. Amazon

For each, ask yourself: are these horizontal or vertically organized companies?

Got your answers written down? Good.

Before we proceed, let me get back to that thing that uncle Melv figured out.

In all transparency, uncle Melv was not a “blood” uncle. He was one of those people that had somehow worked his way into the family, and started to be referred to uncle Melv after some time. He was just always there. Somehow. I don’t want to be too cynical about people, but my sense is that he weaseled his way into many families, just to ensure that his bomb drop would have the biggest possible destructive impact on holiday cheer. Like a more nerdy version of The Grinch.

Uncle Melv’s full name was Melvin Conway.

What uncle Melv figured out is now widely known as Conway’s Law. Yes, it even has its own Wikipedia page, so you know it’s legit. Even the most toxic ideas have Wikipedia pages these days.

Here goes, take a deep breath, because it doesn’t roll off the tongue:

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

To be honest, I have various issues with this formulation.

First, its obvious grammar-stylistically questionable use of “which” for restrictive clauses; using “that” would be more appropriate. My second concern is that it is long and uses many fancy words. The more concise version would be:

“You ship your org chart.”

And this formulation also explains why it completely ruins OrgChartionary. And with that: Christmas.

Let’s see how Conway’s Law works in practice by looking at the two companies I just quasi-randomly mentioned: Apple and Amazon.

Apple is a great example of a company primarily organized by function, that is: horizontal. There is a marketing department, there is a design department, there is an engineering department. Each has their own SVP (very old vice president) reporting to Tim.

How can you tell?

When I think of Apple, there are a few attributes that immediately jump to mind:

1. Consistency. All of Apple’s products look and feel Apple-y: they use the same design language, largely the same software, the same hardware components. When you see an Apple product you immediately recognize it as such.
2. Functional excellence. In many of its functional areas, Apple is at the top of its game. Its marketing is very good. Its design is beautiful. Its software quality is good. Its hardware quality (recently especially in Apple Silicon) is unparalleled.

These are all a natural result of organizing by function. The design department communicates a lot internally, they exchange ideas, building on each other, they agree on a singular approach. The result: very consistent and coherent products. Because within their function everybody works closely together, they get ample opportunity to improve their craft. If you’re designing magnet systems for all of your company’s products, you can really invest and excel at it. And Apple’s magnet systems are pretty great.

Everything comes at a price, however. Apple has other attributes too:

1. A (relatively) small product portfolio. Given Apple’s size, the number of products they put out is relatively small.
2. Slow. While Apple refreshes a lot of their products on a yearly basis, most of these updates are quite incremental. Apple usually lags behind competition when it comes to product innovation.

This, too, is a natural result of communication lines. Whereas everything that benefits from in-department communication operates smoothly, anything that requires cross-department communication has more friction. There’s more context that needs to be transferred, there’s more prioritization issues to be resolved. If you need packaging of your next generation HomePod, you may have to negotiate with the design department for priority, because they’re all working on the new iPhone boxing right now. Good luck with that. Shipping any product required multiple departments and a lot of hand-overs and planning. This is slow.

Now, let’s have a look at Amazon.

Amazon (and especially AWS) is a classic example of vertical organization. In Amazon, teams are primarily organized by product units. Inside product units all functional areas like business, marketing, design and engineering closely collaborate to ship their particular (singular) product in a cross-functional (two-pizza) team. There’s a lot of emphasis on having as little dependencies between product teams as possible.

When I look at Amazon, and especially AWS, I see a few very different attributes that jump out:

1. Scalability. Yes, Amazon is a massive company, but their product portfolio is also huge. AWS’s product overview page in particularly hilariously large, but also outside AWS Amazon ships a lot of product ranging from pure e-commerce, to logistics, to hardware (Kindle, Alexa, phones, tablets, delivery drones, ...) and who else knows what.
2. Speed. AWS expands its product portfolio at a rather breathtaking pace. Most companies significantly slow down the moment they get large, not AWS.

These are both natural result of communication lines too, and very deliberate. By ensuring that these product units are as independent as can be, they can make all their own decisions and therefore move very fast. Little cross-team planning and co-ordination is required. You can launch a new product by whipping up yet another product unit without slowing anything else down.

However, this comes at a price:

1. Inconsistency. Just browsing through the Amazon website, the level of inconsistency is almost hilarious. Amazon’s order page (which doesn’t list any Kindle content or Prime Video orders, by the way) looks completely different than your Kindle content page, which looks completely different than the Prime Video section. It’s almost like these are different companies (which they kind of are).
2. Incoherence. If you’re looking for a database solution, good luck making a decision. There are a lot of options, and it’s not always obvious which one to choose. There’s a lot of overlap, and not all services and products work very well together.
3. Duplication. Talk to anybody who works at Amazon and they’ll tell you: oh man, the amount of duplication here is insane. Every team has its own build systems, its own widget libraries.

These attributes, too, can be explained by thinking through what the communication lines look like. If product units do not communicate that much among each other, they have little insight what the others are doing. There’s no “larger plan”, there’s no “let’s do this together” because all of that would come at coordination and would come at the cost of speed. Naturally, you get inconsistency, incoherence and a lot of duplication as a result.

So, which one is The Best™?

This was why my random pick of companies was not so random: both Amazon and Apple are extremely successful. Both models can work. They just lead to very different results.

Most companies work in more hybrid model. They have some horizontal teams (like platform teams, the legal team, finance etc.) and some vertical teams that try to hit some sweet spot between the two extremes. Finding the right setup is an ongoing journey and balancing act.

However, it is worth being aware of Conway’s Law, because it’s a very strong natural force. Once you really understand it, you can strategically wield and compensate for it.

For instance, if you start to notice there’s recurring friction between your team and another, check your org chart. Chances are that you’re fairly far apart.

You can compensate for this, through the magic of network weaving.

The idea behind network weaving is simple: establish a communication line with the other team. Pick somebody on the other end, and start to meet them regularly. Talk about your team’s work and priorities, your struggles and successes, your hopes and dreams. You will see that the empathy between your teams will grow. Whenever you pick up on some potential for friction with that other team, you’ll be able to put it in context and know who to talk to and how to proactively resolve it before it becomes a problem. It doesn’t fix the problem entirely, but it helps.

Again, nothing is free and there are natural limits to this. We cannot network weave with every team or person in the company, this would end up being all that we do all day (don’t check my calendar). You have to be strategic about it.

Another thing you can do is to apply some elements of domain-driven design. Through techniques like event storming, you can uncover bounded contexts which are often natural team boundaries. Based on such analysis you can tweak your org chart to more optimally match your product and company needs and the org chart that backs it.

Another approach is to flip the whole thing on its head and apply what’s called the Inverse Conway Maneuver. Here the idea is to lay out your desired product architecture first, and then deliberately design your org chart to mirror it.

Conway’s Law is of those things where once you truly internalize it, you start to see its effects everywhere.

Especially around the holidays.

There’s this awkward moment where a nice round of OrgChartionary would really fit. But sadly, uncle Melv ruined it. So you’re like, “so what do we do now... a round of tic-tac-toe, perhaps?”

Thank you, uncle Melv.

Happy holidays to those that celebrate!