Get best of the week

Onboarding on a remote site

There are several types of onboarding: at the company level, when everyone shows and tells a beginner about its activities, features, structure; at the HR level, which can still emphasize the impression of work; and at the team level. We’ll talk about the latter, especially about how the requirements for onboarding changed during remote work.

Work before udalenka and after.
Work before udalenka and after.

What are the options for onboarding?

  • They threw it into the water, swam out - our man could not - it was his own fault, it was better to try and learn to swim in advance;
  • This is the task, here you will understand the rest of the campaign;
  • Real onboarding. In the first cases, it really was not. Newcomers are engaged and carefully immersed in the device companies and teams.

I will make a reservation, in this article I did not focus on the separation of onboarding of a senior or a junior. These processes have a focus on technical details and job control, but are equally important.

Social aspect


A developer is a social creature and most likely an introvert. An experienced developer may have good communication skills or even be an extrovert. But still it’s better to push him a little to communicate.

Meeting the team


Introduce a new colleague to the team, spend more time on the informal part, talking about a hobby or other interesting facts about a beginner . If a person is closed and not ready to share his interests, touch on highlights from a past job. Most likely, he already told you as a leader about them at the interview. This is important, in everyday life in the office, a novice could well tell this to his colleagues during breaks or at lunch, while working remotely it is more difficult to do.

No matter how big your company is, show the project a newbie will work with. Focus on who is doing what tasks right now. If the project is large, and you suggest the beginner to look and ask questions himself, he may go away to study irrelevant sections or just dig in. Not to mention the fact that if you have microservices, several mobile applications and a website, a beginner simply will not be able to properly prioritize.

We would like to optimally use the time and we create long instructions that answer a bunch of questions. So maybe you can send the newbie “Read The Fancy Manual”? Now that everyone has a shortage of social contacts, it is better to spend a little more time on live communication .

Arrange a meeting with a business. When you sit in the office and the product runs in a panic, they say, the photo gallery does not work, the beginner will immediately understand that this is an important / key part of the project. Without seeing the burning forest near you, you can forget that it burns. Let the business designate, and then recall, what exactly is important for the development of the project.

On a remote site, employees work more productively, since no one distracts them. Forced remote work while we put out of brackets. But this process is stable and good, as long as the developer has all the necessary data. If there is no data, you need to get it somewhere. And here a beginner can lose a lot of time searching for them, because he does not immediately find out who they can be asked for. And the exchange of knowledge, who to ask and where to look for, is a significant scope for optimizing the work of a beginner .

Gradually, a new employee will meet all colleagues. And “gradually” is the key word here. It would be great to have a list in confluence indicating who and in which case you can contact. But you should not dump a list of 20 names to a new employee with a brief explanation of who and why he needs, and hope that this is enough.

image


I recommend buddy's approach , described well in a Lamoda report . Buddy is a dedicated team member who will answer all questions about immersion in the company. The partner will tell you whom to contact on a particular issue - not in which department, but to whom specifically. Will tell if there is a similar functionality or microservice. It will help to deal with the company's adopted style of communication and behavior.
When working with the product, a bunch of pop-ups and moments unexpected for a beginner arise, he can immediately ask a question and understand what it was and why it was done. Even if the mentor does not know, his experience in the company should be enough to know who to ask.

In a remote place you can’t pass by and ask how are you. This is the moment a colleague should take upon himself. Constant communication with him compensates for this problem. If this person does not exist, his role is usually assigned to the leader, who is no less busy at remote work and he does not have time to react promptly. Choosing such “buddy” you need to take into account the communication skills and the desire of the person himself - someone wants to calmly code, and you should not blame him.

Get away from general to specific questions . To the standard question “are there any problems?” you most likely will not get a clear answer. It is worth asking whether a person coped with a specific task, whether everything is clear to him there. In this case, the likelihood of quality feedback is higher, he can remember (and does not hesitate to say) that he had a question on this topic.

Technical aspect


Have a technical briefing on the project. Break it into several meetings. During the first, tell the general points. On the second - about interaction with other departments. At the third meeting, introduce the infrastructure. Check the documentation again , update it after the employee, when there are defects. When, not if! Pick up tasks that do not require remote approval in advance. Ideally, try to sketch this task yourself and check the relevance of the description.

Talking about a project, you introduce many terms that mean nothing to a beginner. For example, “Katney Gosu in the Republic of Kazakhstan”. When introducing new terms, give a beginner an explanationand dose such information. If you tell the whole infrastructure of the service in one meeting, the beginner will most likely forget almost all the concepts that he has not encountered in the next couple of days.

Try to give paired tasks the first time . Even if one person can do the task, it is better to divide it into sub-tasks so that there is cooperation. Take microservice, for example. Let's say a beginner makes a layer of communication with DB, and a more experienced colleague has a common framework and communication by API. Next, the novice will write business logic, and the task will go into testing as a complete microservice.

Such tasks help to quickly build into the rhythm of the team, as a colleague sitting on the other end of Skype (Zoom, Hangout) in case of problems prompts and allows the newcomer to feel that he is not alone. It also protects the new employee from unnecessary alteration of half the code base, if he suddenly: 1) misunderstands the task, 2) wanted to show his ambitions and killed 48 hours without sleep.

Udalenka implies an increased sense of uncertainty. A plan helps to deal with it qualitatively. Not a motto, everything goes according to plan, but a formulated plan for immersing an employee in project details. And also an employee development plan. And of course, clearly described employee goals on a trial period and expectations from a newbie. They should not be tied to sprint tasks, but to common points that are important for the company at any stage of development. For instance:

  • Get access from (name of the person in charge);
  • Expand the task branch on the test environment;
  • Conduct 5 review tasks of colleagues;
  • Check out the dev-ops layout requirements;
  • Take the first feedback meeting.

The last example is important, here a meeting is fixed for receiving feedback, which I have already said a lot in the social part. Your list will differ depending on the priority of the team and the qualifications of the employee. You can directly separately highlight the common part and the additional ones for junior, middle and front / back.

Having a formalized to-do list and requirements for a trial period will save you and your new colleague’s nerves. It will allow the employee to show himself from different sides in a fairly short period of time, equal to the test, and plunge into different areas of your work. If you do not do this and give a beginner, for example, peacefully sawing one module, in 3 months he will ideally do it, but it may turn out to be ineffective in many other moments.

How to understand that onboarding was successful on a remote site?


A person should not have the impression of a team as a set of pixels on the screen. There must be an understanding of what is happening around the team. Understanding the project should be tied to specific features that were made by living people with whom he managed to work and communicate.

We have taken meetings with the feedback from other team members, where they share with the leader the experience of interacting with the newcomer and general impressions. For the productivity of such meetings, more than half of the employees should already have experience communicating with a new colleague. If they claim that “the work worked, it didn’t bother me”, then the onboarding process should be finalized.

More articles:


All Articles