Although my 5 week vacation in Spain was primarily about studying Spanish, I did have some extra time to read some books on other subjects. Some were fictional, such as the intense Manhattan is my beat by Jeffery Deaver, the funny Gold by Dan Rhodes and the more philosophical Baade-Og Mandag. Others were non-fictional, such as Great Service: A Framework for Action by Leonard L. Berry and Moments of Truth by Jan Carlzon.
It is the last two books in this line up that is the driving force behind this posting, because they contain so many interesting messages that are very close to my heart. They are all about customer service. They are about how to create it, how to think it and how to ... well, live it - as a company and as an employee in such a company.
Customer service found a place in my heart when I got a job at a Shell gas station in 1995. I went through internal training on customer service (I still have the material that was handed to us) and was put in a position where the gas station was my responsibility during my evening shifts. Many of my young colleagues considered the owner of the gas station quite strict (and yes, he was a little paranoid, but wouldn't anyone be that, if you have had experience with previous employees stealing from your shop?). However, that aside, he also had many positive opinions on how we looked (with regards to the uniforms) and how we conducted service to our customers. This experience did, in retrospect, open my eyes on customer service, and I must say I found it quite fun to help an old lady replace a front light on her car, even though such service wasn't in my job description.
Lately, focus on customer service has taken a nudge up for me. I think it is an reaction to several things, but mostly, I think, because I don't quite agree to the way things typically are carried out in the software development and consulting industry. Management of IT businesses tends to have a very strong focus on short term profit, to the point where it sometimes hinders the employees in doing things the right way. What the "right way" is, however, is also a subject for discussion.
Producing the "right way"
In the software industry we have processes, roles and frameworks for basically every dimension of software development, maintenance and management. We have project management, software development processes and patterns, test processes, delivery processes, processes for handling change and more. We have roles such as project manager, architect, developer, tester and sales people. We have requirement documents, solution description documents and systems to handle bug reports. We don't even have to rely on guessing, analyzing or ask the customers what they want - we create a Service Level Agreement that contains the details on when, where and what kind of service, the customer can expect from the supplier during a defined period. With all these elements why do I then believe that something is missing in the picture?
The thing is that all of the above exists to ensure that the software is developed in time and with right quality, and gives everyone involved in the production a structured way to produce it. But sometimes, to me, it feels like the processes chosen and roles used aren't quite made to handle the different needs that customers may have. Some customers may have to react to changing markets or be involved in political questions, which forces them behave in ways that might not be compatible with existing processes in the software industry. And when this happens, interesting things tend to surface. Here are a couple of examples:
- When a need rises from the customer to have employees from the supplier to stand by during night time (for what ever reason), the reaction can be "We cannot (or need not) do that, because it's not in the Service Level Agreement".
- When a customer needs to introduce some changes and it happens during the "wrong" period of the development process, developers, project managers and the like will often tend to work against such a change, because it's "not the way to do it" (what "the way" means depends where in the process the request for change occurs).
I too believe that there's a right way to create software for a customer. But it's not by rigidly clinging to processes that are not compatible with the customers needs, and getting all annoyed and irritated when the customer is not behaving in a way that supports the process. To me, this is where customer service and mindedness could come in and save the day in more than one way...
The focus on short term profits
During the years I have seen plenty of good ideas go nowhere, often because of managements intense focus on getting the most out of all employees, that is, making them have as many billable hours as possible. Some of the ideas could have resulted in for example rise in speed of development or quality of the products to benefit the customer and gain competitive advantage for the company in general. However, because these ideas demanded research and / or investment (that is, no billable hours), they were put on hold or prioritized so low, nothing ever happened. I have seen the same thing happen to knowledge sharing meetings and other non billable activities.
Of course the numbers need to stay black. But, to put it very simple, you have to give a little to get a little. That is a universal fact. But I think there's more to it that just blaming management of having focus on short-term gains. I cannot recollect ever having heard of any IT company, where middle management and its employees were measured on anything else than short-term numbers. And as long as this is the case, initiatives for better performance, quality, customer satisfaction and loyalty will suffer in one degree or another.
Change
Changing the view from production orientation (that is, the chosen processes, roles and frameworks) and short-term profits to customer orientation (what do the customers want and how do excel in giving it do them?), and implementing this kind of thinking company wide (which is crucial, no matter if everyone has direct customer contact or not), can have a lot of benefits:
- Instead of letting processes, roles and frameworks dominate, the company should think customer needs first and tailor the processes to it. Because focus is now on customer satisfaction instead of violation of rules and procedures, there's really no "wrong" customer behavior contradicting process. Sure, there will be conflicting interests, but how to solve them should be apparent: whatever it takes to keep the customer happy!
- The customer first approach also enables front line servers (project managers, test managers, sales force) to serve the customer even more. If the customer needs change or something else that might have been in contradiction with earlier applied processes, then everyone must now accept the need as customer satisfaction is now the main focus.
- Putting customer service first will enable the employees to have a genuine interest in the customers and their needs, and make it possible for them to proactively handle any concerns the customers may have. Strong customer loyalty will rise from this.
- Focus in top management must change to include customer satisfaction and loyalty as success factors. This will open up for middle management to invest in initiatives with long-term goals such as long-term profit, customer loyalty and competitive advantage.
To summarize, I think there is a degree of unhealthy focus on production orientation and margins in the IT consulting industry and not enough on customer service orientation. While processes, roles and frameworks are crucial for making good and reliable software, they should not dominate over customer service and satisfaction - the customers are vital for the existence for an IT company.
What do you think? Does customer service orientation have a place in IT companies? Or does it simply conflict so much with the "right way" to create software, that customer service orientation in an IT company close to impossible?
Christer