{"id":54148,"date":"2019-12-19T00:00:00","date_gmt":"2019-12-18T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-ya-perestal-boyatsya-i-polyubil-sapport"},"modified":"2020-02-18T14:02:07","modified_gmt":"2020-02-18T11:02:07","slug":"kak-ya-perestal-boyatsya-i-polyubil-sapport","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/kak-ya-perestal-boyatsya-i-polyubil-sapport","title":{"rendered":"How I stopped being afraid and learned to love support","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Do you remember the last time you contacted tech support? And that it was a pleasant experience? Neither do I. That's why, initially, at my first job, I had to keep reminding myself that my work was important and valuable. I had just started in support. I want to share my experience in choosing a profession and the conclusions I would have loved to read before I got a job myself. (Spoiler: support is cool).<\/p>\n

Experienced IT professionals are unlikely to find anything interesting here, but if you're just discovering the world of IT, welcome to the rest of the article. <\/p>\n

\"How
\n<\/a><\/noindex><\/p>\n

Press X to start<\/h2>\n

\nI spent my entire childhood playing computer games while awkwardly trying to socialize. In school, I started trying to program, but quickly realized it wasn't for me. Nevertheless, I went to university for an IT major, where I discovered that there are other paths in IT besides programming. By the end of university, I knew I wanted to go into administration. Infrastructure attracted me much more than coding, so when it came time to look for a job, I had no doubts. <\/p>\n

However, I couldn't become an administrator without work experience. For some reason, everyone wanted someone who knew how to handle IT infrastructure, or they offered tasks at the 'bring me this, bring me that' level. Undeterred, I kept searching until a friend told me about how, after a year in hosting support, he was able to improve his skills enough to become a sysadmin.<\/p>\n

At that time, I only knew what tech support was from my personal interactions with employees of various call centers. The usefulness of such communication seemed nonexistent to me. The idea of working with hardware and its configuration immediately appealed to me, but I viewed support as a sad period of life that I just had to endure. I mentally prepared myself for menial tasks, unyielding clients, and disrespect from real IT professionals<\/i>. <\/p>\n

However, I quickly realized that technical support is one of the most important parts of modern IT business. It doesn\u2019t matter what a company offers \u2013 IaaS, PaaS, whatever-as-a-service \u2013 clients will inevitably have questions and bugs, and someone will have to address them. I should clarify that this discussion will focus on second-line technical support, not call centers.<\/p>\n

Technical support, hello<\/h2>\n

\nI began my journey in the support department of a well-known Russian hosting provider, famous for its technical support. It didn\u2019t take long for me to encounter what I feared: clients<\/i> and their issues<\/i>. It turned out that a client may not understand what they want, they might not even grasp what their problem is, and they may not know whom they are contacting. I encountered people who asked to explain over the phone in two words how the internet works or wanted to know why they needed hosting<\/a>, if they don\u2019t need anything from the internet. However, despite the varying levels of questions, everyone needs a response. And once you start answering, you can\u2019t just end the conversation and leave the issue \u2013 even a simple one \u2013 unresolved. Of course, you could suggest that the person write a ticket for a simple problem, but they're unlikely to appreciate a response that is just a sentence and a half long. After a day. <\/p>\n

\"How
\n
\nIt was then that I understood another truth: technical support is the face of the company. Moreover, a person encounters it in a rather extreme situation: when everything is already broken, breaking right in front of them, or about to break. Ultimately, the impressions from communication and the quality of help will be perceived through the lens of stress. That\u2019s why a support employee must know their company's product well enough. After all, no client wants to explain to the support staff, whom they contacted for help, how the equipment they purchased works. Frantically googling during a conversation with a client is also less than enjoyable, even though it does happen.<\/p>\n

Another important point I overlooked: support can significantly facilitate and expedite the work of other employees in the company. If support collects the necessary information and formulates correct requests to the engineers, it saves a lot of time for developers and administrators. Does this mean that a support employee simply relays questions to the actual IT specialists? No! Because often, an experienced support specialist understands the product better than the developers who are responsible only for their specific area. It is precisely due to this understanding that support staff can formulate clear requests to developers without making them figure out the problem themselves.<\/p>\n

From this follows another, the most important point for me. Essentially, support is a talent incubator. Often, during the process of solving client problems, an understanding emerges of what can be changed, adjusted, or made more convenient in the current structure. For example, scripting routine tasks or setting up monitoring. This blend of client tasks, personal ideas, and free time gradually forges a true technician from a university graduate.<\/p>\n

Enterprise & Legacy<\/h2>\n

\nIn the end, I realized that this job is far more serious than I had previously thought. My attitude towards it has changed as well. When I was invited to work in L3 support at Dell Technologies, I began to feel a bit anxious. And after hearing scary terms like 'enterprise' and 'legacy' during the interview, I started envisioning the worst possible associations that could come with them. A large gray corporation, clients that are equally large gray corporations, outdated technologies, narrow development paths, and closed-minded cog-like people. I also became aware that the requests would not come from clients who do not understand what they need, but from other engineers who, on the contrary, know it very well. For them, the face of the company they interact with is not as important. What matters much more is that the production issue that happened at night is resolved with the least financial losses.<\/p>\n

\"How
\n
\nReality turned out to be much more pleasant than expected. Ever since my time working in night support, I remembered that sleep is important. And from my university days, I learned that people can have commitments during work hours. So, I viewed the transition from a rotating schedule (which was necessary for my master's program) to a full 5\/2 workweek as something threatening. When I was going to work in a 'gray enterprise,' I had almost resigned myself to the fact that I would no longer have personal time in the sunlight. I was very glad when I realized that I could come in when it was convenient, and if not, I could work from home. From that moment on, my perception of Dell Technologies as a gray enterprise began to fade.<\/p>\n

Why? First of all, because of the people. I immediately noticed that I didn't see the type of individuals I was used to encountering everywhere: people who are fine as is<\/i>. Some people truly just get tired of growing and are content at the level they stopped at. Some are dissatisfied with their job and consider it beneath their dignity to invest themselves fully in it. There are a few of them, but they left a strong and far from favorable impression on my young mind. By the time I was employed at Dell Technologies, I had changed jobs three times and had managed to convince myself that this was a normal state of affairs for any position and specialty. It turned out to be false. After meeting my new colleagues, I realized that I had finally found myself surrounded by people who always want to do something. 'Finally'\u2014because such individuals invariably start working as sources of external motivation. <\/p>\n

Secondly, I changed my mind because of the management. I thought that friendly management was characteristic of small companies, while in larger ones, especially those dealing with significant amounts of money, it was easier to encounter a hierarchy. Therefore, I expected strictness and discipline here as well. However, instead, I saw a genuine desire to help and participate in my development. The very opportunity to speak on equal terms with more experienced specialists or managers creates an atmosphere where one wants to try and learn something new, rather than just work within the confines of job descriptions. When I realized that the company was also interested in my development, one of my main fears \u2013 the fear of not learning anything in support \u2013 began to leave me.<\/p>\n

At first, I thought working in L3 support was so specialized that this knowledge wouldn't be useful elsewhere. However, as it turned out, even when working in a narrow field and with a proprietary product, you will inevitably interact with its environment \u2013 at the very least, the operating system, and at most \u2013 with an endless number of programs of varying complexity. By delving into the operating system in search of the cause of a particular error, you can personally encounter its low-level mechanics, rather than reading about them in books without understanding how they work and why they are needed. <\/p>\n

Unpacking<\/h2>\n

\nWorking in support turned out to be completely different from what I expected. I was quite anxious at the time, so I want to outline a few points that I would have liked to hear myself when applying for my first job.<\/p>\n