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?