For a while, I have wanted to put down my thoughts on how we should behave when providing support to the users of our systems if an important issue has been found. More specifically, these ideas come from providing support in enterprise setups where you might work with a system integrator or a business user of your product.

After a lot of thinking and iterating, I have come up with this simple set of values. When you provide support to someone on your product:

• Be Urgent – the issue is probably important to them. It’s important to portray that in your urgency. Once you get to it, respond and acknowledge. Offer an initial view or confirm that you are raising it internally to figure out more. They say that actions speak louder than words but when handling an issue, it’s also important that words lead the way since action physically takes time.
• Be Kind – in enterprise scenarios, it’s likely that the person who you are talking with is actually facing (the wrath of) the end-user who is inconvenienced. Be kind to them. Don’t take out your frustration on them. We’re probably all on the same team in resolving this. Being unkind or rude might seem like one way out of this (especially if you feel that the people who contacted you are wrong), but the real long-term cost of that is very high. This issue will get resolved and the system will last much longer than this one issue, and your relationship with this partner will likely outlast this single delivery. Being unkind and burning bridges will singe the relationship forever. The expression that I’m reminded of is “grace under fire” (which is also the name of a 1993 TV series).
• Be Humble – The issue could be due to something we did wrong on our side, or our partner did on theirs, or the end-user did. But, whatever the cause, this issue has now surfaced. Don’t pre-judge the situation and try to shift blame – work from a position of openness and work in the interest of the product or the project to find the solution. Be humble that the issue could be due to something we did wrong. As my former CEO used to quote/ say, “If you are right, you have no need to be angry. If you are wrong, you have no right to be angry.”
• Be Clear – once the attitude is correct, this is the most important idea. Be clear – it’s probably better to be more explicit at this time rather than imagine that everyone has the same knowledge and is on the same page as you. Don’t reply back saying “can you send me the logs?” since that might soon be followed by a question on the duration and the systems from which you need the logs. Ask clearly – “can you send me the logs from the ZYX VM for the duration 7:00pm – 7:40pm”. Being clear at this time helps you reduce the time spent and also the frustration on all sides. If, for some reason, you can’t be clear, let that be known – “Could you try restarting the XYZ service? I don’t have access to the System User Manual right now but it’s documented there” rather than replacing it with the context-less “Can you restart the services and try?”

That really is it. Some people worry if being humble and kind are signs of weakness. I do not at all see them as signs of weakness – I see them as signs of maturity and collaboration in the interest of the work that you are doing. Resolving the issue will almost certainly be followed by some form of introspection or analysis and that would be the right time to identify what went wrong, which side overlooked something, and what process should be followed to prevent that from happening again. In these, if you showed grace under fire, you will certainly be treated warmly, irrespective of where the fault was.

Issue handling is an opportunity to build stronger bridges for the future. Don’t blow it up.

If you found this post useful or would like to add more thoughts, feel free to share the post (you can tag me as @onghu on Twitter or on Mastodon as @onghu@ruby.social ) or leave a comment below.