Effective Support

I had an awesome day today.

Not because of any new technology, or interesting piece of side work (though those are fun), but because today I was asked to fill in for the daily support tasks at work (our main contract is a support contract, with all of the investigations, bug fixes, data fixes and enhancements that come with it). You see, over the past 4 months for the most part Ive been on project work so it was a bloody nice breath of fresh air to get into the support queue (which we call Pending Technical ;) ), and really hammer it down and get things done.

So as I was churning through the queue, relatively quickly, it got me thinking about support work in general and the various ways you can be of service to your client, while at the same time learning new things and staying interested in the work you do. Which brings me to the inspiration of this post... Effective Support.

I'm starting to realize, 6 years in, that support work is a really good grounding for developers, in various ways...

The first of these ways is troubleshooting; there's no point being a fancy-pants developer, writing reams of code if you cant troubleshoot issues when (and they will!) start to appear. I find the grounding Ive had in troubleshooting over the past 5 years (how long Ive been working for my current employer, and my current client) has really enabled me to think on my feet, diagnose issues quickly (and usually correctly), and resolve them. Or if not resolve, at least put forward to be fixed. The Client wants results, even when the results may not be what they want to hear, and they would still much rather know whats going on so they (or you, as the case may be) can get it fixed as soon as possible. Not only that, they'll appreciate the speedy response. Take too long, too frequently, and the Client will start to develop an apathy towards your relevant 'Pending Tech' queue, with little or no expectations. This is a Bad Thing... When the Client stops caring, they start looking somewhere else.

The second of these is communication; in the support world communication is everything. Whether it be written or verbal, communication will make or break a support ticket. Being clear in what you require from the Client will go a long way towards resolving your current task. If you get a ticket that makes no sense, like vague issue descriptions for instance, pick up the phone and call them directly. Don't be afraid to talk to the Client... Ive found a single conversation will often resolve a multitude of issues, as you get instant feedback as to whats going on. Even more important than picking up the phone... See your Client. Most companies that outsource will have some sort of hot-desk arrangement, so talk with your manager and try and book at least half a day at the Client site per week. While there will be times where its simply not possible, the Client will always appreciate seeing the people on the other end of the line. If you stay stuck in a room with 4 walls, with no contact to the outside world, the support tasks you are responsible for will suffer, and even worse yourrelationship with the Client will suffer. Great communication with your Client leads to a great relationship with your Client... Which means you get to keep your job :)

Thirdly is maintainable code; again, using the fancy-pants developer example, there's no point being so wonderful and awesome if the next guy that comes in doesn't at least have a basic understanding of whats going on. While there are always going to be some areas that will be more complex than others, your code should be clear, concise and (I cant emphasize this enough), clearly commented. Now, I'm not saying that you should comment EVERY SINGLE LINE OF CODE IN EXISTENCE!!! (Imagine that shouted in a deep, echoed voice), but I am saying for areas that aren't immediately clear, or require a deeper level of understanding, comments should be included to help the next developer in his/her mission to understand what you have done. I find, having been on the short end of the stick a few times, writing maintainable code from the start will go a long way to remaining effective and agile for your Client, otherwise your estimates will be bigger due to having to deal with the mess of code left from before. Lower estimates mean less money, which makes the Client happy, which means you get to keep your job :)

Lastly (for tonight at least) we come to business knowledge. Or 'Domain Knowledge' if you prefer. While we, as developers, will never have quite the understanding the Client does of their business (and Ive noticed we always tend to have a technically skewed view of things), it should be our job (especially as support developers) to increase our knowledge of the domain we are working in. Get use cases, functional requirements, policy documents, ANYTHING really you can get your hands on, and try to increase your level of contextual understanding of the business (how/where your application is actually used, and how the users use it). I think that business knowledge, in combination with communication can really enable your team to excel in the support environment, and are the most important points of what I'm trying to get across with this post. The Client always respects those who actually care about the business they represent, and who make the effort to truly understand what it is they are supporting. And with that respect, you get to keep your job :)

I hope this post has enlightened you, the reader, in what I believe to be three key points in giving Effective Support to your Client. Feel free to disagree/agree/modify my points in the comments, discussion is encouraged :)