Amateurs Talk About Product, But Professionals Study Org Charts

Way back in 1967, when software development was the domain of giants on whose shoulders we stand today, Melvin Conway made the following observation:

What is an organization's communication structure?  To a first approximation, the communication structure is the org chart.  Here are some very serious and accurate examples:

Now, you are probably quite familiar with organizational charts, and you may even have some considered opinions about how useful they are.

But, Melvin Conway's law is telling you that your org chart has quite a lot to do with how your product will get built.  Why?
 

The logic here, essentially, is that certain communication pathways within your organization are lower bandwidth than others.  Even with the best of intentions, two people on very different teams within the same company can struggle to establish enough common ground to really exchange much information with each other.  I'm sure you've experienced this phenomenon.

Because of this, there is a natural tendency to architect your product around these difficult, or at least lower bandwidth communication channels.  One way to do that is to separate the product into components and have those components interact with each other in well defined and limited ways. 

This can have pretty profound effects.  For example, Amazon's org structure made AWS almost an emergent property of Amazon's business rather than a deliberate strategy.  Amazon, famously, organizes itself into two-pizza teams.  The idea is that each team should be small enough to be fed by two pizzas.  What went along with that was a mandate, back in 2002, that these teams needed to expose their data and functionality to each other through service interfaces.  Which is essentially a fancy way of saying that each team needed t0 publish the inputs they would accept, and the outputs that are expected.  Amazon did not care about what technology its teams used to implement their service, but the communication between teams would be done through service interfaces.  This takes the approach of channeling communication within well defined interfaces to its logical conclusion.

I believe that, back in 2002, this edict was primarily about preserving the ability to organize Amazon into two-pizza teams.  Without this service interface approach, as Amazon grew, any two-pizza team would quickly be overwhelmed by the task of keeping up with the communication with all the other two-pizza teams.  With it, Amazon was able to build out another service which was a directory of its services and the inputs and outputs associated with them.  Then all of these teams could simply discover the interfaces for all the other teams and use them.  The way to preserve two-pizza teams was to tell each team that it should treat all other teams as black boxes and provide a black box interface that all other teams could use.

This organizational structure, which prioritized the two-pizza teams, had the result that the task of creating AWS was approximately equal to the task of exposing some of Amazon's internal services to the public.  That's a much simpler (not simple) task than trying to create a cloud computing infrastructure from whole cloth, as others had to do.

There are certainly pros and cons to Amazon's approach.  For one thing, AWS can't really be said to have a single user experience.  There are many different user experiences, almost one for each AWS service and that can be disorienting.  For another, the documentation on AWS is centered around each individual service.  But, most AWS users want to stitch together at least a few different services.  It's often better to search the Internet for examples about how to knit AWS services together rather than try to find the answer within AWS' own documentation.

And I know many of you are mapping this entire post on to the running discussion about the trade offs between microservices and monoliths.  That's an important discussion with lots of implications for development, operations, testing, scalability, etc. etc. 

The point here is that we think that these strategic choices about the tradeoffs between scalability, flexibility, consistent user experience, technical architecture, etc. are made by product people who are thinking about product market fit in partnership with engineers thinking about the right technical implementations to support the product goals.  We, quite rightly, lionize people who can craft insanely great products.  It's hard to do!

When you think about org charts, you probably don't associate them with Steve Jobs levels of awesomeness, do you?

But Melvin Conway and I are here to tell you that the way you structure your organization has a huge impact on the space your product leaders have to operate in.  There's a well known, but no-less fantastic quote (which I hope I am quoting accurately):

That thought really applies here.  Before your product team can start thinking about how to craft your product, and how to achieve product-market fit, your organizational structure has determined much of the structure of your product.  Just as logistics sets boundaries on the tactical and even strategic choices available to armies, so do organizational structures set boundaries on product teams.  So, if you separate organizational structure decisions from your product decisions, don't be surprised if your product leadership runs into frustrating barriers that product-oriented frameworks, tools and training are ill-equipped to solve. 

It's worth remembering that among the very first decisions Steve Jobs made about the development of the original Macintosh was that the Macintosh team would be in its own space, set apart from the rest of Apple.  They even took to flying a pirate flag, to demonstrate their willingness to go their own way.  I'm not sure how or even if this structure was reflected on Apple's formal org charts, but I am sure that it had a profound effect on the development of the Macintosh.

Startups, in their earliest stages, don't have to worry about many of these trade offs.  At the beginning, your team is small enough to support high bandwidth communications among just about the entire team.  But as you grow larger than hunter gatherer bands, you'll need to make decisions about how to structure your organization because our natural methods of group organization, being adapted to groups of hunter gatherer size, can no longer fill the gap.  Many, if not most organizations think about their own internal needs when they make these choices.  But as we know, because Melvin Conway taught us, those choices also impact your product design, your product market fit and your customer.  Choose wisely!