“Am I a trembling creature or do I have rights?”
To be honest, I had this thought in my head for a long time and understood that sooner or later it would break out. At the same time, I understand the essence of “technical support pain” very well, since I worked there for 3 years at the dawn of my IT career. Then I began to develop further and looked at technical support from the side of a project manager, development manager and deputy IT director. And now, 20 years later, realizing that my view has become impartial, this thought has finally broken out in the form of a desire to write an article.
But let's first digress and try to look at IT in general “through the eyes of the User”. So, what does a business-oriented User imagine when he hears or says the word “IT specialist”?
Some, hearing this word, still imagine a guy in a sweater, or glasses, with a shaggy head and “a little bit of that”, speaking in a language incomprehensible to normal people, etc. Others, on the contrary, imagine a guy in a shirt with a tie or a suit. And in fact, the word “IT specialist” now covers a whole bunch of narrowly focused specialties:
product managers,
project managers,
infrastructure managers,
IT Architects,
team leads,
systems engineers,
network engineers,
business analysts,
interface designers,
release managers,
environment and service engineers,
testers (there is a whole gradation here: alpha, beta, load, integration, regression),
developers (and they are also divided into areas: front-end, back-end, integration and API, mobile applications, WEB services, etc., etc.).
And I haven’t even gotten to the narrow specialties like Bid Data, AI, SaaS, where there are Data Scientists, AI Engineers, etc., etc.
In general, the set of IT specialties is just like the credits at the end of a film, where we see that behind the 2 main characters of this blockbuster (the main developer and the project manager) there are several hundred people, thanks to whom this film (IT product) was created and released – do you feel the analogy?
So, having imagined this whole bunch of noble people who participated in the creation and launch of the software product (the whole list quickly running before our eyes in the credits after the film), we approach the issue of technical support for the launched IT product and ask ourselves the question:
“What if the product suddenly develops an error or starts to glitch?”
And here we remember about technical support. And it must be said frankly that some users have an established attitude towards technical support as some kind of lower service link. Like a janitor, or that guy who drives a garbage truck and rolls garbage bins to it. And if suddenly something falls out of these bins, then he must show an “instant reaction”, pick it up and “annihilate this bug” as quickly as possible, without disturbing the User's “refined perception of the world”.
Well, that's true, isn't it?
And only those of you who understand the importance and complexity of the work of technical support itself will disagree with me now:
compliance with the SLA (service level agreement), which regulates the timeframes for “instant response”, as well as the timeframes for fixing errors “to annihilate the bug”;
ensuring a positive user perception of the product and the team as a whole, i.e. under no circumstances should we disturb the user's “refined perception of the world” and be almost a psychologist, not allowing the “righteous anger of the User” to ignite a third world war;
properly organize the correction of the found bugs, i.e. understand their causes, go through the FAQ, check the version of a possible error from the user's side, sometimes even understand the logs. Set tasks for developers, testers, release managers, etc. and then tirelessly monitor the deadlines so that the fixes do not go into “next year's release”;
and most importantly – internal motivation and constant resolution of the internal conflict “who am I and where do I want to develop?”
In other words, a good tech support specialist will almost always secretly envy and compare himself to those brave noble guys from development/design who create and implement new features and modules, while he has to “sort out dirty laundry”.
Here, of course, we can start talking about dividing technical support into 1st, 2nd, 3rd lines, each of which is covered by specialists of different levels and allows us to “spread out the area of responsibility”, distributing it among different specialists.
But answer yourself honestly: have you never felt irritated when you contact one specialist to solve your problem, and he transfers it to a second, and then a third? As a person, you will still wait for a specific person in charge – the one who is currently dealing with your problem. And “passing the baton” to the next support line usually causes increased irritation and negativity, which spills over onto the new person in charge of solving your bug.
Agree that in such a situation, technical support employees have to think very often about self-motivation and find a core within themselves so as not to break down (not to give up this thankless position and not to go, for example, to analysts or developers). And to continue to work “with fire”, to sort out endless bugs and solve problems of Users, periodically encountering their negativity.
If your team has a great support team that knows how to communicate with Users “like a team of psychologists” and is very knowledgeable about the features of an IT product, right down to competent analysis of details, logs and filling out FAQs, then you are lucky.
After all, a good technical support specialist can easily become the savior of your product (film). The one who, at a difficult moment of “the emergence of an unforgivable bug” (which was 100% missed by all those brave guys from the credits), will prevent a World War with the User simply because it is his calling – to be a “Fighter of the invisible front” and save the Motherland in difficult moments.
It is precisely these motivated and technically savvy IT support specialists who are capable of not only registering requests and transferring calls, but also reducing the “heat of passions” and simultaneously understanding the problem and solving it, that are extremely important to find and retain.
I understand that my views do not claim to be the “ultimate truth”. But I also sincerely hope that they will allow us to swing the pendulum of perception of the work of technical support a little in the other direction and look at these (often underestimated) guys from a different angle.
Think about it – without them the IT world would not be so clean and beautiful!
