A few years ago, I worked with a very 'interesting' boss. He was the head of our group and he used to have 2 Executive Assistants and 1 Executive Secretary supporting him. Since group size was about 30, this meant that 10 % of the group was in his support staff. I used to wonder if this was really required. While he definitely needed some administrative support, 3 support staff seemed to be a bit too much. I used to suspect that some sort of 'pace bowler mentality' might have something do with this situation. Let me explain. In the game of cricket, if you are a pace bowler, you would feel very good when you see a few fielders in slip and gully positions when you are running in to bowl. In a way, it is an acknowledgement of your skill as a pace bowler. After all, fielders won't be deployed in those positions unless you have a good chance of forcing the batsman to edge the ball. So it makes sense. Now think of a situation where the batsman has been hitting you over midwicket frequently and you still insist on having many fielders in slips/gully. It this case it becomes debatable whether your demand is based mainly on logic/cricketing sense or on your need to maintain your self image as a good pace bowler.
This brings us to the larger issue of the level of admin./secretarial support required for senior managers. In MNCs, the trend these days is to reduce the number of support staff for senior managers to an absolute minimum level. In a high-tech world, many of the traditional administrative/secretarial support activities are not required. Self service is the norm even for senior managers. Some times this (i.e. operating without support staff) is also done as a 'cultural statement'. Anyway, this leads to savings in 'headcount' and it makes sense in most situations. However there are also situations where a significant part of the senior managers time gets wasted in administrative activities that could have been done by a support staff. Considering the very high salaries of many of these senior managers, some times this 'avoidable' wastage of time could prove to be more costly than the cost involved in employing support staff (especially when we consider the 'opportunity cost' of the time wasted by the senior managers). Also I feel that, in general, decisions based on 'total cost of workforce' are often better than those based on 'headcount numbers' though headcount numbers are easier to track and control. Thus it becomes necessary to examine whether the decision to reduce the number of support staff is based entirely on sound business logic (based on a cost benefit analysis).
It would be interesting to examine if the presence of support staff encourages some managers (especially 'old world' managers) to operate in a more hierarchical/less democratic way with the other team members and/or to feel that the other team members are not so important. An extreme example is the case of a senior manager who (when he has questioned by his HR manager about the high attrition rate in his team) claimed that he is not bothered about attrition as he can run the department with only two other staff members. When the curious HR manager tried to find out who these two 'critical resources' are it emerged that the senior manager was referring to his secretary and his driver. May be the presence of support staff increases 'power distance' in some contexts and in those contexts the 'cultural statement' that I was mentioning earlier might not be all that bad an idea !
Prasad Oommen Kurian's blog on Human Capital Managment and Organization Development
Friday, October 19, 2007
Monday, October 8, 2007
Of specialists and 'business-alignment'
I have spent most of my career so far in specialist roles. I have also handled HR business partner roles (being part of the business leadership team) where I was the 'internal customer' for specialists roles in HR. This gave me an opportunity to develop a more 'balanced perspective' on specialist roles - their value proposition, their relationship with generalist roles, and their business-alignment.
One of the issues that has interested me a great deal is the 'business-alignment of specialists'. Most of us would agree that specialists should not operate in an 'ivory tower' manner and that their efforts should be aligned to the needs of the business. It would be quite disastrous if a specialist operates with an attitude that 'I need to make some interventions, so let me find a group/unit to be intervened upon' or that 'I have designed a 'perfect' framework/tool/process and my duty is to make the organization implement that - whether they like it not'. So, the solutions that the specialists design should be targeted at the key problems and opportunities for the business. Also, these solutions should be designed in a such a way that they have a good chance of 'working', keeping in mind the organizational constraints and its state of readiness. Otherwise the result would be 'very elegant impractical solutions'.
However, it would also be a mistake to jump to the other end of this spectrum - where the specialist becomes just a pair of hands. Specialists are paid for their expertise and just 'obeying' what their customer asks them to do without questioning would be an abdication of responsibility. As a specialist, I have felt uncomfortable when a business leader or a generalist attempted to tell me 'the solution'. I feel that the customer should describe the need/problem. The customer can also specify some key design considerations and boundary conditions for the solution in their context. But it is the job of the specialist to design the solution. Of course, the solution design process is an interactive one where the customer input/data/feedback is sought at all the appropriate stages. Again, it is for the customer to decide whether the solution meets his/her needs. But none of this takes away from the fact that 'solution design per se ' is the job of the specialist.
Now, this does not mean that specialists should stop listening to the customer the moment the customer starts describing the 'solution'. These 'solutions' described by the customers often provide valuable information regarding the 'real problem'. In many situations, this information might not be part of the initial problem statement. The solutions provide a good starting point for an in-depth discussion with the customer regarding the problem. This is essentially a matter of asking the customer why he/she is proposing the particular solution. The idea is to seek clarifications so as to have a better understanding of 'where the customer is coming from' and not to 'destroy' the 'solution' proposed by the customer. Once we understand the real needs/objectives of the customer, it becomes possible to have a discussion with the customer regarding the possible solutions (and not just the one the customer had initially proposed) and their implications. This gives the specialist an opportunity to bring in his expertise (content and process) and do what the specialist is paid to do. Of course, there could be situations where the customer is not prepared to have such a discussion (i.e. where the customer's position is that of 'just do what I tell you'). If these situations occur frequently in a particular context (or if they become the standard operating procedure), then the specialist should think about whether a specialist role is really needed in that context. Fortunately, these these kind of contexts are relatively rare.
The role of the specialist is a tricky one. Deep technical expertise (in both the 'content' part and in the 'process' part) is often a key part of the 'definition' of a specialist. Thus 'technical perfection' of the solution becomes a key motivating factor for the specialist. However, the survival of the specialists depend on developing and implementing 'pragmatic solutions' that work within the organization constraints. Thus there is always this ('creative'?!) tension between 'correctness of the solution' and the 'feasibility of implementation'. Making the transition from being a 'technical' expert to being a 'solution provider' is a necessary part of the 'journey' of any specialist. The 'trick' is to make the transition without losing the 'soul of the specialist'.
Any comments/thoughts/ideas?
Related Link : Specialist roles in internal HR - An endangered species?
One of the issues that has interested me a great deal is the 'business-alignment of specialists'. Most of us would agree that specialists should not operate in an 'ivory tower' manner and that their efforts should be aligned to the needs of the business. It would be quite disastrous if a specialist operates with an attitude that 'I need to make some interventions, so let me find a group/unit to be intervened upon' or that 'I have designed a 'perfect' framework/tool/process and my duty is to make the organization implement that - whether they like it not'. So, the solutions that the specialists design should be targeted at the key problems and opportunities for the business. Also, these solutions should be designed in a such a way that they have a good chance of 'working', keeping in mind the organizational constraints and its state of readiness. Otherwise the result would be 'very elegant impractical solutions'.
However, it would also be a mistake to jump to the other end of this spectrum - where the specialist becomes just a pair of hands. Specialists are paid for their expertise and just 'obeying' what their customer asks them to do without questioning would be an abdication of responsibility. As a specialist, I have felt uncomfortable when a business leader or a generalist attempted to tell me 'the solution'. I feel that the customer should describe the need/problem. The customer can also specify some key design considerations and boundary conditions for the solution in their context. But it is the job of the specialist to design the solution. Of course, the solution design process is an interactive one where the customer input/data/feedback is sought at all the appropriate stages. Again, it is for the customer to decide whether the solution meets his/her needs. But none of this takes away from the fact that 'solution design per se ' is the job of the specialist.
Now, this does not mean that specialists should stop listening to the customer the moment the customer starts describing the 'solution'. These 'solutions' described by the customers often provide valuable information regarding the 'real problem'. In many situations, this information might not be part of the initial problem statement. The solutions provide a good starting point for an in-depth discussion with the customer regarding the problem. This is essentially a matter of asking the customer why he/she is proposing the particular solution. The idea is to seek clarifications so as to have a better understanding of 'where the customer is coming from' and not to 'destroy' the 'solution' proposed by the customer. Once we understand the real needs/objectives of the customer, it becomes possible to have a discussion with the customer regarding the possible solutions (and not just the one the customer had initially proposed) and their implications. This gives the specialist an opportunity to bring in his expertise (content and process) and do what the specialist is paid to do. Of course, there could be situations where the customer is not prepared to have such a discussion (i.e. where the customer's position is that of 'just do what I tell you'). If these situations occur frequently in a particular context (or if they become the standard operating procedure), then the specialist should think about whether a specialist role is really needed in that context. Fortunately, these these kind of contexts are relatively rare.
The role of the specialist is a tricky one. Deep technical expertise (in both the 'content' part and in the 'process' part) is often a key part of the 'definition' of a specialist. Thus 'technical perfection' of the solution becomes a key motivating factor for the specialist. However, the survival of the specialists depend on developing and implementing 'pragmatic solutions' that work within the organization constraints. Thus there is always this ('creative'?!) tension between 'correctness of the solution' and the 'feasibility of implementation'. Making the transition from being a 'technical' expert to being a 'solution provider' is a necessary part of the 'journey' of any specialist. The 'trick' is to make the transition without losing the 'soul of the specialist'.
Any comments/thoughts/ideas?
Related Link : Specialist roles in internal HR - An endangered species?