Here is the promised “different story.”
Challenge
If someone had asked me four years ago, “How can we teach newcomers in the IT department/company?” — I would have immediately said, “By the method ‘monkey sees — monkey does,’ that is, attach the newcomer to a more experienced employee and let them watch how typical tasks are performed.” 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 — and they did!
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 — the fact is, this method can only work for those already “in the know,” who understand the specifics of the work and need some non-critical details.
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?
Let’s 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 “green”) engineer, a university graduate who is smart and resourceful. There's just one catch — this person has no experience in support or even basic helpdesk, and they will be the first Turkish-speaking engineer in your company.
How will you tackle this challenge?
And when you answer this question (and you will answer, I believe in you), let’s complicate the task — 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’t want to run away as quickly as possible?
(Please think about this question before reading further.)
Our Story
This is exactly the challenge we faced.
While our department was relatively small, the scheme of 'assigning a mentor to a newcomer, providing a list of documents, and letting them work — sink or swim' worked well. It was a good, universal scheme, tested over years and even centuries of human experience — but at some point, we realized we were tired of repetition. Each newcomer needs to be told certain things — 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 — which is a risk.
And here we recall another equally traditional scheme — gathering newcomers into groups and giving them lectures — this is how our training program originated.
... Sometimes our engineers participate in conferences — both internal and external, organized by others and by us ourselves. It was from one of these events that the current support training began.
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.
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 — starting with the 'hardware' and gradually increasing the levels of abstraction: Disk API, Operating Systems, Applications, Networking, Virtualization.
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.
What else, besides that?
I 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—reading manuals, working in the lab, resolving test and live tickets, etc.
The 20% training is actually almost 100% theoretical base, but theory alone won't get you far—the classic Knowledge-Skills-Expertise scheme applies. We can provide Knowledge, but developing Skills and turning them into Expertise is a completely different task.
This is precisely why our initial theoretical lectures have quickly evolved to include other components, and now the overall structure looks like this:
- Lectures/Training;
- Independent Work;
- Mentorship.
The first point is clear: we take a group of beginners, teach them theory, and smoothly transition to the second point, assigning a 'homework' task at the end of the lecture—a practical assignment that the beginner must 'play out' in the lab and submit a report in some form (usually a free format, but exceptions do exist).
We intentionally formulate tasks in a rather general manner, avoiding precise instructions like 'go here, do that, write down what you see.' Instead, we simply set a task (for example: deploy a virtual machine with this list of components) and ask them to conduct some 'research' on the resulting output, without delving into how to do it or how to verify the results. This is aimed at teaching beginners (especially those who are far from the IT world at the beginning of their journey and how the engineering community thinks) independent thinking, documentation reading skills, problem-analysis capabilities, and, importantly, an understanding of their own limits.
We all know that sometimes solving a problem leads to a dead end, as if a wall grows ahead that can't be broken through. Understanding when it's worth continuing to hit your head against it, and when it's time to find someone who can help—this is also a very important skill for an engineer working in a team.
In our setup, a mentor serves as this 'helper' for the beginner.
It is simply impossible to overestimate a mentor. Just consider this: they are the first 'point of contact' for every newcomer assigned to them, the one who can answer most questions and assist in most situations — and correct those bad patterns (in technical aspects, business ethics, and company culture) that may be overlooked by a trainer or even a team lead.
Is that all about them?
Lectures, mentorship, and self-directed learning — these are the three main building blocks of our educational program. But is that all there is to say? Of course not!
Even with a solid framework, four complete training programs (with a fifth one on the way), we do not stop gathering our 'stuff'. Education is as alive as our product is, and thus new information and new ways to convey it are constantly emerging.
For example, an important milestone for us was realizing that we are indeed repeating school/university education to a greater extent than we thought, and it doesn't always work. We teach adults with experience, fears, and preferences of their own. This 'school' system can be a bit intimidating for people (let's call a spade a spade — in 95% of cases, any frustration stemming from the school model arises from fear): we have all gone through school and university, and often it has been a traumatizing experience, so we certainly do not want to relive it.
From here, we start (yes, we are only just beginning, but 'a journey of a thousand miles begins with a single step'...) to reshape our approaches. We remembered/discovered andragogy (education for adults, as opposed to pedagogy, which is essentially about educating children) with its focus on experience, understanding objectives, nuances of information retention and learner comfort, the importance of the emotional component (which is even more significant for children), and the necessity of practical application, among other factors. We learned about and now we turn our training sessions around, thinking about how to bring even a completely 'out-of-the-loop' person to a training with some initial experience that we can help update, complement, deepen, and polish, and, importantly, provide not just bare theory, but practical knowledge that can be transformed into skills with the help of a mentor or independently.
We invited business coaches who worked extensively with our lecturers on public speaking, discussed emotions, trained assertiveness, provided tools for managing group dynamics, and, of course, helped us answer the questions of “what do we want from training?” and “what is our ultimate goal?”. The results are already in — some training sessions, which received the most feedback like “boring and unclear,” are now considered some of the most interesting and engaging — even though the lecturer remains the same!
Recently, we welcomed a couple of very cool and motivated individuals who spoke about Knowledge Centered Support and how to build video courses — and we gleaned many great ideas from them on how to revamp our courses and move away from the “webinar-recording style” to create beautiful and straightforward courses that explain everything we want clearly and don’t let information overload become a problem.
Moreover, we are now focusing not only on the technical aspects of training, i.e., the so-called hard skills, but we are also working on soft skills, not just for lecturers or management, but for engineers as well. We are doing this so that a new hire like Ignat can practice the skills he will need 100% in his job, manage his emotions, and know that in any situation, no matter how challenging or desperate, he won't be alone: support is about people, and “we don’t abandon our own in trouble.” Before the first incoming phone calls, we will role-play with the newcomer to help them get into the process and find their response style; before the first cases, we'll discuss how to work with them best and what to watch out for, and we will support and guide throughout the entire process.
We are support. And who should we support first if not our own?
And finally, a few words...
I am aware that my story sounds complimentary. And I am not bragging — this is our story, our present, and just a small part of our plans for the future.
Our training is far from perfect. We have many shortcomings and we’ve made a ton of mistakes — oh my! We receive a lot of feedback, and more often than not it isn’t positive; people write to us about problems, issues, and desired improvements — and since we train worldwide, we get such a diverse range of feedback, especially when considering cultural differences...
We have room for growth, and thank God we have those who are willing to work, criticize, discuss, and propose new ideas. This is a great resource and significant support.
Support is all about people — it is people who make training effective, helping new employees start contributing sooner and grow into excellent engineers faster, and great engineers make the world better.
... and with that, allow me to conclude my permitted remarks.
Source: habr.com
