Here is the promised “other story”.
Challenge
If four years ago I was asked: “How can I train newcomers in the IT department / company?” - I, without hesitation, would give out: “According to the“ monkey sees - the monkey imitates ”method, that is, attach a beginner to a more experienced employee, and let him watch how typical tasks are performed.” This approach worked for me before, it still works now, and some time ago in Veeam, when the trees were big, the logos were green, and the product was small, it was also possible to train - and trained!
Gradually, the product became large and complex, there were more and more new engineers, and the RTFM (Read The Freaking Manual) style approach worked worse and worse - the fact is that those who are already “in the know” can learn this way, who understands the specifics of the work and needs some, not so critical details.
But what about those who come from adjacent areas and want to grow and develop, but do not know how to approach this? What about, for example, those who speak a conditionally rare language (for example, Italian, which is rare for an average IT specialist)? Or how to train a promising university graduate who does not have much work experience under such a scheme?
Let's interrupt our story for a second and imagine: here you are, a team leader in the support team, yourself a good and successful engineer in the past, with extensive experience in system administration and communication with different people. Your task is to pass on your experience to a new (one might even say “green”) fighter-engineer, a university graduate, smart and quick-witted. There is only a nuance - this is a person without support experience and even a banal helpdesk, and he will also be the first Turkish-speaking engineer in your company.
How will you solve this problem?
And when you answer this question (and you will answer, I believe in you), let's complicate the task - what if there are ten such engineers? What if twenty? But what if this is a continuous development of the department, and at any given time there will be a newcomer who needs to be trained, show a minimum standard of work quality (and this standard is high) and make sure that the person does not want to run away as quickly as possible?
(Please consider this question before reading further.)
Our Story
This is the challenge/task we are facing.
While the department would be relatively small, the scheme “give the newcomer a mentor, a list of documents and stop working - swim or drown” worked well. The scheme is good, universal, proven over the years and even centuries of universal human experience - but at one point we realized that we were tired of repetitions. Each newcomer needs to be told some things - the same thing that can be useful to him in his work. In the “traditional” scheme, this is done by the mentor, but what if some mentor has wards going one by one? Repeating the same thing quickly gets boring, burnout sets in - and this is already a risk.
And then we remember another, no less traditional scheme - to gather newcomers into groups and give lectures to them - this is how our training program was born.
… Sometimes our engineers participate in conferences - both internal and external, third-party and organized by ourselves. It was with such our event that training in support began, as it is now.
One of our engineers gave a brilliant presentation at VeeamOn in Las Vegas about what pieces Veeam Backup & Replication is made of, and with a little tweaking it became a lecture “Components”. By this time, we already had several lectures on different parts of the functionality, but it was that lecture that “set the tone” for everyone who was before and after. It was the way that lecture was structured, what materials were used, and so on, that became the standard for us.
We began to talk a lot about virtualization, Microsoft technologies, our own products, introduced basic trainings for our beginners without IT experience, where we tell everything that a support engineer might need - starting with hardware and increasing levels of abstraction: Disk API, Operation Systems, Applications, Networking, Virtualization.
Of course, we understood and understand that it would be impossible or at least unreasonable to try to cover the entire range of technologies that we use with trainings. It already takes several months to teach all the features of one product, but the product does not stand still, and something new appears all the time. In addition, only training-lectures, as they are, cannot give everything that a future engineer needs.
What else besides?
I like to say that the Pareto rule works for us: with our trainings, we give about 20% of what a successful engineer needs, and 80% remain on his conscience - reading manuals, working in the lab, solving test and combat requests, etc.
20% - trainings - in fact, this is almost 100% of the theoretical base, but you can’t achieve everything with theory alone - the classic Knowledge-Ability-Skills scheme works. We can give Knowledge, but developing Skills and turning them into Skills is a completely different task.
That is why our initial theoretical lectures were supplemented with other things very quickly, and now the general scheme looks like this:
- Lectures/trainings;
- Independent work;
- Mentorship.
Everything is clear with the first point: we take a group of beginners, read the theory to them and smoothly move on to the second point, giving out “homework” at the end of the lecture - a kind of practical task that the beginner must “play out” in the lab and provide a report in some form ( Usually the form is free, but there are exceptions).
We deliberately formulate tasks in a rather general way, avoiding precise instructions “go there, do that, write down what you see”. Instead, we just set a task (for example: deploy a virtual machine with this list of components) and ask us to do some “research” with the result obtained, without going into how to do it or how to check the result. With this, we want to teach beginners (especially those who are far from the IT world and how the engineering fraternity thinks at the beginning of their journey) independent thinking, the skill of reading documentation and analyzing emerging problems, and, very importantly, understanding their limits.
We all know that sometimes the solution to a problem leads to a dead end, as if a wall grows ahead that cannot be broken through. And understanding when it’s worth continuing to beat your head into it, and when it’s time to find someone who can help is also a very important skill for an engineer working in a team.
We have a mentor as such a “helper” for a beginner.
It is simply impossible to overestimate a mentor. Judge for yourself, he is the first “point of contact” for the newcomer assigned to him, the one who can answer most questions and help in most situations - and correct those bad patterns (in the technical part, in business ethics, in the culture of the Company), which both the coach and even the team leader can miss.
And it's all about him?
Lectures-trainings, mentoring, independent work - these are the three main building blocks that make up our training program. But is that all there is to say? Of course not!
Even with a good scheme, four full training programs (the fifth one is on the way), we do not stop collecting our “trods of plows”. Learning is as alive as our product is, and so there is always new information and new ways to deliver it.
For example, an important milestone for us was the realization that we are really repeating school / university training a little more than completely, and it does not always work. We teach adults, with experience, with their own fears and preferences. And such a “school” system scares people a little (let’s call a spade a spade - in 95% of cases, any frustration due to the school model comes from fear): we all went through school and university in one way or another, and most often it was all a traumatic experience, so I don’t want to repeat it at all.
From here we begin (yes, we are just starting, but “a journey of a thousand miles…” and so on) to remake our approaches. We remembered/learned about andragogy (teaching adults - as opposed to pedagogy, which, in fact, is about teaching children) with its focus on experience, understanding of goals, with nuances about the assimilation of information and the comfort of trainees, the importance of the emotional component (for children, this is even more importantly), the need for a practical component, and so on. Learned about and now we are spinning our trainings, thinking how can we even bring a person who is absolutely “out of touch” to a training already with some experience, which we will help to update and supplement, deepen and comb, and, importantly, give not only a bare theory , but also practical knowledge that can be transformed into skills with the help of a mentor or on your own.
We invited business coaches who did a lot of work with our lecturers on public speaking, talked about emotions, trained assertiveness, gave tools for managing group dynamics and, of course, helped us answer the questions “what do we want from training?” and “what is our end goal?”. The results are already there - some trainings that collected the most feedback in the style of “boring and nothing is clear” are now called perhaps the most interesting and sincere ones - but the lecturer has remained the same!
And just recently, a couple of very cool and motivated guys came to us, talking about Knowledge Centered Support and how to build video courses - and we got a lot of good ideas from them on how to remake the latter and get away from “recording a webinar-style” into beautiful ones. and simple courses that simply and clearly tell everything we want, and do not allow us to drown in a variety of methods of providing information.
Moreover, now we are engaged not only in the technical component of education, that is, the so-called hard skills, but also work with soft skills, not only for lecturers or management, but also for engineers. We do this so that the conditional Ignat, when he comes to the company, can train the skills that he will 100% need in his work, be able to manage his emotions, and know that in any, even the most difficult and hopeless situation, he will not one: after all, Support is about people, and “we don’t leave our own in trouble.” Before the first incoming phone calls, we will play role-playing games with the newcomer, helping to get involved in the process and find their own style of answers, before the first cases we will tell you how best to work with them and what to look for, and we will follow and help throughout the process.
We are support. And who should we support in the first place, if not our own?
And in conclusion, a few words ...
I am aware that my story sounds laudatory. And at the same time, I am not boasting - this is our history, our present and just a small part of our plans for the future.
Our training is never perfect. We have many shortcomings, and we made mistakes - dear mother! We receive a lot of feedback, and most often it is not laudatory, they write to us about problems, shortcomings, desired improvements - and since we teach worldwide, we get a lot of diverse feedback, and if we also take into account cultural characteristics ...
We have room to grow, and thank God, we have those who are ready to work, criticize, discuss and offer something new. This is a great resource and great support.
And Support is about people - it's people who do the training, training helps new employees start to be useful earlier and grow into good engineers faster, and good engineers make the world a better place.
…and with that let me end the permitted speeches.
Source: habr.com