Challenge
If four years ago I was asked: âHow can I train newcomers in the IT department / company?â - without hesitation, I would give out: âBy the method ofâ a monkey sees - a monkey imitates â, that is, attach a newcomer to a more experienced employee, and let him see how typical tasks are carried out. â This approach worked for me before, it works now, and some time ago in Veeam, when the trees were large, the logos were green, and the product was small, it was also possible to train - and taught!
Gradually, the product became large and complex, new engineers became more and more, 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 came from related areas and want to grow and develop, but donât know how to approach this? What about, for example, those who speak relatively rare language (for example, Italian, rare for the 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 transfer your experience to a new (even one can say âgreenâ) engineer fighter, a university graduate, clever and quick-witted. There is only a nuance - this is a person without experience of support 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 answer, I believe in you), let's complicate the task - what if there are ten such engineers? And if twenty? And if this is the constant development of the department, and at any moment there will be a newcomer who needs to be trained, show the minimum standard of quality of work (and this standard is high) and make sure that the person does not want to escape as quickly as possible?
(Please consider this question before reading further.)
Our story
It is with this challenge / challenge that we are faced.
While the department was conditionally small, the scheme âto give a beginner a mentor, a list of documents and quit work â swim or drownâ worked well. The scheme is good, universal, tested over the years and even centuries of universal experience - but at one moment we realized that we were tired of repetition. Each newcomer needs to be told some things - the same thing that can come in handy in his work. In a âtraditionalâ scheme, a mentor does this, but what if a mentor goes one by one? Repeating the same thing quickly bothers, burnout occurs - and this is a risk.
And here we recall 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, external and organized by ourselves. It was from such an event that our training in support began, as it is now.
One of our engineers spoke at VeeamOn in Las Vegas with a brilliant presentation about which pieces Veeam Backup & Replication consists of, and with minor modifications it became a lecture âComponentsâ. By this time, we already had several lectures on different parts of the functional, but it was precisely that lecture that âset the toneâ for everyone before and after. Exactly how that lecture was built, what materials were used and so on, 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 experience in IT, on which 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 will be impossible, or at least unreasonable, to try to cover with trainings the whole range of technologies that we use. To train all the features of one product, it takes several months now, but the product does not stand still, and all the time something new appears. Moreover, only training lectures, as they are, cannot give everything that a future engineer needs.
But what except?
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 a lab, solving test and combat requests, etc.
20% - training - in fact, it is almost 100% of the theoretical base, but you canât achieve everything with one theory - the classical scheme of Knowledge-Skills-Skills works. We can give Knowledge, but to develop Skills and turn them into Skills is a completely different task.
That is why it is possible very quickly our initial theoretical lectures were supplemented with other things, and now the general scheme looks like this:
- Lectures / trainings;
- Independent work;
- Mentoring.
Everything is clear with the first paragraph: we take a group of newcomers, read the theory to them and smoothly proceed to the second paragraph, giving out at the end of the lecture âhomeworkâ - a kind of practical task that the newcomer should âplayâ in the lab and provide a report in some form usually the form is free, but there are exceptions).
We intentionally formulate the tasks in a fairly general way, avoiding the exact instructions âgo there, do that, write down what you see.â Instead, we only set the task (for example: deploy a virtual machine with this list of components) and ask that we perform some kind of âresearchâ with the result, without going into how to do this or checking the result. We want to teach newcomers (especially those who are far from the IT world at the beginning of their journey and how the engineering fraternity thinks) the independence of thinking, the ability to read documentation and analyze problems that arise, and, very importantly, understand their limits.
We all know that sometimes a solution to a problem leads to a dead end, as if there is a wall in front that cannot be penetrated. And to understand in which cases it is worth continuing to bang your head into 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.
We have such a âhelper" for a beginner is a mentor.
Overestimating the mentor is simply impossible. 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 fix those bad patterns (in the technical part, in business ethics, in the culture of the Company), which can be missed by both the coach and even the team leader.
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 that can be said? Of course not!
Even with a good scheme, four complete training programs (the fifth on the way), we do not stop collecting our âplod trodesâ. Learning is as lively as our product is lively, and therefore, new information is constantly appearing, as well as new ways to convey it.
For example, an important milestone for us was the understanding that we do repeat school / university studies a little more than completely, and it does not always work. We teach adults, with experience, with our fears and preferences. And such a âschoolâ system of people is a little scary (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 one way or another, and most often it was still traumatic experience, so I donât want to repeat it at all.
From here we begin (yes, only begin, but âa journey of a thousand ...â and so on) to redo our approaches. We remembered / learned about andragogy (adult education, as opposed to pedagogy, which, in essence, is about teaching children) with its focus on experience, understanding goals, with nuances about the assimilation of information and comfort of students, the importance of the emotional component (for children more important), the need for a practical component, and so on. We learned about the Kolb cycle and now we are twisting our trainings, thinking how we can even bring a person absolutely âoff topicâ to the training with some experience that we will help to update and supplement, deepen and comb, and, importantly, give not only bare theory, but also practical knowledge that can be transformed into skills with the help of a mentor or independently.
We invited business trainers 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 âwhich is our ultimate goal? â There are already results - some of the trainings that collected the most feedback in the style of âboring and nothing is clearâ are now called almost the most interesting and sincere - but the lecturer remained the same!
And just recently, a couple of very cool and motivated guys came to us who talked about Knowledge Centered Support and how to build video courses - and we got a lot of good ideas from them, how to remake the latter and get away from the âwebinar-style recordingâ into beautiful and simple courses that simply and clearly tell everything that we want, and do not allow you to drown in a variety of methods for providing information.
Moreover, now we have taken up not only the technical component of training, that is, the so-called hard skills, but also work with soft skills, not only for lecturers or management, but also for engineers. We are doing this so that the conditional Ignat, coming to the company, can train those skills that he will be 100% required in 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 people 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 our own style of answers, before the first cases we will tell you how to work with them better and what to look at, and we will monitor and help throughout the process.
We are support. And whom do we support in the first place, if not ours?
And in conclusion, a few words ...
I am aware that my story sounds laudatory. Nor do I brag - this is our story, our present and only 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 get a lot of feedback, and most often it is not laudatory, they write to us about problems, shortcomings, desired improvements - and since we train worldwide, we get a lot of diverse feedback, and if we take into account the cultural features ...
We have room to grow, and thank God, we have those who are ready to work, criticize, discuss and propose new things. This is a great resource and great support.
And Support is about people - it is people who do the training, training helps new employees to start to benefit earlier and grow into good engineers faster, and good engineers make the world a better place.
... and on this let me finish the permitted speeches.