Welcome! We are helping each other build remote careers. Are you looking to build one?
  1. 3

Hey Everyone, I have had a few new people joining my company. It is the first time I am onboarding new people. I think it would have been easier if we were just in the same place as there are a lot of visual cues that would have understood implicitly. How do you do this while each person is in a different location? This sounds really tricky and tough. Any tips/guidelines/best practices? Thanks!


  1.  


  2. 2

    Great question Sarah! We have an entire section dedicated to onboarding new remote hires in our guide.

    To summarise, the key points are -

    1. Share as much as possible about the company, culture as well as what work’s to be done in the initial week before the person actually joins.

    2. It is helpful to assign a mentor (go-to person for any query) for the initial weeks and regularly check-in on how things are with the new hire.

    3. You should surely introduce the new hire to the wider team on the first day. There are some fun Slack apps like Donut, Icebreakers that help you do this.

    4. Finally, it is great if you can fly in the person to the mentor’s location and have him/ her work from there for 1-2 weeks (Doist does this). However, this might not be possible during the COVID period.

    1. 2

      Woah, that’s neat. Thanks for the link to guide and also summarising the points here. Let me try to adapt these suggestions to my context and share how things shape up in a few weeks!

    2. 2

      Hi Sarah,

      I’m Boris, co-founder of RemoteMore. We are 12 fully remote people in our company.

      Some of the key things to keep in mind about remote onboarding:

      • Keep in mind: splitting the work into pieces is very important in remote setting, and a bit different in remote setting. Because communication is a friction in remote, and work hours are not as measurable, you have to split and define the tasks. Therefore, you should need a bit less integration between the people compared to on-site roles.

      • We do a social meeting with the team - for people to know each-other. We do a super cool exercise, where the people d draw heir Life-line: ups and down over their life-time (work and non-work life). Then they present it to everyone in the team. You have to set an example.. but it really works like a magic. Much better than the boring “introduce yourself”. You have to go first, as people can be shy until they start. (I think it depends a bit on your company culture if this exercise is a good idea.. if you are very formal, maybe it’s too personal)

      • We do 1on1 manager and new employee. We talk about the company, what it does, what we strive to do, strategy etc. Also practicalities (e.g. tools used, giving access to them). Also work process in the team. A key thing for us is: “Success in this role looks like this: X”. (setting clear expectations)

      • We try to have people achieve a task on their own in their first day. If they are engineers - we give them some good intro task for engineers. Nothing that needs knowledge of the whole codebase/complicated things. For example, some front-end changes, or some smaller bug that is not too complicated.

      • We do daily stand-ups on team-level anyway, and 1on1s. I think those are important.

      Documentation is nice, and well-defined process. But I wouldn’t do it until probably about 15 people in the company.

      Good luck!

      1. 2

        Great share Boris! Really liked how you shared the minutest of details :-)

        Keep in mind: splitting the work into pieces is very important in remote setting, and a bit different in remote setting. Because communication is a friction in remote, and work hours are not as measurable, you have to split and define the tasks. Therefore, you should need a bit less integration between the people compared to on-site roles.

        Amazing point! I think most of us focus too much on getting communication right when tasks can actually be broked down into capsules and to-and-fro avoided altogether. So true for engineering in particular.

        We try to have people achieve a task on their own in their first day. If they are engineers - we give them some good intro task for engineers. Nothing that needs knowledge of the whole codebase/complicated things. For example, some front-end changes, or some smaller bug that is not too complicated.

        Out of curiosity, do you guys also have pair programming sessions, maybe a week or two later? I have done only a handful myself but I am starting to believe these work really well in a remote context.

        1. 2

          On the first point - We start to believe that not only engineering tasks can be broken down well, but also in other areas. Marketing: set up this campaign, prepare the brand bible, do the copywriting of this email campaign. And so on.

          Putting a lot of effort in integrating the people well between themselves is important in remote work, due to the difficulty in doing it very well in a remote setting. But splitting the tasks is also important, to minimize the need for the good integration between the people.

          .

          On the second point - Pair programming - sometimes, but not so often actually. Even though pair programming with screen sharing works well from communication point of view. There’s not much friction in it.

          But we do ALL code reviews on a video call, with all developers in the team on the video call (we have small teams of a few developers in each team). It works really well, I think for the same purpose that you want the pair programming sessions. Everyone gets on the same page about the codebase, and exchange learning.

          My biggest difficulty here is to get people to give constructive feedback, instead of just saying “I agree with all of this”. But this, I guess, is the same in a non-remote team.

          1. 2

            Quite true! Splitting tasks is very much the same in other areas as well.

            Code reviews on video calls is nice. I was about to ask you earlier if you do code walkthroughs but this solves it all :)

            In fact, I remember from my earlier experiences that people used to give a ‘Ship It’ without even looking at the code! The video calls at least make sure the other person knows what code is written.

            1. 2

              Yes, I agree with you.

              People not being active participants on something… is one of the most disheartening moments as a manager :D

              1. 1

                People not being active participants on something… is one of the most disheartening moments as a manager

                Second that, without a doubt!

      2. 1

        Sarah,

        Unfortunately, many people who never worked remotely are masquerading as experts.

        You need to reach out to the experts who have worked remotely.

        As someone who has been doing it for the past 8 years, here are some of mine:

        1. Walk them through your company culture, their role, General introduction of the company, assign them their emails, set up accounts etc

        2. Assign them a buddy - ideally someone who has been there with them for a long time and knows the co in and out. It would be nice if they are from a different department.

        3. Have quick, short meetings with people with whom they’ll be working - first meeting would be with someone who’ll be their immediate boss and the last one with the CEO/CTO.

        4. Don’t introduce them to everyone on the first day! That’s a mistake people make - because they are blindly coaching after reading resources from the internet. You want to slow things down for the first few days, let them be comfortable and understand the place.

        5. Keep checking on them for the first week. Ask the buddy to keep in touch at the start of the day and towards the end so that they can seek help, clarify things and just bond.

        6. What Doist does is not possible for everyone. Of course, what the commentator forgot to mention is that Doist does it for people located in the same city. Even they don’t fly people across the globe to place someone in a mentor’s house! That’s why I said, masquerading remote work advocates.

        7. Introduce the new member to everyone on the team meeting.

        8. Create a checklist for things they need to do on the first few says on a tool, so that they have a guided process. Add videos, blogs etc on everything you think they need to go through to settle down in the new role.

        9. As the CEO, do check in on them quickly, just a simple text on how you can help them and how’s the experience so far here and there would be nice.

        If you have any questions or need any more help, just email me at [email protected]

        I’ll be happy to help :)

        1. 1

          Hey Bhagyashree,

          Thanks for such a detailed response. Some really great points.

          However, I am a bit unsure about certain aggressive statements. For eg:

          “Of course, what the commentator forgot to mention is that Doist does it for people located in the same city. Even they don’t fly people across the globe to place someone in a mentor’s house! That’s why I said, masquerading remote work advocates.”

          Firstly, Doist does fly people across cities, and it is not just for individuals in the same city. Here is the quote from their blog:

          “At Doist, we arrange Mentor Trips where a new teammate flies to meet their mentor in a different city and works with them in person for a week. This can expedite and ease the learning process and strengthen the bond between mentors and mentees.” (https://doist.com/blog/remote-onboarding/)

          We actually spoke to their Head of Marketing, Brenna on our podcast as well (https://content.remote.tools/trw-show-episode-1-brenna-loury-head-of-marketing-doist-2/). She confirmed this too. Do you have a better source than this?

          Lastly, more than anything, I would suggest that you keep the tone of your comments only helpful and avoid any name-calling. Always feel free to present your view. But, don’t claim to have a better opinion than anyone else.

          1. 1

            Thanks Kartik, I actually didn’t want to offend or be aggressive. Apology if it came across like this. :)

            1. 1

              Sure Bhagyashree :)

              It is best to just present your perspective. Masqueraders, etc. are pretty strong words. Each of us has our opinions, none greater than the other and each coloured by our experiences. You can say that you have a different perspective than someone else, but not better. The idea is to enjoy and learn from these discussions not to ‘win’ them.

              Hope you understand :)