Remote onboarding 101 – “Whenever I reach out, I feel like I’m bothering them”

“It’s really hard to get mentorship, I don’t have the support I need.”

new remote developers

Remote or not, one of the first skills we need to teach junior developers is how to ask for help.

Junior devs often fear that reaching out will make them look bad. To help them get over this problem, their team needs to demonstrate they are eager to help.

One the other side of this, we also have to teach new devs how to google concepts, or how to debug a problem before asking for help from a senior engineer. In other words, we have to teach them the skills they need so they can begin to fix the small problems they run into, and we have to give them frameworks or guidelines that make the decision to ask for help feel obvious and like it’s “the right thing to do”.

While trying to teach new engineers how to google their problems, we also need to avoid making them feel like they are a bother if they reach out.

I feel so stupid. I never know when I should ask for help, or where.

– junior dev

Be explicit about expectations

If you want them to ask as soon as they have a question, say so. If you want them to batch questions every couple of hours, say it.

Encourage questions, and set a simple decision making framework for new developers.

“What if I’m bothering them ? I don’t want to interrupt them all the time”

junior dev

It’s common for new employees to feel like they are bothering you… while you are actively waiting for them to please open up and ask for what they need. If they aren’t asking for help nearly as much as you expect them to, and they seem to be getting stuck or taking too long on tasks, make sure you continue re-setting this expectation to ask for help, and repeat yourself until you’re bored of saying it.

If a junior developer isn’t making progress because they are scared of you, that’s a problem waiting to explode in your face. Act quickly, and ensure they never wait for hours just to ask for help that would have taken you 30 seconds to provide.

Give them a framework they can use to ask for help.

I feel stupid. I take up so much of their time. I don’t have the right experience to work on a project on my own.

– a junior dev

Why isn’t the task done? I gave them a really easy bug to fix.

a senior dev, not realizing the junior dev has been stuck for the last 6 hours because their environment isn’t loading.

It helps to give new remote developers (especially junior!) a framework for how to decide they need your/someone else’s help. A simple bullet list can be incredibly helpful to feel confident that you did all you could and you really, absolutely need help to get unstuck.

The goal is to provide the tools for debugging and fixing their own problems, while preventing them from waiting far too long to ask for help.

I have used lists similar to this one, with a bit of context around them. If you don’t have one yet, I recommend copying it or writing your own, then sharing it with the new people in your team as they onboard.

“You will run into problems. We all do. When I have an issue, I have a short mental checklist that reminds me of problem-solving steps, and if I can’t figure it out, I know I need to ask someone for a hand. It goes like this, and I encourage you to have a similar list for yourself and to send answers to the questions when you ask for help, too.

  • Did you google your problem? What did you google?
  • What do you know about the problem? What’s going wrong?
  • What have you already tried?
  • What do you think is happening?

If googling your problem and writing down the answers to these questions doesn’t help, please don’t wait any longer and ask the team to assist you.”

There’s a lot of technical details you can add, but I’ve found that this pretend rubber-ducking on Slack is a good way to get rid of google-able questions while ensuring new team members have the help they need and don’t wait for hours just to ask someone about it.

Remember to mention that Not asking for help is a much more common failure mode than asking for help, and that you will let them know if there’s any problem with their approach, so there’s no need to worry about it otherwise.

If you aren’t explicit about your expectations, you’re creating anxiety that could have been avoided with a simple, quick chat.


In three bullets, this is what helps us get individual contributors more productive, faster:

  • Giving them a framework to decide when and how to ask for help.
  • Being explicit about the fact that you need them to communicate when they need help.
  • Helping them learn the basics of debugging

Remote Onboarding 101: give new employees the power to improve your onboarding documents.

One of my favorite low-effort onboarding hacks is giving every new employee suggest/edit permissions on all onboarding docs, and asking them to improve the document as they go through it.

By lowering the barrier to contribution and giving all new hires the power and encouragement to improve the documentation they are using, you make onboarding a team activity.

Onboarding documents will get updated more often, small fixes will get shipped with each new hire, and your onboarding process will get better every time.

Why does this work?

It works for several reasons. The first and most important one is that you stop relying solely on people who know too much to tell you what’s missing, and instead you start relying on the experts of “is this document any good?” which are new employees trying to learn about your organization.

Teaching others solidifies learning: apply it to onboarding.

Another reason to encourage contributions, and why this works out to generate better onboarding processes, is that making an impact on others is an important part of onboarding and feeling like a fully fledged member of the team.

While the newest member of a team is not going to be an expert in submitting expense reports or the team’s internal culture, they are often a great reviewer and editor for pre-existing documentation, because they are seeing it for the first time, going through each step themselves, and asking their peers and manager for help when needed.

What should a new employee do when they don’t know something?

  1. Read the existing documentation
  2. Reach out to their peers and ask
  3. Verify what they learned
  4. Improve the documentation so the next person doesn’t need to ask

Following a cycle like the one above will help new employees gain more confidence in themselves and their ability to solve problems on their own.

Onboarding that encourages new team members to be curious and proactive about improvements to documentation will result in more early opportunities to reach out to colleagues for clarifying questions, get their feedback, and ask for help.

Getting comfortable asking questions and learning is part of successful onboarding, so it’s a win-win-win.

Each onboarding is an opportunity to do better.

With this small change, new employees are put in a position to have an impact on the experience of the people that will come after them, and they get to do so from day zero.

A note on implementation: depending on the size of your organization, you may be able to (and want to) get more granular with the permissions you provide. I’ve heard from organizations that ask all new engineers to “own the technical docs” for their team, and others where we simply give everyone the ability to suggest changes in Google Docs + permission to send pull requests to technology-related docs in GitHub; with everything in onboarding, local context will dictate how you do some parts of it.

Remote Onboarding 101: tell them Where, When, and How to show up.

“How do they know I started my day?”

Your new employee at 9AM, wondering if you already fired them.

Why aren’t they here yet? It’s 10AM!

You, because you assumed someone else told them how to login to Slack.

A while back a friend was about to start a job in a remote organization, and they sent me a panicked message: “It’s 10 AM, I don’t even have the credentials to login to anything… what am I supposed to do?” followed by their brain running wild, thinking that maybe their offer had been rescinded. Unfortunately, that was the first but not the last time I would hear a similar story from a new remote worker.

You went through so much trouble to find a great person to join your team. You sold them on the mission, you evaluated a lot of people, and they evaluated you. They met some of their new teammates. Everyone was excited when you extended an offer, and you were relieved when they signed. But now it’s finally their first day, and instead of excitement about meeting their new team, they are worried because of a problem that could have been prevented with a short e-mail. That’s no way to start a new relationship. You know where I’m going with this…

You can stop this from happening by setting clear expectations ahead of time.

Ensure no new employee has to wonder “Do I still have a job?” on their first day.

Be explicit, avoid panic.

Write a welcome email that they can refer to from their personal email account to get started on their first day. This isn’t the full onboarding documentation, it’s simply a set of guidelines and expectations that help them be confident as they get ready to start working together. The next few points cover what I expect to see in such an email.

Tell them when and where they are expected to “show up” on their first day.

Many remote organizations don’t have a “start time” or specific work hours that they expect employees to respect, so they forget that new people may need clear guidelines. A new employee being told “you can set your own hours” may be happy to hear that in the interview, but the first day shouldn’t allow for that much uncertainty. They don’t really know you, and they don’t know what’s going on unless you tell them. Even if you really don’t have a daily schedule, make sure they have a “check in” time that’s been agreed upon ahead of time. You can do this with a calendar invite very easily.

Ensure someone will be online to welcome them to the team

Someone from their team (it can be the manager, but it doesn’t have to be) should be around to greet them, ensure they are in all the right channels and have access to every critical tool. They should be someone who can offer to answer any questions they may have and help them as they go through the initial onboarding tasks. The way I like to do this is combining the calendar invite for their “initial check-in time” with a 1:1 meeting, so their first hour or two is really about showing up for a call and getting to know each other, instead of trying to read through docs on their own.

Plan for things to fail at the worst possible time.

Let them know what to do if for any reason they cannot log-in to a critical system that they require to start their day. I’ve had situations where someone’s power went off unexpectedly, and it’s really stressful if you don’t know what’s going on.

The solution? Share a phone number that they can call if something is preventing them from coming online.

Tell them what their first day is supposed to look like

I will go over the details in another post, but I wanted to mention the importance of letting people know what to expect on their first day. If you know that X, Y, Z things will be happening, it’s good to let them know too.

Ask for their feedback

The welcome email is a good opportunity to ask for their feedback about the interview process. If you can, add it in the welcome email, and then ask again in your first 1:1. A new employee remembers details and how things made them feel. While they may not be ready to be fully transparent yet, it sets a good expectation, and some people actually share their thoughts once asked.

Welcome e-mail template

Dear $name, 
welcome to $company. We are all looking forward to working with you! 
As your first day approaches, we wanted to send a few important details about your first day to ensure everything goes as smoothly as possible.
Of course, if you have any questions about the process, or run into any problems, do not hesitate to ask.  

# Start time

While we don't have official, company-wide working hours, we recognize that the first day in any company requires more structure. I would like to invite you to join me for a 1:1 at $time on $day, where we will be going over your onboarding plan, getting to know each other, and ensuring you have access to all the critical systems and tools you will need. Please confirm your attendance in this $link, or suggest a different time if you have any conflicts. 

# In case of emergency
If you run into any problems on your first day, please email or call me at $number.

# Gear

You will be receiving your company issued laptop and a welcome package in the mail by $date. Please verify you received everything in good shape, and let me know if you run into any issues. 

# What to expect

We want to ensure you are set-up for success in your career at $company. You will be meeting with me during the first 2 hours, and after our meeting you will have a couple of hours to work on getting your environment set-up and say hi to your colleagues. At $team, we believe in build strong relationships with everyone, not just the people in our immediate group. I encourage you to set up a few 1:1s with peers in other areas to learn more about the organization (don't worry, we can arrange this during our first call). 
Our team has their weekly staff meeting at $time, please join us. You will have an invitation for this meeting in the $company calendar.
I will walk you through the plan for the week, and we will be setting up your onboarding task list together, so there's no need to worry about that yet. 

We know starting a new job can be stressful, so please do let me know if there's anything else you would like to know. 

I would love to hear about your experience interviewing at $company, so please bring your comments to our first meeting (or e-mail me). We want every new employee to have a great experience, and new employees who just went through the hiring and onboarding processes often provide creative and important fixes and feedback that the rest of us missed. 

Thank you, I hope you have a great day.  


Do the little things right.

After the candidate signs the offer and has a confirmed start date, you can use a template similar to the above, include all the relevant information, and send it via email.

You don’t want your new teammate to start their day worried because they can’t manage to log into Slack or get to their Email account… and while onboarding often takes months, even the little things we do have an impact in how people experience the process.

There is more to do before the end of their first day.

I will be covering Onboarding Checklists, Feedback, preparing for infrastructure failures, and other initial tasks in other posts. Subscribe to get more remote onboarding tips in the comfort of your inbox.

I seriously don’t have the energy to spam you, unsubscribe at any time.