Why a simplistic approach won’t help in simplifying a complex organization

Leaders of large organizations are increasingly aware of the risk posed by internal complexity. The challenge of simplifying organizations is drawing increasing attention from business gurus, authors and consultants. One key “thought leader” is Ron Ashkenas, a partner in the US consulting firm Schaffer & Associates, who wrote a Harvard Business Review article about the issue in 2007 and also more recently a book, “Simply Effective”, where he recommends that managers “streamline the organizational structure”.

Askhenas invents some creative words and concepts, for example, he refers to the tendency to add organizational units, layers and locations as structural mitosis. I also like that he points out that complexity may be self-inflicted – managers (indeed, all of us) at times create unnecessary complexity that could have been avoided.

On the other hand, I have some doubt that the solutions he promotes actually would help to simplify organizational structures.

In his Harvard Business Review article, Ashkenas cites a company that reduced complexity by transforming the structure from one of autonomous business units to “an integrating operating company”. He also presents a checklist for managers, where one is asked to rate, among other things, how many layers there are between the CEO and first-line workers, with possible answers ranging from “seven or fewer” to “more than ten”.

But why would an “integrated operating company” necessarily be less complex that one consisting of autonomous operating units? In fact, if integrated means more centralized, isn’t it likely that it would lead to a higher level of complexity, for example, if local units become unable to make key decisions without consulting higher level managers?

Many of his other suggestions focus on reducing variety that create internal complexity, for example, cutting the number of product variants, services, or features.

This advice is similar to that found in some other popular books. It is fairly common to equate complexity to variety (the number of units, levels, products etc). This thinking leads to the conclusion that you need to reduce variety to become less complex. This may certainly be relevant in some cases (I do believe that structural mitosis is a real phenomenon).  It is quite possible, however, to produce an enormous variety of product models, yet maintain a relatively low level of complexity internally – thanks to standardization of components and interfaces (that is, so-called modular product and process platforms). 

I think the reason why Ashkenas ends up with this conclusion is that he starts out with a wrong definition. According to current definitions used within engineering and the systems sciences, complexity is not variety but the existence of multiple, unknown or unpredictable links between different goals and processes, something which reduces the chance of reaching business objectives.

In fact, the goal could well be to maintain the exact same outputs (e.g., the same number of product variants, services, etc.) but with lower levels of internal complexity – allowing the firm to increase quality, reduce risk, and generally increase the predictability of its operations.

As for the checklist in the Harvard Business Review article, it is of course meaningless to talk about there being one correct number of layers in an organization; a larger organization, or one requiring more active employee supervision, will obviously need more layers from the CEO to first line workers than other organizations. Complexity is always a relative concept. To determine the required number of levels in an organization, one has to start by considering the key characteristics of the organization including the people employed and the type of work they perform.