The Conway's Law Edition

Noah here. If you’ve ever built websites for large companies, you can surely relate to the challenges of nailing down a primary nav. The top nav is seen as the primary method for users to find what they’re looking for, and so the links that appear there will have the most juice in attracting customers. In some situations, this leads to a massively bloated top nav, where every part of the organization has managed to position itself as critical enough to merit top billing. At other times, the top nav is shaved down to just a few sections—shop, learn, and support, for instance—that ultimately represent a company’s essential functions (and leaders).

WITI Classifieds:

We are experimenting with running some weekly classifieds in WITI. If you’re interested in running an ad, you can purchase one through this form. If you buy this week, we’ll throw an extra week in for free on any ad. If you have any questions, don’t hesitate to drop a line.

Parlance is a Brand Voice Advisory Studio. We Help Make the Impossible, Relatable. Say Hello

Tempo Rubato is a live classical music venue in an old factory shell in the backstreets of inner city Melbourne. Follow us on Insta

My Next Electric is a hella-fun online crash course about how to move from gas to electric cars and stoves. Sign up for a class

Noah here. I've got a new newsletter about brands and AI called BrXnd Dispatch. If you're in marketing, creative, or just interested in understanding what's up with AI, check it out. Subscribe to BrXnd Dispatch

No matter the approach, what is almost always true about a corporate website’s primary nav is that it is representative of the company’s structure in one way or another. Shop, learn, and support represent sales, marketing, and support, respectively. Each of those departments has enough pull to be worthy of mention on the page’s primary real estate. As much as companies like to talk about user-centered design, many websites are more a reflection of the company’s org chart than any kind of deep insight into a customer.

Why is this interesting?

Many years ago, computer scientist Melvin Conway noted this reflection in what has now come to be known as Conway’s Law. “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,” Conway wrote in his 1968 paper “How Do Committees Invent.” This was later shortened to “systems resemble the organizations that produced them,” and Conway’s point, which went well beyond page navigation, was that the choices we make before we start designing a system fundamentally shape the final output.

In some ways, the concept is not entirely different than Churchill’s observation that “We shape our buildings and afterwards our buildings shape us” or John M. Culkin’s view on media that “We shape our tools and thereafter our tools shape us.”

The question of why this kind of mirroring occurs is not entirely clear. One of the more interesting theories is called “the mirroring hypothesis,” which boils the concept down to time and energy saving:

The mirroring of technical dependencies and organizational ties can be explained as an approach to organizational problem-solving that conserves scarce cognitive resources. People charged with implementing complex projects or processes are inevitably faced with interdependencies that create technical problems and conflicts in real time. They must arrive at solutions that take account of the technical constraints; hence, they must communicate with one another and cooperate to solve their problems. Communication channels, collocation, and employment relations are organizational ties that support communication and cooperation between individuals, and thus, we should expect to see a very close relationship—technically a homomorphism—between a network graph of technical dependencies within a complex system and network graphs of organizational ties showing communication channels, collocation, and employment relations.

In other words, as long as people need to work together on problems, it makes a decent amount of sense for the solutions to bear some resemblance to the teams responsible.

So what can and should organizations do about Conway’s Law? One answer is nothing. After all, it may well be the best way to design a system for that organization/problem. Another approach is to find an appropriate balance. If you buy the idea that some part of mirroring/Conway’s Law is simply about making it easier to understand and maintain systems, then it’s probably good to keep some mirroring. But it doesn’t need to be all or nothing. In the aforementioned mirroring hypothesis paper, the authors have a nice little framework for thinking about different approaches to mirroring depending on the kind of business:

As you see at the bottom of the framework, you have option three: “Strategic mirror-breaking.” This is also sometimes called an “inverse Conway maneuver” in software engineering circles. In this approach, you adjust your organizational model to reflect the system you want to build. Design first, re-org second. 

In the end, like many things, being aware of the existence of Conway’s Law and some of the approaches to dealing with it is probably the most important piece of the puzzle. (NRB)

—

Thanks for reading,

Noah (NRB) & Colin (CJN)

—

Why is this interesting? is a daily email from Noah Brier & Colin Nagy (and friends!) about interesting things. If you’ve enjoyed this edition, please consider forwarding it to a friend. If you’re reading it for the first time, consider subscribing.