Once upon a time I viewed myself as only a developer. I didn’t like support, and tried to avoid it as much as possible – even though I knew it was in the customer service side where I would always learn the most in my day-to-day job. I put it down to the stubborn “programmer” in me! Then I moved into a role which was 90% support work, and I had an awakening of sorts: I really like support work. More than that, I loved working in support. I haven’t really talked much¹ about this shift in mindset, so this post is part of an attempt to rectify that.

For 3 years, leading up to early 2014, I led a small support team within a major oil and gas company. We were tasked with looking after a complex health and safety-related web application which had users from all across the globe The support team itself was spread out internationally, so I quickly had to get used to working remotely and communicating with both users and team-mates over email, IM, screen-sharing and other ways of coordinating as a distributed team.

A bit of extra background: I initially took on the support of this application by myself. The application was a virtual unknown within the IT structures of the client, and entirely unknown to my employer who was tasked with assuming responsibility for it from the original developers. I had a very, very small window of opportunity to learn from the original developers, and precious little documentation to work with afterwards. On top of this, the main stakeholders of the application were steadfastly against the move to a new support team.

Things did not get off to a good start. The support needs had been grossly underestimated by all involved in the planning sessions which had led to me being hired. It was taking longer than I’d have liked to learn the application, and soon there were red flags being raised about the reduction in support performance. When my manager and I discussed what was going wrong and how to turn things around, the first thing we agreed to was expanding the team. Initially one more person was added, with the goal of adding a second once the first had been given enough knowledge to free up enough of my time to train them both in the more in-depth aspects of the application. I should point out that at this moment I was still learning a lot of nuances of the application myself! Eventually the core team grew to four.

Our users were very diverse, ranging from someone who only touched a computer when they had to, right through to very highly technical users who spent all day, every day within the application – and this was before taking into account regional and cultural differences – so I learned to adapt myself to each person I was talking to. Sometimes even a subtle shift in tone or language could help a user understand something they’ve been struggling with for hours (or days in some of the requests we got). My communication skills levelled up immensely over this time period!

Empathy was one of the other key skills I used every day, and in turn was something I try to instil in the rest of my team. I think it’s essential to a support role, and credit it as one of the reasons I ended up as successful as I was in this particular role. Many times I found insight into a problem by pausing the technical analysis until I’ve asked the user why it is they’re trying to achieve something, and even in some cases why what they think is a problem is a problem to them (i.e. results vs. expectations). In my experience, the most important questions you could ask a user was not “What is the problem? What were the symptoms?” but rather “what is it you’re trying to do?” and “why do you want to do it?”

Through a combination of hard work, honest, friendly engagement with the users (beyond just their support tickets), and a willingness to “go the extra mile”, we went from being the unknown, out-sourced support team “forced” on them, to trusted colleagues who were experts in the application and would always do right by the users – which is something I’m very proud of.

What I learned over all of this was that I am happiest when I am solving problems and helping others with something which is bothering them — and customer service work gave me the opportunity to combine both in to one job. Put this together with the challenges which I overcame in the role, and this was one of the most rewarding and satisfying periods of my career so far. I still like to write code, but I no longer feel it is where my heart truly belongs.

Eventually, due to the shifting sands of Enterprise contracts and budgets, my team had to be disbanded, and the application handed over to a new team from a new supplier. I used the lessons I had learned in my own adoption of the application and its users to prepare the new team as best as I possibly could, training the incoming team of six with an intensive crash-course as we only had a fixed amount of time. After all, their success or failure would be a reflection on how well I had understood my application and users. I’ve only had limited contact with the client since I left, but from what I understand, things have been good in objective, results-driven manner, but my team and I have been missed for the extra attention we put into talking and listening to the user community.