Hello everyone, my name is Stepan Fomenko and I am a Miro developer on a team that maintains databases and migrates master data from Redis to Postgres. In this article, I’ll show you how we have changed the onboarding process in development teams in the face of a sharp increase in the number of engineers.
Onboarding is the process of onboarding new employees in a company and a team. It is necessary for the new person to join the work as quickly and comfortably as possible (comfortable both for himself and the team).
The onboarding process at Miro has changed radically over the past year. We are growing rapidly and the previous approach, which worked when hiring several people a month in one office, proved ineffective when hiring a dozen people a month in distributed teams around the world. The transformation of the process was not easy, in places painful, and along the way we discovered a lot of new things – perhaps this experience will be useful for you as well.
Important: this article describes the onboarding process in our backend team for middle and senior engineers. We do not yet have novice engineers, for them the process would look different. Also, the process may differ slightly within the company from team to team.
As it was before
A year ago, the process looked like this: several experienced developers personally told the newcomer the main topics about the structure of our architecture, and further questions were resolved in a corporate chat.
For all the warmth and lamp-like nature of this approach, there are two reasons that did not allow us to apply it as the team grew:
The complexity of the system is constantly increasing, it is necessary to involve more and more technical experts to tell the newbie about important changes;
With the active recruitment and increase in the number of distributed teams, experienced developers find themselves overwhelmed by onboarding meetings.
How it works now
We changed the process quite a lot: we abandoned face-to-face meetings with experts, created a large knowledge base from articles and videos on processes, architecture and internal structure of the product, launched the role of an onboarding mentor and developed a detailed weekly plan for the entire adaptation period. Now onboarding with us lasts about 2.5 months.
An onboarding plan is a detailed checklist of what a beginner will do for each of the onboarding weeks. It is based on a template in Confluence, which includes all the information required for beginners about the company and development directions. Teams only supplement the template with their specifics.
An important part of onboarding is the beginner’s full participation in the team’s work from day one, being present at all team meetings, and completing team tasks. We try to increase the level of complexity of tasks during the adaptation period gradually, that is, at first we give quite simple ones and gradually bring them to tasks of ordinary complexity, which the team solves.
Also, during onboarding, a beginner chooses a topic in the documentation, which is currently poorly covered, and by the end of onboarding he writes an article, filling this gap. This is the scout rule for documentation.
An onboarding mentor is usually a developer from the team where the newbie comes. His task is to make the beginning of the work of a new person in a team as comfortable as possible, to answer questions and help him in every way. Each newbie has a regular 1-1 mentor once or twice a week, but there may be additional meetings.
A 1-1 mentor meeting is time allocated for questions, discussion, and feedback. We usually discuss how comfortable the newbie is to work, whether he has any wishes, suggestions, questions about the material covered, etc. Also, at such meetings, the mentor highlights important points that the beginner has already managed to get acquainted with from the documentation or video, but which need to be further emphasized.
Challenges we faced in transforming the onboarding process
Little documentation. When we started implementing new onboarding, it turned out that we had very little documentation. I think many have come across this. The situation is much better now, but we are still working in this direction.
Too much information. There has been a lot of feedback from newbies that the first weeks of adaptation are too stressful due to the fact that they are overwhelmed with new information. We redesigned the template several times to even out the workload across weeks.
English. When we got the first English-speaking engineers, English became the official internal language of the company. All the materials that were in Russian, we needed to translate in a short time. The translation process is proceeding rather slowly and is not yet complete. However, in order not to aggravate the situation, we agreed that all new documentation is written immediately in English.
Long-term implementation of a new process. The development of onboarding and the training of the teams took more than six months. Even now, when the process is implemented, new mentors appear in the company – they need to be brought up to date, so the training does not stop. People team regularly conducts trainings and tells teams how to properly conduct onboarding.
Constant work on the template. The onboarding template, which provides general information for newbies, has gone through more than ten iterations to meet the needs of different teams. And work on it continues – we regularly receive new suggestions to improve the template from teams.
A few tips that can be helpful regardless of your hiring volume.
Video from experts. Record video stories with experts in onboarding sessions. It works especially simply now, in the format of remote work: I turned on recording in Zoom and the video is ready. This is a quick solution for starting the process of accumulating knowledge in a company.
Invest in the documentation. At least for the stable parts of the system that rarely change. This will greatly help new employees to understand the technical aspects of the system on their own, without involving technical experts. It is advisable to do this immediately in English if there is a minimal chance that English-speaking employees will ever work in your company + this is an additional useful English practice for engineers, since most of the external technical documentation is written in English.
Feedback. Ask newcomers how you can improve technical solutions, products, processes. New people with fresh eyes see and can fix what you might not have noticed. Many positive improvements in our company were launched just through this kind of feedback.
By implementing a new onboarding process, we have gained the following benefits:
An onboarding plan has appeared, where topics are ranked in order of study priority and are evenly distributed over the entire period of employee adaptation;
Guaranteed coverage of important topics with video and documentation;
The ability to quickly adapt the general onboarding plan to the specifics of the team;
Transparent expectations from a beginner during onboarding;
Offloading the burden of subject matter experts.
All this together gave us the opportunity to effectively scale onboarding with a large hiring.
If we talk about plans for the future, the main challenge is the need to translate a large amount of documentation into English. This will make it accessible to English-speaking colleagues.
There are also plans to experiment with LMS solutions and make onboarding more interactive by adding different mechanics for self-testing after learning the materials.
That’s all, if you have any questions – write in the comments. I will try to answer them. It will also be great if you share your thoughts on what exactly you would like to see in the ideal onboarding process. Perhaps this will help us improve our process as well.