Rajith’s Column

It is not often a software engineer has to engage in a customer facing role. In most organizations there is a tiered support structure between a customer and the software engineer. However in certain circumstances a software engineer may end up in a customer facing role. For example if you work for a startup you may have to juggle multiple roles, including a customer facing role until a proper support structure is put in place. Even in an established organization, when a new product is introduced the engineering team may need to handle support issues initially until the support organization gets up to speed with it.

In any case it is important that software engineers develop necessary skills to handle such situations effectively. Some of these skills will help when communicating within your organization and some for life in general.
Following are some tips that may help you to make your engagement a productive and a pleasant one.

1. . Pay attention to the subtleties when communicating over email.
   It is often easy for people to misunderstand you when communicating over email as opposed to phone or in person. The tone could be easily misunderstood as being aggressive or rude as the person reading is unable to gauge your emotions or see your body language. This is especially important if you haven’t met them in person or spoken to them over the phone. Generally once a person can put a face to a name it becomes a bit more easy.

   I have had several instances where this has happened and I now pay close attention to any email I send out to ensure that I communicate exactly what I intended.

   Also it is important to state the obvious at least for completeness sake. What is obvious to you may not be to others. This especially important when using emails as there is no opportunity for instant feedback/questions. Otherwise it will result in lengthy email threads.




2. Respect the people you are dealing with and try to build good working relationships
   Telling a customer to RTFM is probably not a good idea. Even if you are frustrated due to repeated questions that you have answered a 100 times to several people during the last few days, it is best to answer it one more time. Even when you have no choice but to tell them to RTFM, do so in a respectful manner which doesn’t make people feel bad. Nobody in this world wants to be belittled or disrespected. When egos are hurt it creates a very unpleasant work environment.

   In fact good healthy relationship can go a long way in making sure the project runs smoothly and successfully.




3. Your code vs my code - avoid the customary finger pointing
   Most people are very passionate about the code they write. And often when there is a problem we tend to take a defensive stand. Anybody who has seen a conversation between a programmer and QA engineer would know what I am talking about.
   But when you are dealing with a customer, you need to be extra careful about how you look at a problem. Even if the issue is not in your product you need to control your urge to point it in the same emphatic way you do so with your QA folks. You need to be more diplomatic in how you point out the bug on their side and try to avoid using words like “your code” or “our code”.




4. We can’t reproduce in our lab environment is not a good answer.
   Certain problems may not be possible to reproduce (in the exact form), outside the customers environment as it is difficult to replicate the exact environment due to differences in hardware and not having access to their application binaries due to security, legal and other issues. . But it is important to identify the issues at a more deeper level. Perhaps if you understand the root cause, you maybe able to simulate the issue in a different way.
   Take the time to understand the issue and try to talk to all people involved to get a complete and accurate picture. From experience I have seen that sometimes you want get all relevant information the first time you talk to people. People often forget unless you ask probing questions. Most times the first reactions from people capture the symptoms rather than the root cause. So a careful analysis maybe need to nail the real issue.




5. Encourage the use of proper support procedures right from the beginning. Never take short cuts.
   I have been burned several times by not following this. When an issue happens it is important that you encourage your customers to follow the correct procedure. For example the use of a bug tracking tool instead of a series of adhoc emails. It is often tempting to ask customers to email log files, or if you are on site to walk over to their desk and try to investigate.
   But if you encourage the use of a bug reporting tool it will have several benefits. It will force the person reporting the issue to think through in a methodical way and capture all the right information while it is still fresh in their mind. For example most bug reporting tools have fields to capture version information, a problem description, a component, steps to reproduce (if any), expected and observed result and provisions to attach log files ..etc. Once information is captured in a central location it is easy to share that information with your engineering team rather than digging through a series of adhoc emails.




6. Proactively educate the people you work with
   By experience I have found it is helpful to have a meeting as soon as possible with all involved parties and educate them on the following. Some of these may have already being communicated to them. But most may have forgotten or in some cases not being given to them at all.
   • Provide links to documentation, training slides ..etc
   • Educate them on the proper procedure to follow when reporting issues (can’t stress this enough)
   • Based on the most frequent questions, try to provide an faq that is tailored to their environment
   • Once you identify the full system setup provide a basic trouble shooting guide for them to isolate if the issue is related to your organizations product or not. This I found reduced a lot of pain and non issues being reported.
   • Provide useful links to other skills involved in the project. For example I sometimes encountered folks who work mostly in a windows environment, but now dragged into a product being deployed in a unix environment. So links on basic unix skills would make it easy on everybody in such a situation.




7. Don’t babysit the people you work with
   Initially you may get into the habit of spoon feeding information and babysitting them. This may seem like an easy option rather than trying to get them involved in the process. But it is in everybody’s best interest to get the customer to gain as much confidence in getting to know how to install, debug and use your product. This will reduce a load of pain later on in the process. Also try to,
   • Avoid getting sucked into debugging the customers code.
   • Avoid the temptation to debug or fix an issue on your own. Try as much as possible to get them involved in the process.
   • Document trouble shooting attempts and consolidate them into a trouble shooting guide. Most products have official trouble shooting guides, but a supplementary trouble shooting guide tailored to their environment and using terminology familiar to them will make them more comfortable.




8. It is helpful if you have multiple programming language skills
   Since you write code, the customer will expect you to answer questions at the code level. Sometimes you may have to review code segments and provide an opinion. However if your product is providing clients in different languages, these questions may be in a language that is outside of your core competencies. Therefore it is important that you have a at least some knowledge using those languages.
   In general the ability to write code in several languages is always an added bonus as you will be a valuable asset to the company.




9. Know thy unix tools
   Also if you are in the unix world it is nice to have some skills in basic unix tools like top, vmstat, pmap, netstat, sar, lsof ..etc and text processing languages like perl, awk, sed etc. These tools can help you diagnose issues and obtain important information about the env. The text processing tools will be invaluable when you need to make sense out of massive log files or other text processing tasks. These skills will make you more productive by allowing you to extract information quickly and efficiently than just using grep or crunching numbers using a spreadsheet.




10. Keep your conversations professional and never take things personal
    You always need to remember that you are representing your company/product and the team you work with. Therefore the people you work with at a customer’s site may directly vent their frustration at you. This may manifest in the form of rude comments, lack of cooperation and in rare situations a bit of yelling (Fortunately I’ve only seen only one such incident that happened a few years back) . Never take them personally or get into any sort of argument. It is best not to take anything personal or get emotionally involved. When the stakes are high and push comes to shove, humans will react and we need to understand that and continue to behave professionally. Sometimes all they expect is for you to keep quiet, listen to them and empathize with their situation. And something simple as “I hear your point/understand your frustration. We are doing all we can to help” is all it takes.

    However if you are finding it difficult to cope, it is best to bring it to your managers attention and discuss possible measures to address the situation. It’s a bad idea to just keep quiet and bottle them inside, as you run the risk of an emotional outburst. Let your manager help you by dealing with the management on the customers side. All though the customer is the king, it is not acceptable for anybody to be treated badly.