Posts from the ‘Roles’ Category
In this podcast interview we discuss how the Requisite Organization approach can be applied to address complex role/reporting issues. Paul Tremlett is a consultant with CORE International in Canada.
Before listening to the podcast, it may be helpful to take a look at the brief cases that I wrote last week and that we use as a starting point for the discussion.
Some of the things that we touch on are:
- Requisite Organization (RO) as a broader management system
- The combination of fundamental principles and situational judgment
- The importance of diagnostics in the organization design process
- Why it is necessary to do a full costing of a proposed structural model
- Why there are no “dotted lines” in an organization designed according to RO principles
- Why asking “who should report to whom” may not be the right question if you want to resolve role/reporting issues!
If you want more information about the Requisite Organization approach, take a look at the website of the Global Organization Design Society.
Podcast: Play in new window | Download
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.
In my two last blog posts I discussed the difference between individuals and roles. I decided to focus on this issue as it in many ways is the foundation for organization design. This is particularly clear if you consult Elliot Jaques’ writings. Jaques made this difference clear from the beginning, by pointing out that one should define an organization as a set of roles and not as a collection of individuals. So without the concept of role you can have “people development”, but you cannot have “organization design”. Let me conclude this series of blog posts by considering briefly the issue of fairness.
When planning an organization design process, most people will agree that one should first define roles, and then consider the individuals that might fit the different roles that have been defined. The main rationale is to ensure that the organization’s strategic goals and the design requirements are met, rather than constructing an organization that suit the particular individuals that inhabit key roles today.
Somewhat counter-intuitively, focusing on roles rather than individuals may also be in the long time interest of the employees of the organization. Mixing up roles and individuals tends to increase the level of “politics” in any decision process (I provided an example in my blog post last week). By focusing on roles, one is able – at least in principle – to create a systematic and transparent process where job requirements are explicitly defined and where the qualifications of alternative candidates are evaluated.
I attended a talk by Stephen Drotter (co-author of the Leadership Pipeline) a few years ago where he made a similar point in discussing the role of HR. He said that HR traditionally has focused on the the supply of labor – that is, on people (e.g., by increasing the supply of labor by recruiting and retaining people). He said that the first priority should instead be to focus on the work to be done – on the demand (e.g., by making sure that every job is necessary and adding value, and that every job is properly defined and placed at the right level). He then went on to state that:
“…people are treated better, developed more completely and included more appropriately if our thinking and actions start on the demand side.”
Separating individuals from the roles they hold is an important, but also difficult, and at times delicate challenge. Unfortunately, I have experienced that leaders – as most of us – routinely mix up the two, something which can have negative consequences for the organization as well as for employees.
We won’t be able to separate people and structure completely, for political and psychological reasons. New organizational models will sometimes be introduced simply because they suit the people currently in the organization. Or alternatively, proposals for introducing a more optimal structure may be rejected because they are viewed as controversial in terms of the individuals involved – even if the proposals make strategic sense for the company. But by being more conscious of the issue, we may at least avoid the trap where we confuse individuals and roles unnecessarily.
Let me use a simplified example to illustrate this point. Consider a manufacturing company consisting of two main business units (see drawing below). The largest one is Business Unit A, led by a fellow we’ll call Jim. The question is how to organize Research & Development (R&D), which is currently one of several sub-units within the Support functions. The R&D unit is led by a relatively young and inexperienced manager we’ll call Tom.
Jim has argued for some time that his business unit is the main client of the R&D unit. He has also observed that the outputs that the R&D unit deliver seem more useful the more closely the R&D staff collaborate with his people. For this reason, he believes that R&D should be formally integrated with his business unit. So one option is to move the R&D unit to Business Unit A.
Tom, however, does not share this view. He points out that technology development is becoming increasingly important for the company’s success, and would like to move one step up and report directly to the CEO. So this is a second, alternative option – option B.
Which option is best – how do we resolve this? Well, in fact, often such differences are not resolved at all. The CEO is reminded of the fact that Tom is young and inexperienced. He may thus conclude that “Tom is not ready yet” to become part of the leadership team, and that it is premature to discuss any changes in terms of the reporting relationship. So the process often stops there. Indeed, it is hard for existing managers to raise ideas about organizational changes because they are immediately interpreted as an attempt at furthering their own interests. In this case, for example, both of the options put on the table clearly have political consequences for the managers involved.
However, the downside of inaction is that the R&D unit may continue with a compromise structure that nobody is happy with. Is it possible to reframe this problem? It may be possible if we decouple the individual from the role.
One may first look at the R&D unit and where it is located in the organization. There are two questions that are relevant here. First, to what extent is technology of strategic importance to the company? The more strategic it is, and the more complex the task of the leader of the R&D unit, the stronger the need for raising the unit’s profile and incorporating the R&D manager role in the leadership team. The second structural question is about interfaces. To what extent does the R&D unit need to collaborate closely with the business units in developing new technologies? The more intensive coordination that is needed, the stronger the argument for organizational integration (I have a slidecast about this topic if you want further details).
If such a review concludes that the R&D leader should become part of the leadership team, one may then consider whether Tom is the right person to work at this level. That will depend on his experience, competence, and potential. If he is not deemed as qualified, the logical implication is to recruit a leader, internally or externally, that is capable of leading the unit at the appropriate level for the company.
It’s important to emphasize that separating individuals and roles does not mean that we only take care of the structure and forget about the people. I believe it is the other way around. It is precisely when we are unable to properly separate people and structure that the process tends to become political and frustrating to the individuals concerned. I will return to this issue in the next post.
In a third post on this topic next week, I will discuss the implication for HR if we accept the role/individual distinction.
Distinguishing between individuals and the roles that they hold is fundamental to organization design. But the two are easily confused. I do it myself sometimes.
A few years ago, I was working as a project manager in a large firm and was responsible for acquiring a new IT system. We had evaluated several alternative vendors, made the choice about which vendor to go with, and reached agreement regarding the contract terms. Finally we were ready to implement the system. We had even started communicating to employees the new, fantastic features that they would be provided with.
One key idea was that the system would be integrated with the company’s internal database of names that is used by the Microsoft Outlook program. This would make the system more user-friendly as it would automatically recognize the user. Unexpectedly, however, a man from corporate staff appears outside my office and says that no such integration will be allowed, as it would go against company policy. At the conclusion of the meeting, I remember feeling rather frustrated with this person who was threatening to spoil our project.
However, a few minutes after he had left, I sat down and stared at the business card he had given me. I read the title – Head of IT security. I realized that the person was simply doing his job – which among other things, was to restrict the kind of internet based application that would be allowed to interface directly with the company’s internal applications (of course, I also realized that we should have contacted him ourselves at an earlier stage in the process). So any frustration I felt should have been directed at the policy or the role rather than the person.
As the late Elliot Jaques observed, we often come to believe that conflicts are caused by personal differences when in fact, it’s the roles that are incompatible. Jaques recommended that you stop focusing on changing people and start focusing on re-designing roles – by addressing role conflicts and ensuring that people pursue complementary goals. It is often left to people far down in the organization to handle such issues, but shouldn’t it be the job of leaders to ensure that one designs an organization where the conflict potential is minimized?
This is the first of three posts. Next week, I will look more specifically about how we manage the role vs. individual issue during organization re-design processes.
