Smoothing out the onboarding process

There is a new member of the team, hooray! We will develop all the features we had in the backlog, for sure! Just give her a computer, a brief introduction to the code and she will be able to produce code on the first day, easy peasy right?

Oldschool onboarding

Don't be surprised, the short story I've just written sounds familiar to you, hasn't it? If not, let me say that not so long ago the onboarding process of "a new member of the team" was like that.

Imagine the situation on her first day:

• You are nervous, anxious to start but nervous.
• Will I worth it? I have to demonstrate all I know. I have to impress my colleagues! Will they welcome me? Or I'll be a threat? Those are the kind of thoughts traveling quickly through your mind, and they won't stop!
• Presentation time, you have to remember all the names of your new 10 teammates! Plus the bosses! Oh and don't forget that guy sitting right there "who knows everything" and you have to ask if something goes wrong.
• You are still nervous but you chill down when they give you the computer, your brand new computer! And it's new! (in old times, most of the computers given to the newcomers were inherited from the old mates, believe me).
• Ok, you are more relaxed now, you are in your comfort zone configuring your development environment, but your love story ends quickly just at the moment you need access to some internal tools. Ask that mate you briefly talked earlier (the only one who smiled at you) but unfortunately, he configured this too long ago and doesn't remember how to do it, let's go ask "that guy who knows everything", remember? Looks like he's busy with this very important feature that we have to deploy this morning, and can't help us, try asking that "another guy who almost knows everything"... If you are lucky, at the end of the morning you have the code cloned in your computer and you are ready to start coding.
• What? This is the code? What do you have here, the whole Internet? I will never understand a line of it, I'm a fraud, they are going to ask me to not come tomorrow... At this point, you panic. A lot.
• Take a deep breath, you are saved by a teammate who will explain (briefly) to you the code in order to make you something productive "as soon as possible". Oh, thanks... You think.
• Time to go home, you and your exhausted brain need to rest, tomorrow will be a tough day, they say... And you only want to rest to be ready. You have to impress them, remember?

If I've done it well enough, you should be able to fill a small fraction of how stressful the first day at work of a person can be. Back in those days, it was the norm, we accepted it because it was like this, this process was painful and necessary. But, what if not?

Current onboarding

Recently, a new member has joined the team and we wanted to make her incorporation as pleasant as possible. So, based on our experience, we have collected these learnings.

To try to make things easier for all of us (for the new member and for the team), we calendarized all the onboarding events for the first week. In that way, the team can plan at least the first week and act accordingly.

Even though we want to have it all planned, it is important not to saturate the first week with a lot of events, so we followed these simple rules which worked pretty well for us:

1. An event has to be 45 minutes long maximum. Investing more time will downgrade the attention and the event would cover more topics than intended.
2. Do not plan more than 3 events per day. Think that the new teammate will have 100% of her attention on you, that's exhausting.
3. Change the topic of the events, even when the events are split, processing the info takes time, and is better to do it after some time, for example, the day after.
4. Make the other person feel comfortable, do not start covering the complex topics at the beginning, take 5 minutes to ask how it is going, and let her know that there is a lot to process and we know it's hard, do not rush.

To separate concepts, we have divided the onboarding process into two different types of events:

• Soft (or product), will cover all topics related to who we are, what we do and why, how we earn money, it is a good time to introduce some concepts of our domain, our ecosystem, etc...
• Hard (or technical), will introduce the existing code to the new colleague, how we developed it and why, the agreements of our team and, most importantly, we will ask her point of view because we want to improve as a team.

Let's dive into the onboarding process itself, with concrete examples of how we did it. To make it clearer, we thought that organizing the events chronologically would help you to map them in your mind and see how we organized them.

First day

First of all, she has been in touch with her Engineering Manager right from the start.

The EM is responsible for easing the first moments of the new member. For instance, he will ensure that she will have her new laptop ready (in these pandemic times, we have sent the laptop to her home days before she started to work with us), introducing her new teammates, people of interest like our General Manager, People & Comms department, etc.

After these boring (but necessary) procedures, we would like to relax and have some fun, right? So we calendarized two events on the first day:

1. Team members introduction, this meeting is intended to introduce each member of the team to our new colleague. The idea is to take just a couple of minutes and explain what is her position in the company and, in addition, something personal like a hobby, this will help to break the ice. After all members have been introduced, it's the turn of the newcomer, she would be nervous, so don't hesitate to ask her something beyond work, try to start bonding here.
2. Team duties, in this meeting we will cover what we do as a team. It helps to have prepared a team presentation, just a few slides to support your speaking. In our case, this presentation was made by our PO but the more people involved, the better.

For the first day, no more meets were scheduled from our side. She will spend the rest of the day talking with her EM and signing documents, etc. That's enough, don't you think?

Second day

The day after we wanted to do something different, something where we really show who we are, so we planned a team breakfast! (we called this meeting "Breakfast at Tiffany's" just to show the funny intention of the event). The goal is clearly to have breakfast but to add more fun, we played a game (online because these days), in our case it was a drawing game (you know, you have to guess what a teammate is drawing, the first who guesses it, the more she scores). It was entertaining, and we discovered how people think and most importantly, who draws the better. It looks like a silly game but it's deeper than you think.

After this relaxing moment, it's turn to dive into the technical part. To do this, we have a well-structured README file in the project repository which covers the following points:

• A warm welcome to the repository section with links to:
  • Platform-specific onboarding document (for instance, Android), where we cover the general agreements we have as a platform community.
  • Team-specific agreements. In addition to the community-level agreements, these ones try to cover the particularities of our project.
  • Explanation of how we work, in this section we explain a simple workflow of a ticket from the creation to the resolution, emphasizing branch handling on the version control.
• Development environment configuration guide. As you may know, all projects have their particularities to make them run, some of these particularities could be:
  • VPN configuration.
  • Add username and password in a local file to access any internal repository.
  • Recommended memory configuration.
  • Code style configuration. At platform level, we have common code style rules in order to ease the code reviews and push the fewer changes possible into the version control. Once the rules are configured in the IDE, it is capable of automatically formatting our code.
  • Troubleshooting. Because we were newcomers too and we faced the same problems our new partner will face. And if you encounter a new problem during the environment installation, document it!
• Next steps section. At this point, she knows how do we work and has the development environment configured, she can run the project... Now, what? We have created the "Next steps" section which explains how to proceed from now on. Some of the topics covered here are:
  • Training. We will cover this in more detail in the next section.
  • How to generate a pre-production release, we call it "Beta version".
  • How to release to production.
• Links of interest. Last but not least, we have collected the most useful links of the project like:
  • Firebase console.
  • The application store console.
  • Project documentation in the external repository.
  • Slack team channels.

Reading all this documentation at once could be too much, so we divided it into two sessions. What worked best for us was to combine the theoretical part with real-world examples in the code, we all know we have legacy code but I bet you have that last developed feature which is implemented as the documentation says, right? But if not, don't panic! We have another tip!

Third day (and subsequent days)

The third day already? Yes! Time to get our hands dirty, don't you think?

But wait, we want to make things as smooth as possible, so before getting the first ticket and start doing it, let's practice the theoretical things we learned yesterday. To do that, we have an internal training course that will help newcomers to consolidate the written concepts in the README file and ask useful questions about them.

The training consists of completing the proposed exercise. We recommend the exercise to be:

• Simple because this is the first time we will work together.
• Complete, it has to cover the main flows of our architecture.
• Isolated from other legacy code we could have in our application, we don't want to distract our mate from what really matters, that is the consolidation of our way to work.

To develop the exercise we give:

• A statement explaining what is required to do. This explanation must be as complete as possible, attaching the proposed designs, and some tips if necessary.
• A project structure to start from. We want to focus on the development, not on the configuration.
• The proposed solution. We recommend not to look into it during the resolution of the exercise, but it will help later to discuss our proposal and compare it with the developed solution. Also, it will be part of our documentation.

Once we give the exercise to our partner, we recommend doing it in pair programming, at least the first part because it is where she will have questions about how to start, what is really required to do, what is not... This technique will also teach you all how to work together. It's interesting to do pair programming with different members of the team, it's so beneficial for the team because it would be time to share different points of view, time to check the concepts learned about the project architecture, and most important, team-building time!

Note that it's also essential leaving her to complete the exercise on her own, I mean pair programming is a good technique but if you are not used to it, it could be a little bit overwhelming at the beginning, so giving her time to do it at her own rhythm is important.

Take time to complete the exercise, during those days we all will be busy doing product stuff, developing features, assisting meetings, etc. It's important not to stop the wheel but also to reserve time for the completion of the exercise.

Ok, days have passed and the exercise has been completed, it's time to share the results with all the team, to do that as beneficial as possible we did it like this:

• First of all, let her start explaining her solution.
• If someone on the team has a comment to do, do it. Make this "review" a conversation.
• Don't judge, all the opinions are valid and those are the early days and will take time to interiorize concepts.
• Take the opportunity to learn something new, this is the key to all this process, learn and grow as a professional and as a team!
• If something comes up, is important to note and incorporate it into the team agreements.

Next steps

Let me be crystal clear here, the onboarding does not end in just one or two weeks, it takes more time... We'd say it takes about a quarter to be autonomously productive.

After those days, do not leave her, try to incorporate some things you did during this time like pair programming, asking how it is going, etc. But also, let her make mistakes and ask for help if necessary, give her time to figure out how to solve a ticket, let her talk with the stakeholders, and make herself known by others.

Final words

Let's do a recap with the key topics we have covered on the previous points.

• Prepare in advance the new member's arrival (send if necessary any hardware she would need, create if possible her user, etc).
• Calendarize events for the first week (at least).
• Combine light/soft events with complex/brain consumer events.
• You've been there, be kind!
• Be humble as well, you will always have something to learn from.
• Product presentation is just as important as team presentation. Take care of both events.
• Don't be in a rush to give her a ticket. First, work in the team's way of work and agreements.
• Keep the repository's README or documentation updated.
• A training exercise is very recommended. It would help to establish the acquired knowledge and as a real-world example.

We hope this article will help you to smooth out your onboarding process, at least it worked really well with us and we will continue improving it.

Joining Adevinta is a pleasure! Don't you think? 😉