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?


bombay dosti said...

Very true! I also feel that the specialist along with his technical expertise about the subject, also brings with him some very important personal quality. In order to transition from technical expert to solution provider, he must be able to articulate those solutions to the business in a manner that is acceptable and non threatening. We have had situations when even some good workable solutions have not been accepted because of this "threat" from the specialist.

Another view i have heard, was this: quite an interesting one. An internal OD specialist should be a person with high self esteem because most often specialist's solution is also one which has to be implemented by the business with the business partners. The final end product and the success that comes from a solution might be quite far away from the time the solution was conceived by the specialist.Therefore a specialist may not always have the pleasure of enjoying the "sweet wordds of success". There again, the need for a higher order quality required from a specialist- his motivation has to come completely from within himself. Laurels and good feedback may not come immediately.that was a long comment :)
your response?

Prasad Kurian said...

Thank you.

If you are a deep-specialist, you might often experience some sort of 'intellectual loneliness'. Your boss (who is likely to be a generalist), your customer or even your team members might not be able to fully appreciate the real quality of your work/ solution - at least not immediately. Since your expertise in the domain is higher than those around you, you tend to see things (problems, options, implications etc.) that other don’t see. You put in a lot of effort thinking through (or even agonizing over) this 'multidimensional maze' of possibilities and probabilities and arrive at a superior solution. All your boss or customer would see is the solution (that too just the most obvious parts of the solution). The quality of the thought process that resulted in the solution is likely to be lost on them. Another struggle for the specialist is the tension between 'technical perfection' of the solution and 'feasibility of implementation' that I was mentioning in the post. It involves large number of tradeoffs/compromises. While it sounds neat and philosophical when we use terms like 'creative tension' and 'optimization subject to boundary conditions' to describe this process, for the specialist who is going through all this it often feels like something similar to 'intellectual prostitution'. Also the real superiority of the solution might manifest mainly in terms of the outcome measures (as opposed to output measures) which might take a long time to happen (see ). So I agree with you regarding the need for high self esteem/self belief. I think all this 'comes with the territory' for a specialist and hence my point about making the transition from 'technical expert' to 'solution provider' without losing the soul of the specialist.