I am planning to do occasional interviews on this blog with thought leaders in the field, both consultants and academics.
The first person out is Paul Tremlett, a Canadian consultant and member of a community of practitioners called the Global Organization Design Society. This community is devoted to the application and further development of the so-called Requisite Organization (RO) theory proposed by Elliott Jaques.
Jaques was quite insistent that he had found the right way to design the ideal organization. So I decided to challenge Tremlett to participate in a blog interview – and clarify: How can RO help us solve tricky role/reporting issues that we are confronted with in complex organizations?
Instead of discussing generalities I wrote two mini-cases and will ask him during the interview how he would approach the situations described. The cases are based on issues that we have discussed during my previous client engagements (to fit each example into one page I have simplified as much possible while trying to keep the essence).
You can read the cases below.
The interview will be posted here in about one week’s time.
I am not asking about how many pages or slides you need to show the “boxology” – that is, who reports to whom – which usually requires only one page. What I am thinking about is the number of pages you need to explain:
- Who delivers what to whom
- Who collaborates with whom
- Who lends resources to whom
- Who decides what
A real example – drawn from an internal document – is shown below. This is an attempt to clarify the roles in a major UK bank. My first impression was that it seemed like a rather good example of how one could clarify the roles of an organization. When there is confusion with regards to roles and responsibilities, managers and employees usually welcome efforts that can help clarify who is responsible for various decisions and tasks. A matrix like this may be a good pedagogical tool.
But when examining the document a bit more closely, I noted that the matrix contains no less than 245 cells (5x7x7) as the responsibilities (“Approach”, “Inform”, “Advice”, etc. along the top) depend not only on the particular phase in the sales process but also on the channel and product. The accompanying Word document explaining the logic of the chart shown above runs to more than 60 pages. And we are still only talking about one of the issues mentioned above – who decides what. I assume that it would require several hundred pages to fully describe the organizational model of this bank.
One may wonder whether employees are able to internalize and enact a model that is this complex. If nothing else, it is hard to communicate a model that have a lot of contingencies and exceptions to a general rule (“Unit X is normally responsible for customer contact, but if it is a segment B client requesting service 1 for Region 2, then Y is responsible, and if it is a segment C client requesting service 2 in Region 3, then Z is responsible, except when the client already has a relationship with X…”).
In my experience, a better approach is to start by looking at the overall organizational model and consider whether it can be simplified. Are goals in conflict? Are there overlapping unit mandates? Does the formal structure match the work processes? Do we know who’s the internal client, and who’s the internal supplier? If the overall model is clear, logical, and simple, there’s usually less of a need for detailed specification at lower levels.
I am not suggesting that one should practice “simplification by ignorance”. Complexity will not go away by refusing to describe it (for example, by only presenting a new organization design by means of an organization chart showing reporting lines, leaving out other important aspects, and asking employees to find their way through the maze one has created.) If it really takes 60 pages to describe roles and responsibilities in your organization, that is the number of pages you should use. But if you have a choice between two models, one that can be explained in 10 pages and one that requires 60, select the former.
I recently completed a project for an NGO where I assisted an internal working group in developing a new organizational model for the NGO head office. This NGO carries out long term development and emergency assistance, and the head office comprises experts in various fields (e.g., logistics, water supply and sanitation) as well as so-called program coordinators who support development projects in Africa, Asia, and Latin America.
Two alternative organizational models had already been developed before I became involved. Yet the challenge was that the two models had only been described at a high conceptual level, which led to a lot of questions from managers and employee representatives, who could not understand how the new models would work.
In addition, there were also several open issues that had not been closed. For example, the models left open the question of how to organize one of the key teams – the emergency preparedness team (which assists country representations when there is a disaster): Should it remain as a team or should the people in this team be transferred to other units?
The deadline for concluding the design process was approaching fast, so we had to find a way to quickly address these challenges. During one working session, we decided to map the entire structure of one of the main departments using Post-it notes. We used the following procedure:
-
Each sticky note represented one position/role, for example, Advisor or Assistant (we wrote the name of each role on the note)
-
We used different colors for different categories of roles, for example, we used red for line managers and two shades of green for two types of subject matter specialists, and blue for the roles within the NGO’s emergency preparedness team.
-
We placed the notes on the board to indicate how the team groupings in the two alternative organizational models would look. I took the picture shown above with my phone camera during the session, and it shows one organizational model mapped on the left board and another on the right board.
-
Once we had mapped the two alternatives, we started playing with various modifications that we thought could improve the overall design further.
Both the client and I were surprised by the speed at which we are able to come up with new ideas using the method.
When the proposal was presented later by means of a Power Point presentation, we chose to keep the same color scheme as we felt that it helped us communicate how the different categories of roles would be grouped in the new model (see example below).
I think there are three reasons why this approach is so effective:
- It forces you to do a “reality test” of conceptual models that may only have been presented (and understood) at a high level. Rather than talking about how great it would be to have a “process based” or “geographical” or “customer oriented” organizational model, you specify the details of the model and also get a sense of how easy or difficult it would be to implement it (the color coding is important as it makes the key changes implied by the model obvious, such as the distribution of the “blue” team shown above).
- Working together using the wall creates a better group dynamic compared to the endless point-counterpoint discussions that tend to ensue when seated around a table and listening to someone’s presentation. Instead of discussing, we design something together!
- Having the basic building blocks defined in advance facilitates a creative process where you may quickly combine and re-combine the building blocks until you have a good “constellation”. (By the way, when designing the overall structure for a larger organization, each sticky note could represent a sub-unit or team rather than a role as in this example.)
In fact, if you first do a session with Post-it notes and then go to your desk to draw some illustrations using PowerPoint, if feels like walking in a bed of glue in comparison. Instead of using a few milliseconds to stick a note to the wall, it now takes several minutes to draw and align a box properly, adjust the fonts and formatting etc., and that may add up to several hours (or days) before a complete presentation is done.
Nonetheless, it is also important to document ideas and solutions electronically so that they can be stored, distributed and communicated. So I am afraid we need to keep PowerPoint in our tool box until something better comes along.
I should add that although the sticky note approach encourages improvisation, it needs to be well planned and well timed. It is no use starting to restructure units in this manner unless you have basic information about how the organization works or what the goals of the exercise are. In my experience, a session like this is most useful somewhere in the middle of a design process, at the stage where the goals are relatively clear and when you have started to formulate preliminary ideas for new design solutions.
Related post:
Participative design processes: The case for “low tech” workshops
There are quotes that summarize a lot of organizational design wisdom in a single sentence. In the document posted below, I include six quotes that I particularly like and briefly explain how I interpret each of them. Let me know what you think.
Happy holidays and best wishes a well designed 2012,
P.S. If you haven’t seen it yet you may also take a look at my earlier post about metaphors.
Most of the clients I work with are concerned about finding the best possible organizational model, given the particular strategic goals they pursue and the constraints they face. Yet some also mention to me that they believe reorganizing the firm will be beneficial in itself.
There’s actual some support for this view in the academic literature (although I have not come across any empirical research). The key idea is that complexity gradually increases in most organizations (see my earlier blog post about this topic). Over time, organizations tend to add units, layers, processes, and systems. Increasing bureaucracy means that things move slower. More complexity may also lead to more stress and conflict within and between sub-units of the organization.
In his books about complexity and design, MIT professor Nam Suh has explained that we can observe periodic behavior and reinitialization in many technical, biological, and human systems. He uses airline scheduling as a case. Airlines can reinitialize the system by moving planes down during the night. All of the uncertainties that accrue during a day (delays, maintenance issues etc.) can then be terminated to ensure that they do not extend into the following day. Professor Suh claims that such periodic behavior is critical in order to avoid the build-up of unnecessary complexity.
Maybe a reorganization is a bit like this. I am not saying that the particular organizational model that one selects is irrelevant – in fact, I think it is critically important – but the mere act of reorganizing may have some positive benefits too. When we reorganize we break up established patterns. We regroup units. We place people into new roles – sometimes people whose skills and competence were neglected in the old structure. Although any reorganization certainly has a cost it may also help ensure that the complexity of the past is not carried forward into the future.
