Posts from the ‘Elliott Jaques’ 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 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.
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.
