How we implemented the onboarding of new developers

Hi, Habr!
My name is Ekaterina, I am a team leader of the Moilling-billing service team.

About two and a half years ago, the My Warehouse development team consisted of 20 people. During this time we have grown three times, only since the beginning of 2019 we have three new teams. Against the background of rapid growth, we had to change the “timlid learning model and tell everything personally” to a more scalable one.

If you also encountered such a problem and want to find out how we solved it, welcome under kat!

As it was before

When I came to MoiSklad two and a half years ago, my training was warm and tube, but not very productive. Timlid rolled up in my chair to my table and told me how to set up the working environment, what components are in the project, how they interact, how it works on the market, it is being tested and developed.

When a new developer appears in the team every six months, this approach works well - the new employee communicates a lot with the team leader and senior developers and quickly gets to know the team. But it took a lot of time for the tmlide and the senior developers to get into the work of a newbie, although in reality they told each one the same thing.

At some point, newcomers began to come not one at a time in half a year, but two or three people a month. Time for onboarding began to go longer, and as a result we wrote the first article for beginners - told how to set up a working environment. Prior to this article, it took up to three days to deploy a dev-environment and get acquainted with the project, now it’s enough for two hours.

0 day in the company

Even before the release of a new employee to work, we solve several important issues:

Team. As a rule, we try to decide before the interview which team will work in which person. If one of the team leaders liked the candidate, he will be interviewing and examining the person with an eye to his team. Of course, we take into account the needs of teams, abilities, wishes of a new employee - someone is more interested in the backend, someone loves the UI.

Workplace. A new employee should see the laptop and everything necessary for work on his desk right away. He should not wander through admins and knock out equipment through tickets and papers. In My Store, on the day of going to work, a workplace with a laptop, monitor and mouse, a company notebook with a pen and a cool cup has already been prepared for a beginner. So an employee can immediately begin setting up the work environment.

Access to corporate resources. Immediately we provide access to mail, Slak, Gitlab, Confluence and others.

Go to the side of My Warehouse - we have cool mugs and snacks

1 day in the company

The purpose of the first working day is to get acquainted with the organizational structure of the company and get answers to organizational questions. Most of the necessary information is stored in Confluence. By the end of the day, the new employee should have a customized work environment and begin to get acquainted with the structure of the project.

In practice, we do this. At the beginning of the day, Euchar sends an article to the new employee with useful information: how to correctly fill out the profile in Slack; to whom to run, if your monitor broke, your notebook ran out, you were lost, confused and you do not know what to do. Spoiler: to the team leader and the same Euchar.

Additionally, we provide links to articles with common organizational things. We recommend that you read them on the first day and contact them as you work in the company.
This is what the structure of information looks like with which we introduce the new developer on the first day. You can use this structure if you want to create similar documentation for your company or team.

New employee:

• Basic tools for work. We give links to corporate mail, Slak, calendars, Dzhiru.
• The rules for filling the profile in Slak.
• Rules for filling the signature in the mail (optional).
• Organizational company and office seating plan. So that the newcomer is always aware of who, on what issues and in which direction to run.

Are common:

• Salary. Schedule of accrual, the rules of division into salary and advance.
• Sick. How to pay and how to deal with sick leave.
• Vacation All necessary instructions and sample application.
• Compensation training. How, how much and to whom to go if you suddenly wanted to attend a conference or a course.
• LCA. When, how, what is available, whom to ask.
• Other buns. Here about the work schedule, the ability to work remotely, the compensation of meals and in general about everything that you still want to tell the new employee.

All orgstati maximum compressed and structured. In them, we collected only the most necessary things that are required for an adequate life in the office. More or less attentive reading takes about an hour.

By this time, the novice is already oriented in the office and understands who to go with this or that problem. If the cookies run out, he will not look for them from the admins.

Then the team leader gives the new employee instructions:

Common to all teams to customize the workplace. It says how to unload the project, download the necessary components and who can help run the project locally on the laptop and check its operation. These steps are followed by links to repositories.

Separate for a specific team. It contains specific requirements for working on tickets, reviewing and transferring tickets for testing. For example, we have custom statuses and ticket types in Djir. They can even embarrass a person who had previously worked with Jira. Therefore, we have collected in one place the requirements that must meet all the tickets created in the bugtracker.

I have these actions in the form of a small checklist:

The links contain articles describing things specific to our company or specific team.

Acquiring technical articles and launching an application locally takes an average of three to four hours. As a result, the novice has a fully configured dev environment and is ready to start developing the first ticket. But before that, at the end of the day, I organize a small rally with a new employee: I pronounce the main directions of the team’s work in a voice, answering questions about the material studied during the day.

1 week in the company

In the first week in the company, a new developer gets acquainted with the main functionality of the application and makes the first tickets.

To get acquainted with the functionality of the project, I have a separate small checklist:

With it, the developer begins to understand the main points of the application, the location in the code of the main entry points, can be guided in the code independently.

Then the novice is issued in the development of his first ticket. Tickets for new developers I select in advance and form a small list in Confluence. This is important, and here's why.

In each ticket, I check that all descriptions were clear. There should be no product specific definitions; if they are, they should be accompanied by references to the documentation. The formed list of tickets allows a new developer to take on tasks on his own without asking colleagues - all tasks in this list are ready to work. And most importantly - as soon as you see the development plan for the tasks for the next month.

In the process of working on a ticket, a new developer can check with previously received articles, transfer a ticket to review and testing. With this approach, already in the first week the finished task falls on the prod, and the developer receives feedback from the decision made by him.

1 month in the company and further

If it seemed to you that our system with check-lists and tickets throws people into a single voyage, this is not so. From the first day, the team leader looks after the newcomer, prompts for the components of the product, shares articles from the knowledge base that will help solve the problem.

If the developer pulls, in the first month we can already entrust a major architectural task.

During the trial period, we hold several in-person meetings: at the end of the first week of work, at the end of the first month and at the end of the trial. On them, we exchange feedback, share plans for tasks and correct what could go wrong. And often we simply say: “Great, we’re working further!”

results

With the help of product and company documentation, checklists for onboarding and instructions for setting up the working environment, we have greatly reduced the period of time that passes before the development of the first ticket. Now the release of the first small ticket occurs already in the first days of work, and before the introduction of onboarding it took about two weeks.

The introduction of interim meetings during the trial period also helped a lot. Now we correct the problems immediately, rather than waiting for the end of the probationary period. It became easier for us to sum up the intermediate and final results, and for beginners to join the work.

The Timlides began to spend less time verbally telling about basic things - we fixed them in articles. Now you just need to keep an eye on the newbies to use the information correctly. We also managed to scale up hiring - the development team increased three-fold in two and a half years.