Customer support or customer success?

March 22, 2008

Have you ever called a help desk line for a product or service and ended up feeling like the primary objective of the person on the other end of the phone was to get rid of you? Sure, they were helpful but there were just enough underlying behaviors to make you feel like the person truly did not care if you were successful with their product or service. While this particular topic is not directly related to Agile product development, I believe it to be relevant for anyone developing products with some form of customer. The problem runs deeper than telephone support. Face to face interaction with an individual often produces the same feelings – this individual does not really care if I am successful or satisfied. They simply would like the me to go away – successful or not.

Often times providers of service will do their best to generate a state of perceived success in order to satisfy a mis-used measurement system. My recent experience with a car dealership is the perfect way to demonstrate this. Here is the story. Again, it does not directly apply to Agile development but it does apply from the perspective that customer success is a key to the success of any product.

The Dropoff

It seems to me if a business has the objective of retaining long term customers, the primary focus must be making them successful with their products. I recently made a trip to Momentum Mini here in Houston, Texas to have my car serviced. The car did not have a major problem. I had noticed a few times the engine had died while it was running and wanted them to take a look at it. In addition, there were some other maintenance items to be completed. They were fairly simple requests. I dropped the car off on a Monday morning after making an appointment. They have a program where you can pick up a rental car from them. It took an hour and fifteen minutes to get the rental car. Additionally, the first place I needed to visit was the gas station as they had given me a car running almost out of fuel.

The Callback – Not

The service manager told me they would call me the next day. On Tuesday, I did not receive a call. Wednesday morning I left a message on the voice mail of the service representative. Still no answer or call back. Another day passes. This time its Thursday and I am furious. I leave another message for the service representative and the service manager. The message was fairly strong and asked them if they were having technical difficulties with outgoing calls. A few hours later after leaving the messages, I finally get a call back. Basically, there was nothing they could do about the problem and all they had done was rotate the tires.

Picking It Up

When I went to pick up the car, the service representative knew I was upset.  This particular service representative actually seemed to care that I was unhappy.  When they brought the car around to me she noticed there was tree sap all over it and offered to wash it for me.  I accepted the offer even though I was in a hurry.  While they were washing the car, she said the service manager (her boss) wanted to speak to me. She indicated they would be sending me some coupons for dinner at a local restaurant.  This helped a little.  When her manager came out, he apologized for the experience and asked me how they can improve.  When I was finished giving my feedback, I was actually becoming more satisfied.  Then as he left, he destroyed the experience for me.  He said “Now you know you will be getting a survey in the mail.  Feel free to write any comments regarding your experience but it only helps us if you rate us a five (the best rating) on all the questions.”  I told him he had some nerve asking me that and went on about my business.  By the way, I never received any dinner coupons.

Reflections

By now you may be asking yourself, why is this relevant to either Agile development or management, hasn’t everyone had similar experiences?  The primary reason to discuss it here is simply to highlight the fact that measurement when implemented the way the dealership above has done can cause employee behaviors which actually harm the business.  My feeling as I left the dealership was that the only thing the service representatives and management cared about was getting a good score on their survey.  When it was clear they would not, they gave up.  This is why I believe the sales manager never followed up with the dinner coupons.

The lesson here is to carefully choose the mechanism you will use to measure your employees.  Make sure that it truly encourages them to achieve the results you desire.  In this example, having the service manager actually analyze and observe the experience of the customers would have been a much better approach. Or perhaps, reading the comments from the survey and using them to gain a qualitative understanding of how well the service department was doing would have been better.   Nonetheless, in this instance, I am not a successful or satisfied customer and I truly believe the measurement system used by the dealership greatly contributed to my dissatisfaction.


The Passion Behind the Software

November 11, 2007

It must have been about ten years ago now, perhaps a little more. At the time, I was conducting a self study of TCP/IP. The motivation behind the study had little to do with economic gain. I simply had a curiosity for how networks functioned – especially the Internet. I had set up a few small websites and written some freeware programs. The excitement of someone viewing my web pages or downloading my programs still makes me curious. Why was it so satisfying?

During this same time frame I developed a small Win32 application that performed an ICMP Ping. It worked very similar to the command line version on Unix. It differed from the command line version on Windows in that it provided much more data about the results of Ping operation. Most notably, it was an elegant (for the time) GUI application. The reason for writing the program was simply to allow me to advance my knowledge of TCP/IP.

Upon completion of the program, it was made available to the public via a few freeware websites. It was downloaded frequently. Every day upon returning from work, I would rush to the computer to go to the website and see how many people had downloaded it. On the days with a high number of downloads, I would feel energized and motivated. This frequently motivated me to enhance the program. Never once was profiting from this utility seriously considered.

A few months passed, there was an email in my inbox from one day a company in Australia. The letter told indicated this company was deploying a standard desktop software environment to the entire company. All 30,000 desktop computers would have the exact same configuration. The letter was requesting a price to allow them to include the ping program as part of their standard desktop environment. They were interested in a feature in the program that allowed the user to export the ping results to a text file where it could easily be attached to an email an email. The letter went on to say the company was wrestling with network issues. They needed an easy way to help resolve network problems. The users were not advanced and asking them to capture output from a command line Ping utility was proving to be difficult.

At this point, I was overwhelmed with excitement over the thought of up to 30,000 people having my software installed on their desktop computer. It simply did not occur to me to try to sell them the program. It was free software. It just was not about making money. I responded back to the company allowing them to use the utility free of charge. It was quite gratifying just knowing they were using my code. In the end, I am certain the company would have happily paid me for the software.

Almost every time I tell this story, someone talks about the money that was missed. The response is always the same. It was not about the money. It was about the satisfaction of knowing my code was in use, knowing someone found it useful, and knowing I helped this unknown company with their network problem.

This very simple example has millions of occurrences amongst open source and freeware developers. A few months ago, I purchased a MacBook Pro laptop. Not long after the purchase, it seemed to run very hot. Attempting, to solve the problem, I googled “MacBook” and “Heat”. One of the top results contained a link to a free program called “Fan Control”. This utility allows the user to control the fan speeds such that the system runs much cooler.

About two weeks ago, Apple released their new operating system known as “Leopard”. Upon install, I noticed the laptop was hot again. Back to google, I went. This time I added “Leopard” to the search. Sure enough, there was a link indicating there was a fix to the fan utility which made it compatible with Leopard. Not only did the author of “Fan Control” provide the utility free of charge. He also provided support and patches faster than most large software companies.

The over arching question is “Why?”. What is it that drives people to work for free? What motivates them to create high quality deliverables? Is it the satisfaction of participating in a broader universe? To belong? Is it a desire to leave a legacy? Or perhaps, a desire conquer or create something? Is it the ability to control ones own destiny?

Regardless. of the answer, software organizations have a unique opportunity to understand what drives software engineers and introduce those key characteristics into the work environment. For example, if it is true that leaving a legacy is important to developers, companies should create an environment which publicly (internal or external) acknowledges the work that has been accomplished by individuals.

Is it possible bring the passion of free software development into an environment where people are paid to produce?


What makes them tick?

November 10, 2007

Recently, I was involved in a discussion regarding the optimal organizational structure for a large software engineering organization. Several of the attendees were proposing various structures. The primary goal was efficiency and maximizing the output of each individual.

The proposals included ideas such as creating a resource pool made up of software engineers with varying skill sets where team members act as a group waiting for assignments. In this scenario, any given engineer could be working on many different projects over a period of time. The source code tree he is working on today may very well be different than the one he had worked on even the prior week.

As the discussion progressed, I found myself believing the participants had missed a critical point. My belief was and is workers (software developers in particular) need to feel a sense of ownership in the project they are working on. In other words, most modern day developers are not content to work on code where they do not have an understanding of how their effort relates to the success of the unit. Beyond understanding, they need to feel as if they have influence. My belief is not only based on a suspicion regarding what motivates software engineers, it is primarily based on personal experience.

During the course of discussion, I commented, “regardless of the structure that is chosen for any organizational structure, it is critical to analyze the individuals which participate within that organizational structure. You simply cannot make a decision regarding organizations without an understanding of the impact it has on the individuals”.

Admittedly, the notion is somewhat intuitively obvious. However, I have witnessed many discussions regarding companies, organizations, etc. which simply do not take into consideration what it is that makes the employees do what they do. What makes them tick? While its impossible to generalize across a large organization, everyone is different, it is possible to understand the general effect an organizational structure may have on a team. The first test, simply ask yourself the questions…How would I respond if I were put into a given work structure? How would it feel to transition from collectively owning a product to serving a role in a resource pool? Would you be as motivated and energized?