I’ve been doing technical support for the last 13 years and still do it today, I love it.  I love it so much that I’ve now got friends all over the world.  I used to have a map of the world in my office with pins that located them.  I’ve even been invited to the wedding of one of them on the other side of the planet, which I attended with great pleasure.  This is invaluable experience and just for that, I’ll continue for the next 13 years in the exact same way.

But in addition to the social aspects that are obviously linked to my personal interest in multiculturalism, technical support is a real opportunity to grow for both developers & business owners.  Support connects you to your users and it’s one of the best channel of gratification you may have.  The comments and suggestions you receive positively from it help you improve your products, skills or strategy.  If you are doing great at support, there is a great chance you are or will be great as an entrepreneur or lead developer.

There are many motivational theories and they are not universal as we are all different. We are all driven by both extrinsic and intrinsic motivation at different levels.  A good example of extrinsic motivation is salary or threats (the donkey, the carrot and the stick). You do support because you are asked to do it or only for money (or because potential loss of money), or both.  Intrinsic motivation on the other hand is the motivation you get from just doing the task.  You are aware of your own performance and you are not specifically seeking for extrinsic motivation.  In fact, that kind of motivation often comes naturally afterwards.

“Many, many thanks Pierre for helping me out […]. It’s rare to get such service and I really appreciate it. […]. I owe you a beer or three next time I am in Brussels!” A customer from UK

Because technical support agents are often at the very bottom of the hierarchical pyramid, it is likely to be perceived as a low profile job.  Many technical support guys try to do the bare minimum and hope they will be promoted soon to get out of that awful situation.  I believe it’s the exact opposite.  The essential skills needed to be a great technical support agent are the same you need to be a brilliant developer or successful entrepreneur.  Great developers & great entrepreneurs have strong interpersonal skills.

Strong interpersonal skills include being genuinely interested in your users and being able to put yourself in their shoes.  Empathy through social awareness is one of the core element of emotional intelligence.  If you don’t understand your users, you will face strong problems.  Some users have difficulties expressing their needs or feelings.  Your great ability to decode what your customers need or want will not only make them happy, but also help you improve your products and overall company strategy.

“I must say Pierre that we are very impressed so far not only with the product but with your overall attitude and all the assistance you have given us. I can’t thank you enough but hope to thank you soon as a customer.” A customer from US

Because support is an integral part of your product, support is also one of your main sales & customer relationship channels.  A study conducted by RightNow® Technologies has found that 46% of Australians declared they would leave their current internet provider because of poor customer service.  The same survey states 21% already left a previous provider for the same reason.  How many customers can you keep or get with a great support?  In software development, support is often the first human to human contact your customers get and how it will goes will be weighted in their overall perception of your product.  In fact, your product is not the bits that get downloaded and installed on your customers machines, your real product is the whole experience your customers will get with your company.

Since your product is your company, including its support, any assistance you give to your users should be free and optimized.  To make it painless for both our users and ourselves, we try to use the following procedure once we receive a request:

• If it’s a reproducible bug, we add it into the backlog and give its ID to the customer/user. We also take the ID of the customer/user to notify him of resolutions and releases personally. This is easy if you collect his email directly.
• If it’s a problem using the software, we take this as an opportunity to improve the documentation.  Any answer is written like a knowledge base article that we add in our database afterwards.  It takes triple the time to write, but we don’t have to repeat ourselves later (most users prefer browsing in KB).
• If it’s a feature request we connect the user with the product owner directly.  This is very valuable.  Of course we use systems like uservoice.com, but talking with the user directly is a lot better.
• If it’s a complaint we try to manage that outside the process.  People that complain like to be considered as important (even if the complaint is trivial).

Support is your free & perpetual market research.  Support is one of your main sales channels. Support is your opportunity to learn how to improve your social awareness.

The sprint review meeting is crucial for you, the developer, because this is the time you will be able to both give a lot of visibility to what you are doing and also get the feedback necessary to better align your work on the real needs of customer and or users. Yet too often, this meeting does not achieve these objectives because it has been badly prepared.

Show what you have done

I would like to draw your attention to two of the main problems that may be encountered.

Firstly, showing the result of work that has no user interface, and then secondly making sure you show something that works.

For the first point, the difficulty intensifies when you are dealing with people who have never been programmers. They often do not realize that a developer can sometimes work for weeks for minimal changes to the user interface. In other words, they can hear what you have to tell them, but they cannot see it. The solution developers choose far too often is just not talk about it.  If you can’t demonstrate it – don’t show it.

This attitude is typical of personalities we technicians have.  It is undesirable because you cannot then get the views of your user on the progress.  Their understanding and view is much more important than yours.  You are first and foremost in their service, and not the reverse. Developers who comprehend this have a very significant advantage over others.

The best way to show something that will not be obvious in the user interface is to use a presentation slide that describes the change. Because every time you develop software it is supposed to add value, you must find a way to highlight it. Some examples:

• For performance improvements, clearly indicate the gain in a metric understood by the user.
• If you have completed some intensive code refactoring, you should be able to demonstrate the usefulness of the work by using metrics highlighting the reduction of complexity, testability, or other value that will in the long term give significant savings in maintaining the code.
• For the functions for which it is impossible to show something, such as support for a new source of information in a communication tool, do not settle for spending a few moments going through an a list of work done. Describe the challenges you encountered – this should give them the context that they lack.

In any case you should avoid sounding as if you are just justifying the time you have spent on the work.  The idea here is to evidence that you have progressed and that you are in control of the situation.

One last thing about the demonstration: Make sure you do the following things:

• draft a scenario that you will repeat to your users.  You must not just randomly chat about the project
• This scenario should cover most of the needs expressed by the client. This makes sure you are not interrupted by constant questions during the demonstration. In addition, this will allow you to ensure good feedback (we will cover this again below).
• Run the demonstration several times on the machine that will be used during sprint review. This should eliminate most problems.
• Rehearse it once or twice under the same conditions as the meeting. That is to say physically in the room with the same equipment.

Collect feedback

Great developers excel in this task. They know that developers who give the most satisfaction to their users or customers are those who understand and realize the things that bring their customers the most value. This type of profile is very rare and it is again very difficult for a technician to fully grasp this concept.

Everyone knows that the users are usually more comfortable when describing their problems than with finding solutions. There must be a real interaction between the technician who will eventually devise the solution and the person who has the problem. For this interaction to be productive, the programmer should be able to ask the right questions and discuss areas for improvement – and this is especially true during sprint reviews.

Many developers fear this time because they are likely to be criticized. This particularly affects perfectionists. Here are some tips to manage any negative reviews:

• Be aware that criticism of your work is primarily criticism of the latter – the work, and it would be inappropriate to assume that the customer is actually criticizing you.
• Remember that criticism relates mainly to the person who has made it and how they have interpreted the situation.

Having considered the two points above, we must consider every criticism as an opportunity for improvement.

Of course, all this also applies to positive feedback and I will write an article soon that will cover this in detail.

To summarize:

• You can show your progress and all your activities
• Feedback is an opportunity for you to excel in your profession