Remote Onboarding to Agile Teams

A feeling of isolation, difficulty adapting to a new working environment, and a much longer learning curve is often associated with remote onboarding. However, as we learnt at the German startup scoutbee, it doesn’t always have to be like that. This report will go deep into our onboarding evolution and will shed light on how we learnt to foster the benefits and mitigate the disadvantages of remote onboarding. It will also cover how we managed to boost creativity and realize the maximum potential of newcomers. And of course, you will learn what pitfalls we faced on this path so you can hopefully avoid repeating them.

1. INTRODUCTION

For a remote team, it is even more important to stimulate self-organisation and set up a safe atmosphere at the onboarding. It’s extremely challenging, as every new member should be aware of all the necessary communication channels and their peers’ current activities. What is more, it all needs to happen without visiting each other’s desk or being able to ask “just for curiosity” questions at a lunch table. As occasional meetings are not possible, they also have to feel safe enough to build the new communication channels, set up new contacts and feel confident about the work they are doing asynchronously. It’s critical that they can represent the most important aspects of company culture by the end of their onboarding, as there’s much more independent daily work implied.

At scoutbee, we faced the typical challenges of distributed fast growing teams: we scaled from 5 to about 120 people in 2.5 years. We were working on automating supplier scouting (search) and providing convenient discovery for procurement professionals. Most of us could have been working without meeting our colleagues in person for months, till the time our next live quarterly gathering took place.

In our journey of shaping remote onboarding practices, we found out that a smooth structured flow can prevent most of the issues.

In our journey of shaping remote onboarding practices, we found out that a smooth structured flow can prevent most of the issues. Onsite we can observe the newcomer and notice when help or support is needed, while with video calls and texting it’s often impossible to do it on the go and we need to be more proactive. As an example, we do not just present the company culture and expect a newcomer to fit in. Instead, we actively guide and let them experience the key cultural aspects, tightly connected with gaining practical knowledge: we explain the concept and then provide a set of activities where they can observe and practice them. With learning by doing and by collaborating, we can ensure the critical knowledge and network are provided to a newcomer regardless of the lack of live communication.

Every company has their own path, and hopefully the practices we shaped in our unique environment can serve as an inspiration. Therefore, in this report, you’re going to read about three key stages of remote evolution at our startup: the first one about the lightning speed onboarding into a small team, the second covering the most dynamic iterations shaping our onboarding flow, and lastly, what we call Powerful Onboarding.

2. BACKGROUND

When I started helping my former colleagues with planning and coordinating their job, I couldn’t even imagine that in several months the German startup they worked for would get a contract with a leading automotive company. At that time, I was invited as a full time Scrum Master, but not only: as it always happens in startups, the roles borders are way more vague at the beginning, so certain PO and HR responsibilities eventually became a part of my work.

After this first contract, the events started to develop even faster: within about three years I transitioned from the role of Scrum Master with “extended” responsibilities to an Agile Coach. As we were scaling, my team was maturing towards the next level of self- organization taking over standard Scrum Master responsibilities. Meanwhile, I was growing into the Coach role and started to take care of other tasks such as boosting cross-team collaboration with new departments, introducing OKRs, fostering people’s personal development and, of course, making sure that product team scaling was sustainable and efficient.

Although in the first year we did have an office opened in Germany, even by the end of my third year ¾ of the development team kept working remotely.

Although in the first year we did have an office opened in Germany, even by the end of my third year ¾ of the development team kept working remotely. We represented over six countries, and about two times more cities, four time zones with a maximum four hour difference, and visited our office about once per quarter. When growing so dynamically, we managed to iteratively improve our approach and flow. It was the highest priority for us to carry the openness, transparency and enthusiasm we were guided with when onboarding our ex-colleagues and often friends at the beginning of the journey. As a typical startup team, we were eager to experiment together and reached far beyond the traditional onboarding practices.

3. ONBOARDING TO A SMALL YOUNG TEAM

When we were only 3 people the first onboarding of a new colleague to scoutbee took us about twenty minutes. It was a friend of ours and as we had worked together before we didn’t need any additional meetings for introduction and getting to know each other, and so it was enough for me to explain what the product was, what was the stage of startup development and what the next steps were, and to then get into pair coding on a real life task right away.

Already when onboarding the second new member to our development team, it was remarkably different. It happened after we got our first contract with an international industry leader. Then I realized that it was necessary for the team to prepare in advance and think well what parts are critical and in what order. It was still another of our friends and former colleagues joining, so they were already carrying the values and mindset we were aiming at, and most importantly they had worked remotely before.

Already when onboarding the second new member to our development team, it was remarkably different.

However, the routine of the team, the product and the development aspirations became much more complex although it still may have felt immature. That was the time when I came up with a general structure of the onboarding reflecting our remote setup peculiarities:

• Access to the tools for everyday use: we took care of them before the person started, and at this point we gathered a list altogether. When joining remotely, struggling with access and any kind of waiting is definitely not an option. It’d be much more stressful and uncomfortable for a newcomer as they can’t be easily “engaged” by colleagues sitting next to them at the office.
• Product overview: who are our clients (persona profile and examples from real life), what the pain we are satisfying with our product is, what stage of discovery we are in and what is about to happen next (roadmap and key events).
• Team setup: who is responsible for what, plan of getting acquainted with each of the team members and what’s distinct from an onsite onboarding, a detailed list of who to contact when and how, including the “alarm” contacts.
• Communication setup: an overview of our Slack channels with an indication of what’s important to track, which ones should have their notification muted completely or by mentions, which ones have to be active, how often to check the unmuted ones etc. Also, we asked to notify when a newcomer’s available and when not, as well as to practice the tools that are specific to online: e.g. pair coding, pair code review, workshops and hackathons for solving complex issues. As we all worked remotely before joining scoutbee, we didn’t need to deeply get into the online etiquette yet.
• Team routines: the processes we’re practicing, what we tried before and what we want to try in the future. I tried to involve the newcomers actively into our workflow and asked them for the feedback and ideas of what to try out.
• Project setup and first quick tasks: at this stage it took only a couple of days to prepare everything so a newcomer is ready for the real world tasks.
• Knowledge Base available in a couple of clicks: it has to be easy to find all the materials after several weeks of onboarding; so all these should be well sorted and updated. When remote, it’s more critical to keep it clean to reduce the number of “noise” messages, misunderstandings and waste. We also asked newcomers to update these documents if they found any non-valid data. This way, they didn’t take everything for granted and actively searched where to contribute.

Such a workflow proved to be quite efficient, so we stuck to it for several more months with minor iterations: every time a new person came, I reviewed the onboarding presentation and we reviewed the onboarding tasks with the team. We naturally started preparing for adopting a new developer earlier and earlier. We also factored in more time for the initial technical onboarding and project setup as the codebase was growing and our technical expertise was improving. However, we were still carving our onboarding process on the go, not allowing ourselves the time to proactively consider the important changes.

4. ONBOARDING TO A FAST SCALING STARTUP

At one point after 6-8 months, our scaling ran at Formula One speed and all our challenges finally made us proactively prepare our onboarding process. We started to review our onboardings in progress and elaborate on the feedback as soon as we could, often asking the newcomer to assist. We hired a second Scrum Master who first shared the onboarding responsibility with me. After a while we felt too much pressure of time and therefore began shifting the onboarding responsibility to the teams and delegating certain areas to different team members. That was the time when our key onboarding principles and practices were settled and developed, and the time when the team started owning the onboarding. Let me describe in detail.

1. First days of the newcomer

After one of the rushed first days of our newcomer, we looked back and asked ourselves: is this time going to be unforgettable? Is fighting with the project setup alone at home and getting into scrum events what we really want to have happened on the first day? Each of us, early birds of the company, had a great story that started with a message pulling us out of the routine and inviting us to work with our friends and former colleagues. We were so excited, rushing to learn from a new and risky endeavor with the people we were dreaming to work with again. That was the story that helped us to raise interest at the interview, a great story to start a conference talk as well as to update our friend about the career news at the bar. That was the story that compensated for the regular live team buildings, office massages and health insurance. Now we had people who had never met us before joining, and we had to find new ways.

From that point, we always aimed at giving a warm welcome and sharing a feel of our culture. We did our best to make all the formalities go smoothly and unnoticed and striven to let newcomers write their own exciting story. We thought of all the tiny details and prioritized the safe atmosphere. We believed that getting to know about each other’s talents and interests is more important than learning the roles. Here’s what we came up with:

1. 1. Collaboration. We always filled in the first hours of a newcomer with collaborative work. If we could start with an informal meeting, we always did so. And if we couldn’t, we let the most available teammate do so as they could concentrate on onboarding with minimal sidetracking.
   2. Education about the team routine. When you join remotely, there’s a high risk of feeling completely lost at the first team meetings. It’s difficult to figure out their true purpose, what’s intended and what’s bad about their flow, especially if a newcomer is not familiar with the practiced routine. It may happen that newcomers feel too shy to ask general questions, and with time it gets even more embarrassing to bring them up. Therefore, to boost the feeling of safety from the first days, we were explaining the meeting purpose and standard flow, or just checking if it’s clear for a newcomer. For example, we explained that we had longer standups to cover both general sync and check-ins on data exploration followed by small brainstorms. We shared the story of how it proved to work better in our remote environment. Newcomers said it was safe to give their standup update for the first time after such an explanation. They could also easily spot if there was anything new and what’s even more important, they felt comfortable asking questions.
   3. Remote communication culture. We shared key statements about our online etiquette and promised to support a person with getting used to them. Let me give some examples:

• • • Everyone should snooze notifications to get into the flow but has to attend meetings, be reachable on Slack and check/answer on Slack at least twice a day
    • We prioritize the team events when working out our schedule
    • We strive to communicate in topic threads about unknown information for the team
    • There’s a taboo of scheduling important calls without inviting the whole team and preparing the meeting notes for those who couldn’t make it
    • It’s the obligation of everyone to keep their work transparent and possible to be picked up by other team mates at any moment with minimum information loss

4. Celebration call. The first standup became the intro call where we made a warm welcome and shared our roles, interests and hobbies. We experimented with different formats in different teams. For instance, the first person tells a story about one of their teammates: what they’re impressed about, why they appreciate working together and what challenging moments become easier after they started working together. Then this person tells a story about the next teammate etc. The main criterion of such exercises was to keep a festive mood and help a person to feel safe.
5. Handshake compensation. We had a gif and warm messages greeting a newcomer in the main channel of the company: this is an important compensation for an office tour, followed by smiles and handshakes.

After the analysis of the onboarding feedback, we have come up with the following Don’ts for the first day:

1. Spending the first hours reading or setting up the devices on their own was mainly not a positive experience: a person feels lost and unsure if they’re doing what’s expected of them. That’s why we allocated people guiding a newcomer on the first day even for tasks that could be done alone. We tried to schedule the passive activities for later and balanced them with interactive activities.
2. Don’t expect that it’s easy to notice the discomfort of a newcomer or that they will bring it up. It may be very awkward to raise issues on a video call, and it’s even more challenging to be a great observer. What we did instead was regularly normalizing the awkwardness, asking for feedback and underlining there are no stupid questions: “It’s totally normal to feel awkward at your first meetings, we’ve been there. Please share if there’s anything unclear for you, especially if you don’t get the whole purpose of the activity: it’s very important for us to explain it all as soon as possible. We’re also looking for the ideas to improve it…”

2. Kick off newcomer’s initial network

Every onboarding task we set was a candidate for collaboration. When a person works remotely, especially if a part of the company is collocated, it’s crucial to level the playing field. The convenient possibility to reach out for help and the key initial network becomes a runway that will enable the newcomer to take off quickly and with little assistance. Moreover, it’s essential to educate and show the ways of connecting with other departments. Working at the office, it’s natural to give this responsibility to a newcomer, but remotely it’s simply not possible to do alone. Here are some examples of how we did this:

• We made sure there were different people supporting newcomers with their tasks and that they were aware of which aspects they were responsible for. As soon as we explained to the teams that it’s not only about having the tasks done, but also about the acquaintance and connecting a newcomer to other people, it became a general practice.
• When we conducted hackathon events and the like, newcomers were paired with different colleagues. It was important to always have the business people and stakeholders setting the stage for experiments and evaluating the results of the hackathon, both the final and intermediate ones. That’s how interaction with stakeholders became a norm from the start.
• We’ve shown that connecting to new people is normal: we let the person do it themselves (e.g. “now you can text Y, they expect you to do so”; “can you please schedule a meeting with X to do this task? I can help you, you’ll also have your first calendar event”). We also strove to involve newcomers to all the cross-department activities, even if just as observers. It felt weird at first because a newcomer is not the first person to set up new connections with other departments. However, if you support and prepare them, it may be more than just a networking opportunity. In our experience, we got a lot of unexpectedly creative and innovative behaviours as a result of such connections.

Some mistakes we made in this journey included introducing too many people at once. It may feel overwhelming and cause “artificial” tasks to introduce people. In that case it worked better to organize a conversation about some general issues like code standards, or meeting culture etc. that are interesting for the person you’re introducing. For introverted people it proved important to share why such introductions take place and why they are the ones to explain.

3. The Onboarding Plan

After several feedback sessions, we learnt that remote onboarding requires much more structure and more frequent check-ins than when face to face. That’s why we added biweekly check-in meetings, and eventually, the lightweight document that we called the Onboarding Plan became the most important onboarding artifact.

To elaborate on the content of this Plan, we invited the key onboarding responsible team members to the check-in meetings. Usually the first one was conducted in the first week and included going through the general process of onboarding, the expectations exchange from the leadership, team and newcomer, and then the plan elaboration. It proved easier to merge the cultural onboarding with some specific tasks, so the plan was pretty lightweight, clear and easy to track.

The Plan usually included the prioritised list of skills and knowledge that should be obtained as a result. We almost always appointed one, occasionally two teammates for driving or supporting the newcomer within a certain area. The list was updated every check-in meeting. We changed the tasks whenever necessary: we were very flexible about them, but not the eventual objectives of the onboarding. What we found especially important is that the cultural and networking aspects were indispensable: explaining their purpose makes it easier both to get onboarded and follow up with the newcomer performance.

Here you can find several examples (the names are made up):

*Note: we often separated the onboarding targets by area to make it easier to follow up and structure the check-in meeting. The areas included: technical, team culture, corporate culture and soft skills. We also added comments of people responsible asynchronously and every time we did a check-in.

You may notice that the examples are formatted similar to Key Results (Doerr). We also strove for flexibility in achieving the objectives: e.g. the channel in which to send or gifs topics are not defined, so newcomers choose their own convenient and comfortable way. We also explained every task: e.g. “Sending embarrassing gifs may look illogical and immature to you, but actually the goal is to help you feel safe enough if something really uncomfortable happens. As you’ll experience with gifs, the team is really open and tolerant. Moreover, it’s also fun when we gain such an experience with gifs”. We explained the reasoning behind, including psychological studies supporting these tasks when needed, and it also helped to build trust with a newcomer.

When we noticed that the best results were delivered by the newcomers who had the most challenging goals; we decided to strive for this challenge aspect. We asked the newcomer what is the most interesting direction of the development for them and together we came up with challenging objectives in those areas. We explained that we do not expect miracles, and that in case of success, it will be considered over performance and generally nice to have. It proved extremely powerful to stimulate newcomers to take the most active part in formulation of such a goal. We were more at ease when discussing them, and the calm atmosphere in the team also stimulated the more “ambitious” mood of the newcomer. Our startup newcomers founded the Community of Practice in their first months, conducted workshops for the new technologies that nobody else in the team ever tried, co- organized events within their first 3 months. In my opinion, it proves the efficiency and deepness of the onboarding, as the people were able to get out of both their own and even the team’s comfort zone within such a short period of time. In addition, it enabled the boost of self-organization.

Of course, it was not always a fairy tale and we also had unsuccessful hires. When it happened first, we were pretty reluctant to acknowledge there was no chemistry with some newcomers, blamed the remote setup, and tried to find alternative ways to fit a person into a team. Naturally, it ended with a longer time of inefficiency both for the newcomer and for the team. After analysing our mistakes, we decided to be strict about our Onboarding Plan and flexible about the ways of achieving goals and their prioritization, but never about performance. The next time when we had unsuccessful hire, we could see it much earlier and an open talk with a newcomer happened with no delays: this way, we were honest both to our team and the newcomer (McCord).

It was especially important to celebrate the achievements of the newcomer both at the check-in meetings and in the team channels and events. The acknowledgement seemed not only to stimulate the positive behaviour but also added up the safety to talk about the less successful progress. When it came to the failures, we examined why it happened and how we could support it. It also empowered the “fail fast” culture.

The last onboarding check-in usually ended with the official closure of the onboarding. There were cases where we decided to cease the collaboration with the newcomer, and in that case it was a separate procedure of the contract termination. In the successful cases, it was a summary of the achievements, failures examination and the next tasks for the personal development plan.

5. POWERFUL ONBOARDING

We learnt that in order to set truly powerful goals, it’s important to validate that every team member is aware of not only the onboarding progress, but also the newcomer’s background. The interest included what their working experience is, what the main achievements are and other conclusions from the interviews. If you don’t involve the whole team in the hiring process, it’s important to debrief about how it went and what feedback all the interviewers provided. It’s usually heavily underestimated: companies often do their best to teach newcomers the knowledge that’s already in the company, while the benefit the new experience newcomers can bring is often forgotten.

As soon as we know the boundaries we operate within and everybody is aware of the newcomer’s background, we set powerful onboarding goals that set a foundation for the Onboarding Plan objectives. It can be done asynchronously or at a workshop and the following questions can help to come up with the most comprehensive plan:

1. What do we want our newcomer to be able to do at the end of the onboarding?
2. How will we know that the onboarding is finished? What are the milestones?
3. How do we know that the person is ready for the daily tasks?
4. What is essential to know in the first days?
5. How can we enable a newcomer to feel comfortable with our daily activities?
6. How can we speed up benefiting from newcomer skills? What can they bring to the team already at the onboarding? How do we build from that in the future?

These questions definitely helped to avoid the following mistakes, especially when a team was scaling fast:

• There is no clear checklist of what should be done on the first days of onboarding. A newcomer feels lost and different representatives ask for the outcome of different activities. It puts pressure and prevents systematic onboarding.
• The team is not sure what the expectations about the newcomer’s deliveries are. Everybody has their own image and worst case it contradicts the management expectations. This can lead to the failure of onboarding and even the newcomer quitting or being fired.
• The team members do not carry the responsibility for the process and do not have any expectations about how it takes place.

6. WHAT WE LEARNT

One can guess the most important learning is that remote onboarding should be a clearly structured and transparent process. I also believe that the warm welcome, creating a safe atmosphere and helping to fit in the culture should go hand in hand with the structure. It’s crucial that the progress is tracked by the whole team with a newcomer acquainted with the onboarding process and its key events from the beginning till the end. Transparency is key, so the planning of the onboarding should be done together with the newcomer and reviewed at recurring meetings, where feedback is exchanged and improvements are brainstormed.

It worked best for us when the objectives at Onboarding Plan were clear and never ambiguous. It worked even better when we started putting challenging objectives without endangering the safety atmosphere but with benefiting from the newcomer skills and experience as soon as possible.

I strongly believe that the most efficient onboarding is done by the whole team and, as much as possible, representatives of other departments. This maximises the informal network that’s usually built organically when working from the office. Moreover, onboarding remotely has to be a more guided process than the onsite one. It’s important to set the dedicated targets to get into culture, processes and standards and follow them with the group activities, such as pair coding, shadowing, mob programming and workshops for the newcomer groups. The self-education should be followed by talks, brainstorms, practical tasks or other activities with teammates to make sure the newcomer obtains the deep knowledge and to increase collaborative intelligence.

The most exciting part about onboarding starts for me when it pays off. It’s unforgettable when the newcomer becomes a real member of the team, changing the culture and practices for the better and actively injecting their knowledge into the team. It’s even more satisfying when they onboard the next newcomer even more efficiently than they were onboarded themselves. Good luck in your journey, and I do hope you will enjoy it even more than me!

7. ACKNOWLEDGEMENTS

Of course, this story would never happen if not for the great team I was working with: Data Team with the most extreme onboarding conditions and growing pace and Application Team, people who took off our ship. I’d like to thank Yana Kachur, Alex Geibig, Ali Aliev, Yuriy Kriachko, Kyrylo Subbotin, David de Lange, Dmytro Ivaschenko for pushing us out of the limits of possible when onboarding or being onboarded. I’m also extremely grateful to my kind reviewers at SimCorp: Maryanne Kmit, Kristian Adams and finally Neil Cook, without whom this report would have never be submitted. Last, but certainly not least, a limitless gratitude to my shepherd Frank Olsen for his guidance and inspiration as I crafted this report.

REFERENCES

Doerr, J., 2018. Measure what matters. 1st ed. Penguin Publishing Group.

McCord, P., 2017. Powerful. [S. l.]: Silicon Guild.