Our website uses cookies to enhance your browsing experience.
Not everyone enjoys working in support. Many people who work there experience burnout. So maybe companies shouldn't have any support at all? How do they benefit from it? Is there a way to prevent burnout while working in support? Let's try to find the answers.
First, a few words about me. Currently, I'm working as a C# programmer at PVS-Studio – a company that develops the PVS-Studio static analyzer. By the way, I managed to have a hand in it. I wrote diagnostic rules and broke enhanced the kernel. Now I work in the Tools&DevOps department, where I deal not only with the obvious things but also provide tech support for clients.
The reason why I told you this is, I have first-hand experience with support and know why people experience burnout working there. With experience, I discovered ways to successfully deal with burnout, and I want to share them here.
I will tell you about my first interaction with support. Here is the story. When I was at school, I played World of Warcraft, if memory serves, it was the Mist of Pandaria expansion set. Things were going fine till suddenly I faced a technical problem – the game thought that I had a different class, and thus was giving me unsuitable things. I couldn't Google the solution, so I decided to contact support.
My previous experience of contacting other companies' support usually ended up the same way: either they simply didn't answer me, or a week later they answered something like, "Thank you for your feedback, we will try to fix your problem". As you can see, I never got a solution. Therefore, I didn't expect them to fix my problem, but I had to do something. However, these were still the same old Blizzard. I wrote a message and got the solution in the game chat in less than 5 minutes! The speed and the work quality of this company amazed me.
This case showed me how support should work.
To be clear, we don't have a call center and all communication takes place via email. Also, my department (like other programmers in our company) doesn't do the primary applications processing support. A small, experienced team in our company is responsible for that. They manage to answer most of our users' questions, except for technically complex ones that require tinkering with code. And it's time for us, the developers, the authors of this code, to get involved in the process. In this case, the developers themselves communicate directly with the users. We believe that this approach allows us not only to improve the support quality, but also to show developers the importance and relevance of their work.
The support that I provide within the Tools&DevOps framework can be divided into:
Well, everything is clear with the first one: I clarify the scenario, reproduce it, and if there is a problem, I fix it. If I cannot reproduce the problem, then I get sad and ask for additional information. In general, there's nothing unique.
In the second case, for a start, you need to understand whether the suggested idea is practical, convenient, useful, etc. Then you discuss the idea with the managers and decide whether it will be implemented or not. And, if yes, then we inform the user, create a task and I start coding. Optionally, after the work is done, I may write an article on the new functionality.
So, the question is: "What is this all about?" What, exactly, are the benefits for us and for users?
Benefits are evident: problems get fixed, experience with the product – enhanced, and, occasionally, the needed functionality – added (or added faster). For example, we planned to make a plugin for CLion in the distant future. However, many user requests made it clear that it should be done. And the sooner the better. If you are interested, here is my teammate's article about its development.
I want to point out that we provide support to free users. And even that benefits us.
In fact, we probably get even more benefits from support than the users. Let's start from the beginning.
When solving the "something doesn't work" problem, we improve the quality of our product. That one's easy. It's impossible for tests to cover all possible use cases of how and where to use our programs. We already have many utilities and plugins, and, consequently, scenarios for their use. For example, one developer tried to use our tool in uVisionKeil and wrote a very good article about his experience.
Also, due to the specificity of the static analysis technology, false positives are inevitable. False positives are the false warnings that the analyzer issues. Our departments which develop diagnostic rules fight against this problem, but it is impossible to anticipate everything. So, when a user sends us a code example that turns out to be a false positive, we fix it. Thus, we are making the analyzer in some sense smarter.
By implementing users' requests for adding new functionality, we do exactly what users need. Especially when they write about it repeatedly. Plus, when you work on something for a long while, your eyes lose freshness of vision, and you may not notice, for example, that something is missing, or something is inconvenient. These are the moments when feedback is very helpful. By the way, here are the features we added over the last six months, starting from 2021, based on clients' suggestions:
If you are wondering, what else we've done, then here is the release history.
Next, remember to grow your rating for your clients. After all, when a person turns to you and receives a quick answer and a problem solution instead of silence, the attitude towards you improves. It can also tip the scales and the client will want to continue using your tool.
In addition, let me point out one thing that, at first glance, may not be that obvious. Providing technical support improves our understanding of product code. Programs are now extensive, there is a lot of code and there are parts that nobody wants to deal with anymore. For example, some core mechanism has been running smoothly for a couple of years. Well, it keeps running and running, why would you need to interfere? Suddenly, a user writes to you with a problem. When studying it, you get into places in code that you may not have heard of. And to understand what the problem is, you need to understand what is happening in the code. This gives you a better understanding of the entire architecture and all the interactions in your program.
Sometimes, if the communication and study of the problem was exciting, you can share information in a note. It's an extra opportunity to advertise the product and show how support works. Example: "False Positives in PVS-Studio: How Deep the Rabbit Hole Goes".
If you take some time and think, you may find other advantages. But I think that's enough. Now let's talk about how to avoid burnout.
Working in support - and communicating with people - is not easy. It can be a road to burnout. First, let me tell you how we cope with burnout in our company.
The main thing – a person doesn't work in support permanently. Rotation helps us a lot. I mean, this month I am in support, next month I work with plugins, then I optimize the workflow (Jenkins, scripts, and all that), then I improve utilities, etc. Moreover, one can switch to rotation in another department and, for example, make diagnostic rules. All this helps me stay on my toes and diversify my workdays and tasks.
At PVS-Studio, working in support means more than talking to clients. It also means reproducing a problem, writing code, solving the problem, and receiving pleasant thank-you words :)
We also write articles and participate in marketing activities to diversify our work. Just like I did with this article.
Our company also arranges team-building events for us: pool, kart racing, bowling, airsoft etc. Sometimes we have parties outdoors. For example, at this beautiful place:
Unfortunately, the pandemic has had an impact on this kind of activities.
If you do not have anything like this in your company, don't despair. You can fight this darned burnout by yourself. It's sink or swim, as they say.
To begin with, it's the joy you get when someone thanks you for solving their problem. Believe me, kind words are always nice to hear. And if your tireless efforts are involved – they are twice as pleasant to hear. Personally, moments like this have repeatedly charged me with positive energy and given me strength to keep working.
You can also play detective and amuse your inner little Sherlock. I'm talking about some complicated investigation when something, that in theory should always work, does not work. There are not that many clues, and that's when you start your investigation. I already wrote an article about one. The article covers an interesting case with WCF and TraceSource. You're welcome to read it, I'd like that :)
Also, remember to leave your work at work. I mean, try to immediately switch your thoughts to something else after working hours. It's perfect if you have a hobby. For me, it's music and games.
I hope that I successfully showed you how great support is, both for companies and clients. And to prevent getting burnout when working in support, you need to organize your work processes and rest in a particular way. Do not hesitate to talk to your managers :)
I'd like to hear how you deal with burnout. So please do share your experience in the comments.
Thank you for your time.
0
0
0
Your message has been sent. We will email you at
If you do not see the email in your inbox, please check if it is filtered to one of the following folders:
0