Conway's Law: Corporate Structure Is Vital to Product Development
In 1967, the computer scientist Melvin Conway made a key observation about organizational structure.
The way that a team communicated and the design of that team’s products, Conway argued, were mirrored — one always reflected the other.
A droll illustration of Conway’s Law. Source: Manu Cornet, bonkersworld.net
In a simple explanation of Conway’s thesis, there are two pieces of software: software A and software B. If the developers of these two pieces of software don’t communicate, there’s no easy way for the software to integrate.
When communication between the developers occurs often and openly, on the other hand, the odds of a seamless experience are far greater.
HOW APPLE PRODUCES AN END-TO-END CUSTOMER EXPERIENCE
At Apple, teams are organized according to what’s called the Unitary Organizational Form. The basic idea — rooted in Conway’s Law — is that the company should be organized around functional expertise rather than products.
That means that instead of dedicated teams for products like the iPhone, the Mac, or the iPad, Apple has teams that work on design, teams that work on engineering, teams that work on marketing, and so on.
This structure encourages coordination between teams and helps Apple deliver a unified experience across products. No product is ever released that departs from the predominant Apple design, engineering, or operational paradigm. Even its credit card has an unmistakable Apple “feel.”
After the iPad first launched, Steve Jobs said this “post-PC device” needed to be “even easier to use than a PC” and “even more intuitive than a PC, where the software and the hardware and the applications need to intertwine in an even more seamless way than they do on a PC. We think we have the right architecture not just in silicon but in our organization to build these kinds of products.”
Reorganizing Apple along functional rather than divisional lines was one of the first things Jobs did upon returning to Apple in 1997, and his successor at Apple, Tim Cook, still attributes the success of the company’s products to this move.
“We’ve found a way to make our products such that the experience is jaw-dropping,” Cook told Businessweek.
WHY GITHUB IS STRUCTURED LIKE AN OPEN-SOURCE PROJECT
GitHub provides an example of a company that obeys Conway’s Law while doing so in a remarkably different way from Apple.
Instead of integrating in order to promote an end-to-end experience, GitHub is intentionally structured like one of the open-source projects the service hosts: decentralized, autonomous, and asynchronous.
That structure reflects the kind of product GitHub has built — one designed for developers more than managers — as well as how that product works.
The GitHub tool is built for asynchronous collaboration: new code can be submitted anytime from anywhere, then reviewed at the responsible party’s leisure. Developers across the globe can use GitHub to collaborate on a project without having to deal with overlapping codebase changes or inconsistencies between their work.
The company itself is also built for asynchronous collaboration, with many of its basic organizational tenets ripped directly from the processes of open source development.
There are no codified standards about what time to come into the office, and most work is completely self-directed. “If you’re interested in working on something, then work on it,” wrote Zach Holman, one of the first engineers at GitHub.
Members of the team are spread out across the world, there are no daily stand-up meetings, and most of the communication they have with their colleagues happens asynchronously, over chat or email.
Collaborating asynchronously to the extreme is a way for the team at GitHub to stay close to one of the biggest problems they want to solve with the company: the difficulty of collaborating asynchronously when working on software projects. One of the ways they take on this problem is through “open, easy-to-use platforms” — precisely what GitHub itself is trying to build.
Apple, in other words, uses an integrated organization in order to build products that give the customer a seamless, end-to-end experience. GitHub uses an organization structured like an open-source project because its goal is to give its user base of developers a collaboration platform that allows distributed, decentralized teams to build great products.
Conway’s Law helps explain not just how companies operate — and how their structures enable or hinder business activity — but also how they are managed.
As computer scientist Fred Brooks (we were at IBM in the mid '60s) has pointed out, for an organization that provides some good or service, the structure that it naturally takes on as it grows is unlikely to be the ideal system for delivering that offering. Remaining flexible is essential to the organization’s structure.
The people that run companies, in other words, must consider organizational design on a similar level as operations, R&D, and products. Much of what we attribute to the latter is rooted in the former.