New employee - dead or alive

Hello! I continue to talk about management experience in IT. Today we’ll talk about introducing a new employee to the team. You have hired an engineer. When will it become a full-fledged combat unit? What to do to accelerate its adaptation? How to optimize this process? After all, is it worth it to pay attention to it and spend time?


I will begin with the answer to the last question: definitely yes. No matter how experienced the specialist, he needs time to delve into the technical details of a particular project, familiarize himself with the development process, and finally meet new colleagues. This is really important for the company: the faster it starts to fully solve problems, the faster it starts to benefit the company.

I believe that entering a new employee into the team is an extremely important process, and the more debugged it is, the faster the newcomer becomes a full-fledged employee and the less time you spend on it.

Beginner to Colleague Transformation

When I worked in a service aggregator of used spare parts, it took 3 days to introduce new people to the team. After that, they and the others solved the current tasks on equal terms, participated in discussions and joked with colleagues at the coffee machine. But I did not come to this, of course, right away, at first I had to fill up the bumps and gain experience. Only then I formed the basic principles for myself and built the process.

Here are the main nuances that I learned for myself from the practice of team management.

1. Entering a person in a team should begin with an introduction to the project. And this I did already at the interview. I always had ready a 10-minute story about the company as a whole, what it earns from, how the service works, the structure of departments and more.
2. Preparation of the workplace and creation of comfortable working conditions. On the first day, a person should sit at his desk with a comfortable chair or armchair and turn on an already configured computer. Do not have time to prepare all this? Your cant, this really needs attention.
3. Individual approach. For example, to create comfort (and it is necessary, especially in conditions of stress when moving to a new job). It’s nice to ask about preferences in terms of the operating system and keyboard / mouse. Maybe you will be the first employer to offer this. And this will raise your company in the eyes of the employee.
4. Correct acquaintance with the team. It’s not enough just to imagine the names of all employees and go to workplaces. You can do this: this is Misha, he is responsible for the backend, this is Petya, he is DevOps, and Vasya and Kolya are responsible for the client part, they can be asked questions about such and such aspects. And all this should be reflected in the official documentation for employees, but more on that below.
5. Acquaintance with the company. I believe that it is best to conduct it in departments and tell how the company is organized inside, how the interaction between employees is established. It will come in handy in the future.
6. Gen. A new engineer must know such trivial things, where is the restroom, how to use a coffee machine and where you can heat food. A great step towards closer relations with colleagues is to invite him to dinner with the team.
7. The principles of the team. Everywhere its own terms and conditions. For example, it was customary for our team to work according to a flexible schedule, anyone could come at a convenient time for him or take a day off on business or work from home. But in the event of a release or emergency situations, we lingered and solved the problem together. The team also had a friendly atmosphere, we treated each other with respect, and expected this from newcomers.

In general, I have not discovered any secrets, but these aspects are really of great importance. The first impression is very important, it is from him that the person will form an opinion about the company and its place in it.

Another crucial factor is stress reduction. It is inevitable, since the transition to a new job is a way out of the comfort zone, all people are different, not everyone knows how to cope well with this. Your task is to smooth out the process of joining a person to the team. And here attention to details is important. For example, a person may be shy to ask to replace an uncomfortable keyboard. Or if you see that he is an introvert, be more delicate and do not bring him under the spotlights to the center of the open space arena when meeting a team.

How to quickly load a newbie into a project and not kill it

A man came to work with you, you introduced him to colleagues and the company as a whole, created comfortable conditions. It's time to get to work. After all, your task is to get him involved in the development process and begin to benefit the company as quickly as possible. And in this situation, the main thing is not to sort out with speed. Immerse the newly minted colleague in work smoothly.

So, below are the main steps that allow me to quickly and painlessly turn a beginner into a full member of the team.

1. Story about the project. I believe that first you need to talk about the project from the point of view of customers. Why is it needed, how does it work, what problems does it solve? And only then can we move on to what is “under the hood” and show how it is arranged inside. To save time, you can record a video once. It is only necessary to monitor its relevance. If you can’t do it yourself, give the task to colleagues.
2. Project structure. It is important to show what your service consists of, which modules include, how they interact with each other.
3. Knowledge base. Be sure to write technical documentation. She will be a ray of light and a guide to the wilds of your project for a beginner. It should be everything: from the principles of naming branches and the rules for creating pull request in Git to the description of the server infrastructure and a set of technical tools.
4. Raising the project. Help the newcomer to deploy the project, do not drop it at this stage. Even an experienced programmer can save before such a task when everything is confused there. To speed up this process, write instructions. But you can save even more time if you do this in advance and configure the project assembly process itself.
5. From simple to complex. In two days, tell about everything, and then throw the newcomer into the embrasure and force them to cut new complex features? Great plan to fail. The resources of the human brain are not unlimited; introduce it gradually. Spend quite a bit of time and pick him tasks with increasing complexity, gradually bring him to the desired level of difficulty.

Again, I did not say anything new, but for some reason, many companies continue to make such mistakes. And then they are surprised that a person with great experience makes annoying mistakes. It is logical to draw my favorite analogy with sports: a professional player knows how to kick the ball and deftly pass, but without knowledge of the team’s tactics and strategy, there will be no sense in it and results. That is why a coach is needed to help the player become part of the team. If you are a team leader, then the introduction of new people to the team should lie with you. Lack of time and other reasons, these are just excuses. This is a really important process that no one will fix for you.

Life stories

Below I will share instructive cases from my own practice. I also did not immediately succeed in debugging the process, I went to this through errors.

About raising a project

When my team was very small, to new employees, we lifted all the services from scratch on each machine. Of course, I spent a lot of time on it or took it from my colleagues when I asked them to help. With the growth of the company and the IT department, this became a headache.

I admit, I missed this moment. In addition, this caused problems not only with beginners. When one of the employees needed to raise the service that another team was writing, they were ready to shoot themselves. And if at once it was necessary to raise a dozen? I decided the situation radically: I transferred the entire infrastructure to Docker. Yes, it was not easy, we spent a lot of time and effort, but a lot of it was saved in the future. We selected the optimal project configurations and each provided detailed instructions on how to deploy and raise.

As a result, all of our 15 internal services were deployed in 20-30 minutes. That is, newcomers painlessly skipped one of the stages of adaptation in a new place. Many were even surprised when recalling their past experience. That was the best praise for me. By the way, I know many companies in which newcomers were thrown alone with the project, and they had to spend a whole week raising them!

About documentation

Probably, like everyone else, at the beginning of the project we had no documentation at all. And while the team was small, and the service was modest in functionality, there were no problems. But after two years, when switching to other parts of the project, the developers themselves did not understand how those pieces of the service that they had not touched for a long time worked. It was even more difficult to tell new employees about the project. Especially when it consists of 15 services that work in different ways and on different technologies.

At the first stage of solving the problem, training videos were recorded for all employees of all departments. Programmers were allowed to watch everything so that they understood how the work of services was arranged from the point of view of the user. This greatly saved time, it was not necessary to talk for a long time, 10 minutes were enough to answer questions after viewing.

Then we prepared the documentation in two versions: for beginners and extended for everyone else. The first one was essentially a simple cheat sheet for the initial stage of introducing a person into the team, where newcomers could find all the most important things. And the second, extended version, everyone has already used. Everything was described there: from architecture and instructions for deploying projects to the subtle technical nuances of using certain technologies. Later, they created another large document that described the interaction of all components of our common system.

We can say that at first there was no search on the large dock, it was extremely inconvenient to use, so everything was transferred to the Wiki engine. With proper organization, and this was also not possible on the first try, everything turned out to be very convenient and affordable. Later we added additional documents for different departments. And then our documentation became a complete knowledge base. For example, you need to configure replication on some of the services, you find the necessary article with instructions and examples.

Each employee could add and edit documents, there were responsible people who monitored the relevance of the information, but almost everyone was involved in the process in one way or another. It is important to note a key point here - knowledge should not be locked on one person, this is the way to nowhere. He can get sick or quit, then in his absence an information collapse can happen.

I already left that company a long time ago, but the base is alive, employees are constantly using it.

About comfort

Once I myself came to a new job as an ordinary programmer, I was pleased when they tried to create comfortable conditions and explained everything. But it was when they just planted them in the workplace and left them alone with the project. It terribly enraged. But management did not see this as a problem.

Remembering my experience, I always try to listen to people and create comfortable conditions. For example, it was such that a person lacked good noise-canceling headphones or a chair with back support. In my practice, there was even a story when a programmer came to PHP, but at heart he wanted to do JS. I was just reforming the department, and the person had excellent motivation and burning eyes. As a result, I transferred it to a different position, everyone was satisfied.

The guys who came to my department really appreciated this attitude. They said that everything was very complicated with us, but thanks to such a smooth introduction to the course of work and the help of other employees, they quickly mastered the team.

I believe that a lot of good communication and a friendly atmosphere in the team helps a lot. Team Leader should live with the team, CTO with TL and processes, probably only then there will be an idyll.

Project test drive

There are such unfortunate cases when a new person is taken into the company, but in the process of work it turns out that either he is not suitable for the project, or the project does not suit him for some reason. Of course, the situation is not ordinary, but sometimes it happens.

To minimize the risks for both parties, I introduced a practice such as a test day. We used this approach when there were doubts. That is, a specialist could work a day to try a new project for him, to see how everything works. In turn, even in such a short time, we could comprehensively evaluate it.

An engineer can have many reasons why he does not like the project. For example, he may not want to work with Legacy, he may not like the development approaches, and finally, the atmosphere in the team may not suit him. And it happens that a person does not have enough of these reasons to leave after a trial period. He remains, but feels discomfort or discontent.

To exclude such situations, we spent test days. People just took time off and came to us to try to work. In this case, there was even less time to get acquainted with the project, so we introduced them to the course of things on an accelerated program. This paid off: in case of doubt after the interview, we, together with the candidate, made the right decision. Thus, he did not risk losing his existing job and getting into a project that he did not like, and we saved a lot of resources if the person did not eventually become a member of the team. By the way, a similar approach is used by some other companies.

conclusions

In different companies, workflows are very different, also everywhere has its own specificity and architecture. Therefore, even tough professionals need time to adapt. Your task is to make it the most effective and reduce it in time as much as possible. Therefore, it is worthwhile to devote time to debugging such a process as entering a new employee into a team. If you have not taken steps in this direction, then try to do it as soon as possible. This will save you a lot of time in the future. And no matter how many people work in the company, 10 or 1000. It is also important to understand that if there is no one to do this, the responsibility still lies with the team leader.

My team managed to reduce input time to three days! After such a short time, a person joined the team and took on current tasks. There is no universal recipe, in each situation your plan will work. But in my opinion, the key aspects are careful preparation for the recruitment of new employees (documentation, setting up the environment, hardware), creating comfortable conditions, competent acquaintance with the project and support from colleagues and, of course, the team leader.

PS What if you have interesting, funny or instructive stories about how you were introduced to the team? Burn in the comments! :)

My other IT management articles:

What is it like to be a Team Leader
Dream team from nothing: hiring IT professionals
How to create and manage successful teams
Grow, Team Leader, big and small