{"id":53316,"date":"2019-11-29T00:00:00","date_gmt":"2019-11-28T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/chemu-ne-uchat-v-shkole-kak-my-gotovim-inzhenerov-tehpodderzhki"},"modified":"2020-02-18T14:01:12","modified_gmt":"2020-02-18T11:01:12","slug":"chemu-ne-uchat-v-shkole-kak-my-gotovim-inzhenerov-tehpodderzhki","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/chemu-ne-uchat-v-shkole-kak-my-gotovim-inzhenerov-tehpodderzhki","title":{"rendered":"What they don't teach in school: how we prepare support engineers","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Here is the promised \u201cdifferent story.\u201d<\/p>\n

\"What
\n<\/p>\n

Challenge
\n<\/h3>\n

\nIf someone had asked me four years ago, \u201cHow can we teach newcomers in the IT department\/company?\u201d \u2014 I would have immediately said, \u201cBy the method \u2018monkey sees \u2014 monkey does,\u2019 that is, attach the newcomer to a more experienced employee and let them watch how typical tasks are performed.\u201d This approach worked for me before, it works now, and some time ago at Veeam, when the trees were tall, the logos were green, and the product was small, this was also a way to train \u2014 and they did!<\/p>\n

Gradually, the product became larger and more complex, the number of new engineers kept increasing, and the RTFM (Read The Freaking Manual) approach worked less and less \u2014 the fact is, this method can only work for those already \u201cin the know,\u201d who understand the specifics of the work and need some non-critical details.<\/p>\n

But what about those who come from adjacent fields and want to grow and develop but don't know how to approach it? What about those who speak a relatively rare language (for example, a language that is uncommon for an average IT person, such as Italian)? Or how to train a promising university graduate who has no significant work experience?<\/p>\n

Let\u2019s pause our story for a moment and imagine: you, a team leader in the support team, who was once a good and successful engineer with extensive experience in system administration and communication with various people. Your task is to pass on your knowledge to a new (we can even say \u201cgreen\u201d) engineer, a university graduate who is smart and resourceful. There's just one catch \u2014 this person has no experience in support or even basic helpdesk, and they will be the first Turkish-speaking engineer in your company.<\/p>\n

<\/a><\/noindex>How will you tackle this challenge?<\/p>\n

And when you answer this question (and you will answer, I believe in you), let\u2019s complicate the task \u2014 what if there will be ten such engineers? What if there are twenty? What if this is a constant development within the department, and at any moment there will be a newcomer who needs to be trained, shown a minimum standard of quality work (and this standard is high), and ensure that the person doesn\u2019t want to run away as quickly as possible?<\/p>\n

(Please think about this question before reading further.)<\/p>\n

\"What
\n<\/p>\n

Our Story<\/h3>\n

\nThis is exactly the challenge we faced. <\/p>\n

While our department was relatively small, the scheme of 'assigning a mentor to a newcomer, providing a list of documents, and letting them work \u2014 sink or swim' worked well. It was a good, universal scheme, tested over years and even centuries of human experience \u2014 but at some point, we realized we were tired of repetition. Each newcomer needs to be told certain things \u2014 the same information that may help them in their work. In the 'traditional' scheme, this is handled by the mentor, but what if a mentor has several mentees in a row? Repeating the same things quickly becomes tedious, leading to burnout \u2014 which is a risk.<\/p>\n

And here we recall another equally traditional scheme \u2014 gathering newcomers into groups and giving them lectures \u2014 this is how our training program originated.<\/p>\n

... Sometimes our engineers participate in conferences \u2014 both internal and external, organized by others and by us ourselves. It was from one of these events that the current support training began.<\/p>\n

One of our engineers presented at VeeamOn in Las Vegas with an impressive presentation on the components of Veeam Backup & Replication, and with a few adjustments, it became the lecture 'Components.' By that time, we already had several lectures on different functional areas, but that particular lecture 'set the tone' for all those that came before and after. It was the structure of that lecture, the materials used, and more that became our standard.<\/p>\n

We began discussing virtualization, Microsoft technologies, and our own products extensively, introduced basic training for our newcomers with no IT experience, where we cover everything a support engineer may need \u2014 starting with the 'hardware' and gradually increasing the levels of abstraction: Disk API, Operating Systems, Applications, Networking, Virtualization.<\/p>\n

Of course, we understood and understand that attempting to cover the entire spectrum of technologies we use with training would be impossible or, at least, unreasonable. Teaching all the features of a single product already takes several months, and the product itself does not stand still, constantly introducing something new. Furthermore, lectures and training as they are cannot provide everything a future engineer needs.<\/p>\n

What else, besides that?<\/h3>\n

\nI love to say that we operate under the Pareto principle: our training provides about 20% of what a successful engineer needs, while the remaining 80% is up to their own responsibility\u2014reading manuals, working in the lab, resolving test and live tickets, etc.<\/p>\n

The 20% training is actually almost 100% theoretical base, but theory alone won't get you far\u2014the classic Knowledge-Skills-Expertise scheme applies. We can provide Knowledge, but developing Skills and turning them into Expertise is a completely different task.<\/p>\n

This is precisely why our initial theoretical lectures have quickly evolved to include other components, and now the overall structure looks like this:<\/p>\n