A good remote onboarding checklist decides whether new team members feel at home after four weeks or are still wondering who they are actually allowed to ask. In the office, everyday life smooths over a lot: you sit next to someone, overhear conversations, get invited to lunch. Remotely, all of that disappears. Anyone who gets nothing but a laptop and a wiki link on day one ends up alone in front of a screen, guessing.
This topic matters to me because the first weeks set the tone for the entire working relationship. So here is a plan for the first 30 days: what should happen before the first working day, what the first week looks like, what an onboarding buddy actually does, and how you can tell after a month whether it worked. On top of that, you get the complete checklist as a printable PDF.
In short
Remote onboarding works when you plan three things at once: access to knowledge, confidence with the tools and real relationships within the team. The key insight: remotely, relationships rarely form on the side, so you have to arrange them. The biggest pitfall is a first week made up of nothing but accounts, forms and documentation.
What you will learn in this article
- What should be done before the first working day
- How to plan the first week day by day
- What an onboarding buddy does and how often you meet
- How to recognize a good first task
- Which questions belong in the 30-day conversation
Why remote onboarding needs its own checklist
Onboarding covers everything that helps a new team member settle into the company and the team: professionally, organizationally and personally. That goes beyond classic job training, where someone gets the tools explained. In the office, a large part of it happens by chance. Remotely, on the other hand, only what someone deliberately plans actually happens.
The GitLab Handbook, one of the most detailed public collections on distributed work, distinguishes three levels of remote onboarding: organizational (where do I find information?), technical (how do I use the tools?) and social (how do I build relationships?). I find this split helpful because it reveals a typical imbalance. The first two levels fit nicely into checklists and tickets, so they usually get done thoroughly. The social level feels soft and therefore tends to slip down the list.
Yet that is exactly where the feeling of belonging comes from. If, after three weeks, someone knows nobody on the team they can “just quickly” ask, they work more slowly and start doubting their decision to take the job sooner. A remote onboarding checklist therefore has to cover all three levels, right from the start.
The first 30 days at a glance: from preparation to the 30-day conversation
Remote onboarding checklist for the week before
The first working day really starts a week earlier. Everything you prepare here takes pressure off day one. Nothing drags on more than a start where your new colleague waits three hours for VPN access, wondering whether everyone forgot about her.
Hardware and access
Make sure the laptop arrives on time, with enough buffer for shipping and customs if someone lives abroad. Set up the accounts that are actually needed on day one: email, chat, calendar, video call tool, ticket system and wiki. Further access, for example to production systems, can come later. A short “Your first login” guide listing the steps in the right order also helps, because setting up multi-factor authentication and a password manager can otherwise easily eat half the morning.
People and calendar
Pick an onboarding buddy and ask whether they really have time during the first two weeks. Then pre-fill the calendar for week one: your first 1:1, the team meeting, two or three get-to-know-you sessions and plenty of free blocks for reading and setting up. A packed calendar looks caring, but for new people it is exhausting. Leave too much breathing room rather than too little.
Finally, send a short welcome message: when things start on day one, which link leads to the first call, who the buddy is and that nobody expects results on the first day. That sounds trivial. Even so, this very message removes the biggest uncertainty before the start, namely what is actually going to happen on Monday at nine.
Week 1: arriving, not delivering
The first week is about arriving. The new person should get to know the tools, be able to put names to the first faces and understand what the team is currently working on. Contributing productively is not expected yet. Say that explicitly, because many new team members put themselves under pressure to show something quickly.
Here is what a first week can look like:
| Day | Focus | In practice |
|---|---|---|
| Monday | Welcome and setup | Welcome in the team call (15 minutes), setting up access, first call with the buddy in the afternoon |
| Tuesday | The team and its work | First 1:1 with you, overview of product and architecture, joining the daily as a listener |
| Wednesday | Tools and workflows | Setting up the development environment, walking through the path from ticket to deployment once |
| Thursday | Getting to know people | Two get-to-know-you sessions, a pairing session with someone from the team |
| Friday | Looking back | Short check-in with you: what helped, what is missing, what is unclear? |
The most important meeting of the week is the buddy call at the end of day one. After eight hours full of new impressions, you need someone who asks: “How was it? What stuck, what didn’t?” The GitLab Handbook explicitly calls this first call the most important task of the buddy.
Your first 1:1 with the new person deserves its own preparation. How to structure it and which questions you can ask is covered in the guide to the first one-on-one, the first part of this series.
The get-to-know-you list
A simple tool with a big impact is a get-to-know-you list. You write down five to eight people the new team member should meet during the first month, each with one sentence explaining why. For example: “Jana, product owner – knows why the current feature is built the way it is” or “Malik, operations – helps you when a deployment gets stuck”. The new person then schedules the meetings themselves.
This has two advantages. First, conversations get a clear reason, which is easier for reserved people in particular than an open “Let me know if you need anything”. Second, the new person learns how people approach each other on your team. Give the people on the list a heads-up beforehand so they are not caught off guard.
The onboarding buddy: tasks and rhythm
An onboarding buddy is a colleague from the team who is the first point of contact for all the small questions during the first weeks. They are not a manager and they do not evaluate anything. Their job is to make sure nobody is left alone with a question they don’t dare to ask.
The GitLab Handbook describes a clear rhythm: the first call on day one, then at least two more calls in the first week and at least one more during the rest of the first month. In addition, it recommends asking the new person whether they want more or fewer meetings. I consider this point important, since some people want a short daily chat while others prefer one longer conversation per week.
Who to choose as a buddy
Among its criteria, GitLab lists: at least three months with the company, the same department, a similar time zone and availability during the first two weeks. I would add one more: the buddy should actually want to do it. Someone who only takes on the role because nobody else is around will quickly start cancelling meetings. Also plan a backup in case the buddy gets sick or goes on vacation.
The time spent in the buddy role is real work. Expect a few hours during the first weeks and plan them into the sprint instead of expecting them to happen on the side. Otherwise, the buddy has to choose between their own tasks and the new colleague, and usually both lose.
Week 2: the first real task
In the second week, things can get concrete. The first task of their own is an important moment, because it shows that the new person is really needed. At the same time, it tests your processes: how long does it take for a small change to go live? Where does it get stuck?
A good first task is small enough to finish in two or three days, yet still covers the whole path from ticket through review to deployment. For example, a small improvement to an error message, a missing test or a gap in the documentation noticed during onboarding itself. Unsuitable, on the other hand, are tasks that require diving deep into unfamiliar code, or urgent tasks that create time pressure.
Plan at least one pairing session in which someone from the team works on the task together with the new person. Remotely, this replaces looking over someone’s shoulder. It is also worth explicitly inviting the new person to fix documentation whenever they run into gaps. New people spot gaps that everyone else stopped noticing long ago.
Weeks 3 and 4: responsibility grows
From the third week on, onboarding gradually turns into regular teamwork. The new person joins all rituals, picks up tickets from the regular backlog and no longer just listens in the daily. Which rituals hold a remote team together is something I describe in detail in the article Leading remote teams: rituals that actually work.
During this phase, pay particular attention to quiet signals. Is the person asking fewer questions than at the beginning because they have understood everything, or because they no longer dare to? Remotely, you won’t see it in their face at the coffee machine. So ask directly in the 1:1 whether there are things that are still unclear but now “feel weird to ask”. This phrasing opens a door surprisingly often.
The 30-day conversation
After one month, a dedicated conversation that goes beyond the regular 1:1 is worth it. It has two goals: finding out how the new person is doing, and learning how to improve your onboarding. These questions work well as a framework:
- What helped you most during the first weeks?
- When did you first feel like part of the team?
- What surprised you, positively or negatively?
- Which question haven’t you dared to ask so far?
- What should we do differently in the next onboarding?
- What do you need from me over the next 60 days?
The answers to the second-to-last question are pure gold. Write them down and adjust your remote onboarding checklist accordingly. That way, onboarding gets a little better with every new team member.
Common mistakes in remote onboarding
The most common mistake is a first week made up of nothing but forms, mandatory training and documentation. All of that is necessary, but if nobody has asked the new person how they are doing by Friday, one feeling sticks above all: here, I am just a case file.
A second classic is “Let me know if you need anything”. It is meant kindly. In practice, though, it puts all the responsibility on the person who knows least about what they need and whom they can ask. Scheduled meetings and the get-to-know-you list solve this better.
Third: too much at once. Anyone who gets twelve intro calls, three training sessions and the complete architecture explained in the first week retains very little of it. Spread the content across the month and allow time to process what was heard.
And finally: no wrap-up. If onboarding simply fizzles out, you miss the moment when you look back together. The 30-day conversation closes this gap and at the same time gives you the feedback you need for the next onboarding.
My take
I consider onboarding one of the most underrated leadership tasks of all. A lot of energy goes into selecting new people, into job ads and interviews. Once the signature is in, however, things often go quiet, and the first working day becomes a task for the IT department.
Yet you will never again get as much honest feedback about your team as during a new member’s first weeks. New people see what has long become normal for everyone else: unclear processes, outdated documentation, unwritten rules. Make use of that instead of smoothing it over.
I want to push back on the idea that remote onboarding is inherently worse than onboarding in the office. It is different and requires more planning. In return, it forces you to write down things that otherwise only live in people’s heads. In the end, the whole team benefits, not just the new colleague.
FAQ
How long does remote onboarding take?
For actually settling in, 30 days is a good frame. Until someone works truly independently within the team, it takes considerably longer depending on the role. So keep regular 1:1s going after the first month as well.
What belongs in a remote onboarding checklist?
At a minimum: hardware and access before day one, a pre-planned calendar for week one, an onboarding buddy, a get-to-know-you list, a small first task with pairing and a wrap-up conversation after 30 days.
How often should an onboarding buddy check in?
A proven rhythm: one call on day one, two more in the first week and at least one more until the end of the month. Ask the new person whether this pace suits them.
Who is responsible for onboarding?
The manager is responsible and plans the framework. The buddy, the team and the new person shape it together. Organizational matters such as hardware and accounts can be handled by IT or HR.
Your next step
Take the checklist and go through it for the next person who joins your team. If nobody is starting right now, ask the team member who joined most recently: what would have helped you during your first 30 days? The answers will show you very precisely where your onboarding has gaps today.
I’m curious how you handle it: what was the best thing that happened to you in a remote onboarding? Feel free to share it in the comments.
Continue the series: Back to the “Leadership in brief” overview · Previous part: Leading remote teams with rituals that work. Next part: Offboarding: when someone leaves the team.
📄 Printable cheat sheet – The complete 30-day remote onboarding checklist to tick off – with buddy rhythm and questions for the 30-day conversation. Download PDF · View online
Sources
- GitLab Handbook: GitLab Onboarding Buddies
- GitLab Handbook: The complete guide to remote onboarding for new hires
This post was created with AI assistance.
👉 Next step: Preparing a first one-on-one? My question cheat sheet puts the best questions on one printable page.
Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en
Top comments (0)