Shipping the org chart

“Your products will mirror your organizational structure. Embrace the fact.”

The expression “Don’t ship the org chart” (generally credited to Steven Sinofsky of a16z, formerly Microsoft) is frequently used as a word of warning in product development circles. It refers to how products are shaped by the inclination of development teams to limit the solution space through arguments like “that’s the responsibility of department X, not us”. But users and customers do not care one bit about the organizational hierarchy of your company.

In some cases the consequences are so severe that someone with no knowledge of the company could make a pretty accurate guess at the org chart simply from using the product. The worst example I have seen is illustrated by this Walt Mossberg review of the Samsung Galaxy S7, where not only the company, but also the industry “org chart” is painfully apparent:

Out of the box, there are two email apps, two music services, two photo-viewing apps, two messaging apps, and, except on Verizon, two browsers and dueling wireless payment services. (Samsung says Verizon barred including Samsung’s browser and Samsung Pay out of the box.) And Verizon builds in a third messaging app.
The setup process also guided me to using Verizon’s messaging app rather than Samsung’s and a Verizon backup service. It even warned me I might lose important stuff if I didn’t sign up for the Verizon service.

This user experience is the result of Google, Samsung and Verizon (and sub-divisions within them) all making product decisions based on what is important to them, not what is important to the user.

In the technology industry we often also discuss the impact of the org chart in the context of “Conway’s law”:

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interfaces structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult.

Like “Don’t ship the org chart”, Conway’s law is often brought up as something to watch out for. As potentially destructive. And it can be. But I prefer to view it as something extremely powerful, but not with a will of its own. It is a neutral force.

There is no such thing as a good or bad organizational structure. No right or wrong. An organizational structure can only be evaluated in the context of the problem the organization is intended to solve. But the chosen structure can have a massive influence on the organization’s ability to deliver the output necessary to solve it.

Certain things come more naturally within a branch of the hierarchy than across branches. Most importantly they are:

1. Communication

Communication flows much more easily within a branch. And as illustrated by Conway’s law, the impact of efficient communication is profound.

2. Decision making

Decisions can be made swiftly within a branch, but to get someone in another branch to agree on something (especially if their goals are not aligned with yours) one generally has to go all the way up to the ladder to the manager where the branches meet. If one even bothers to attempt it at all, it can take a lot of time and effort, and important information is almost inevitably lost in the process.

3. Community

A sense of belonging is one of the most powerful human motivators. We all wish to be part of a group. When implementing a new org structure, in no time at all your own branch becomes “us”, everyone else “them”. And within a community the individuals will have a higher willingness to trust, to give the benefit of doubt, to provide assistance purely out of generosity, and to forgive. In a knowledge company, such “social capital” is absolutely essential for performance. Margaret Heffernan explains it well in this Ted article:

“Building social capital makes organizations more productive and creative because high levels of trust create a climate of safety and honesty.”
“In organizations with high degrees of social capital, conflict, debate and discussion are the means by which it gets better.”
“Helpful teams of people accelerate the sharing of knowledge and expertise; they don’t let one another stay stuck or confused; they try to prevent problems before they arise and they won’t let colleagues become isolated or cut off.”
“Trust, helpfulness, practice and courage become the simple renewables that power our working lives.”

I don’t mean to imply that good communication, swift decision making and high degree of social capital is impossible to accomplish throughout the organization as a whole. But it takes more time and effort to build it across branches, and the level reached will never be quite as strong as within smaller teams and departments.

As a consequence of these forces, a given organizational structure will make some things easy, other things hard. One of the most important tasks of management is to identify what output is most important, and then shape the organization so it is aligned with producing exactly that.

This “optimum” organization will still experience undesired side effects from the siloing effects of the org chart, but now in areas which are less damaging. And somewhat counterintuitively, from the moment a new org structure is implemented, management should shift much of their time and focus to these seemingly less critical areas. After all, everything that falls within a branch, will be “easy” and employees are enabled to succeed without manager involvement. It is when they have dependencies across branches they need help, and measures such as culture, goals, incentives, mandates and processes can provide it (more about those in subsequent posts).

So rather than “Don’t ship the org chart”, my takeaway is “You will ship the org chart whether you like it or not, so make sure it works in your favor!”.