Posts from the ‘Interdependencies’ Category
If you are a leader contemplating re-designing your organization – ”To separate or integrate, that is the question”: Should units be divided or combined?
In the slidecast embedded below, I discuss how to approach this challenge. It includes a couple of examples from a series of interviews I did with leaders of oil services firms. Any comments would be welcome.
P.S. A slidecast is a presentation with audio, so make sure you have the speakers turned on if you want the narration.
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.
Most people consider organization design principles as rather abstract concepts. How do we bring them to life and demonstrate that they both explain – and potentially inform – decisions about how to design organizations?
One solution is to develop an experiential format, such as role plays or simulations. I have been working on simulation for a long time in order to illustrate some of the core organization design principles such as interdependency and coordination costs.
Yesterday I was able to pilot test the simulation with two groups of 36 students at the Norwegian School of Management. Associate Professor Thorvald Haerem kindly lent me his class who willingly participated. The students quickly understood the rules and impressed me in terms of their ability to make coordinated decisions.
The key idea was to have 7 tables with 5 students, each symbolizing a department, while coloured to-shirts symbolized the work process they performed. Hence the task was to reconfigure the formal structure into a more process-based organization by moving people according to set rules.
In the slide set below you can read more about the purpose and outcome of the simulation. The next step for us now is to analyze the decisions the students made more carefully, in order to evaluate the relative “goodness” of the configuration they ended up with.
The tool I discussed in the post before the Summer (see here) was aimed at improving the implementation of a new organizational design by optimizing the simultaneous staffing of hundreds or even thousands of employees based on their job preferences.
However, there are complex challenges in every phase of the organization design process that deserve to be treated in a more analytical fashion, and that potentially may be supported by software tools.
In the textbook I am writing (to be published by Pearson Education in 2011) I have dedicated a chapter to various techniques for sub-unit grouping – that is, deciding where to draw the boundaries between various sub-units in the organization (departments, teams, processes, projects, etc).
One tool that can be used for this purpose is the Design Structure Matrix, a square matrix that captures interdependencies between various individuals (or process steps) within and across sub-units. An interdependency can be defined in different ways, but for simplicity, assume that it can be defined as need for information, and that one can use “frequency of communication” as an indicator. This is clearly information that is quantifiable (you can ask people to indicate how frequently they interact or interchange information with their colleagues).
Once you have such data you can use the Design Structure Matrix to cluster the roles (or process steps) to identify where the boundaries should be drawn between different sub-units (or roles/process steps).
If you try out these tools, you will probably experience that they raise new issues that need to be clarified; we are still in an exploratory phase in terms of finding out how such tools can add the most value to the design process. But at the same time, I feel that they represent a new and exciting trend in organisation design. Even if design decisions to a large extent depend on our judgment, the tools may improve our judgment by structuring complex information and visualizing data about how the organization works.
The familiar organization chart is still the most frequently used organisation design tool; indeed, many people seem to equate “organization design” with “re-arrangement of the boxes” and this is unfortunately what many organisation design processes consist in – re-naming titles and re-arranging reporting lines.
There’s nothing wrong with organization charts as such – they are useful depictions of the formal structure of any organisation. In today’s complex, network oriented organizations, however, they provide few clues about how work is actually carried out.
If you are to make effective organisation design decisions, you need to figure out what goes on in the white spaces of the organisation chart, to paraphrase the title of a well-known book written by Rummler & Brache in 1990.
This is what I tried to do in a presentation I gave at the Organisation Design forum in 2006. At the time my plan was also to write and publish an article about this topic together with co-author Ron Sanchez, a visiting professor at the Copenhagen Business School. Due to other commitments we were unable to complete it then, but we have now blown the dust of the drafts that we worked on, and are in the process of writing a new paper that elaborates on the concepts mentioned in the presentation.
Please note that we are not saying (as some seem to be thinking) that “structure is out”. We firmly believe that organizational structure is as important as ever, but that 1) the structure needs to be chosen based on an understanding of the business processes and working relationships, and 2) the formal reporting relationships (which the organisation chart depict) are only one of several dimensions that you need to design (and manage, once a unit is established).
You can view the 2006 conference presentation here:
