A guide to the unique challenges that remote developers face when joining a new organization.

Everyone knows the nervous routines of starting a new job: sweaty palms and jitters upon walking into the office, back-and-forth internal dialogues as you sort out obstacles (“should I ask for help or play it cool?”), and maybe a pang of imposter syndrome as you worry that everyone knows more than you. Even in the absence of a formal onboarding program, face-to-face communication will prevail, helping you settle into a productive and confident routine within a few days.

Except when you’re a remote employee.

There are no lunch outings and break room conversations to make up for missed “meet the team” sessions. No unscheduled debugging alongside colleagues to teach you about the codebase. No quick questions after standup to point you in the right direction in the absence of assigned mentors or up-to-date org charts.

When you start a fully remote position, you must be intentional about integrating best practices into all facets of your work - there are few ways to learn as you go.

The Checklist

Some of the forthcoming advice overlaps with traditional onboarding plans. However that's by design. As a remote employee, it becomes your responsibility to overcome the deficiencies of any formal program.

Professional blogs are awash with advice on crafting the perfect onboarding program but are painfully lacking on practical advice for new hires. To ensure success in my latest remote consulting engagement, I analyzed my onboarding experiences from the perspective of a new remote employee. The checklist below identifies some of the core challenges and common mistakes.

A quick note on my background - over the past four years, I have:

  • Worked at three companies, in roles ranging from onsite technical lead to 100% remote consultant;
  • Spent time on teams ranging from 2 to 16 people;
  • Integrated into workflows ranging from Waterfall/on-prem servers/fixed release schedule to Agile/cloud-native/CICD & “move fast and break things”;
  • Hired and fired contractors;
  • And directly overseen subordinates moving from fully remote to fully onsite and vice versa.

Meeting the Team

☐ Send an introductory message to the team expressing your excitement and provide a summary of your background

  • Sounds simple, but it's easy to overlook. Unless you've interviewed with the whole team, your colleagues will not know anything about you. It's important to advertise the ways you will contribute to the team alongside areas where you may need some guidance.

☐ Set up an introductory 10-minute video call with each member of the team

  • Without a face-to-face meeting, it's crucial to build rapport with teammates and get answers to typical questions like "What are common mistakes made by new hires?" Somehow, many companies do this for onsite employees yet omit it for remote hires.

Communication

The guiding theme for communication is to work in public. You should display as much of your progress via online platforms as is feasible.

☐ Check code into Github multiple times per day

☐ Use public Slack channels over private DM's

☐ Broadcast blockers as soon as possible

☐ Use the webcam for all meetings

  • We use nonverbal cues to express ideas and feelings - there's no reason to sacrifice communication effectiveness just because you're having a bad hair day. And videoconferencing empowers more authentic communication and an easier exchange of ideas than relying exclusively on Slack/email.

☐ Schedule regular "office hours"

  • While working in the afternoon, I like to maintain an active Zoom videoconference for 2-3 hours. The link is posted to my team channel and people can hop on and off as they see fit. The afternoon schedule accommodates colleagues in other time zones.

☐ Verify internet speeds at your work location via https://fast.com/ (operated by Netflix)

☐ Get added to all relevant calendars (scrum ceremonies, release schedules, company holidays)

☐ Schedule a weekly 1:1 with your manager

Documentation

☐ Publicly share a list of all accounts you are awaiting, to convey status and expedite account creation process (e.g. G Suite, Slack, JIRA/Project Management tool, TestFlight, Github, AWS / GCP, Splunk)

☐ Be verbose in your ticket clarifications and documentation on JIRA/Trello/Asana etc.

  • PM's are prone to shorthand and imprecise language that can confuse new team members. Acceptance Criteria is a sticky subject.

☐ Create a directory of systems used by your team, including the best point of contact for questions

  • Why? It's embarrassing to have to ask the same question twice. And many organizations don't realize how fragmented their tech ecosystem really is. A format like this has been invaluable for onboarding (and helping later employees onboard):
System Name Technical POC Brief Description Location Open Questions
Splunk @jane-doe Microservice logging and monitoring https://example.com/splunk Do we have any non-standard conventions for log formatting?

Deliverables During Your First Week

You should be extremely intentional about selecting well-defined tasks with a limited scope that allow you to accomplish each of the following:
☐ Navigate the code base

☐ Configure your local environment

☐ Implement org's coding standards and Git workflows

☐ Receive feedback in a code review

☐ Run & pass tests

☐ Deploy code

☐ Aside from your defined sprint scope, request that the PM arrange several tickets in the backlog that are suitable for you.

  • In my experience, you will run into blockers and be unable to continue a task for the rest of the day. No big deal, switch to another ticket and be productive in another way.

Technical Overview

Getting introduced to technical systems is nearly identical for onsite vs remote, with one exception:
☐ Ask a colleague to demonstrate the testing and deployment process over video chat

  • There is a special pain to breaking the build when you work remotely. Validate your assumptions about tests, builds, and deployments so you can avoid conversations like this:

    Me: "I merged and the build succeeded, why aren't my changes showing up?"
    Coworker:"Oh put in a ticket for Devops to deploy. They might be able to get to it next week."
    Me:" But we're running CI with Jenkins and Docker."
    Coworker:"Yeah they need to copy and paste it into the EC2 box. We don't have it automated in the sandbox environment. Or the test environment. Or production. Actually automation is a work in progress."
    Me: ¯\_(ツ)_/¯

Project Overview

☐ Ask a PM to describe the release planning process in detail, in their own words

  • "Agile" has about as much meaning as "big data" and "AI" these days. Every dev team has a process and it doesn't matter which one they follow, so long as they actually execute it.

☐ Request an overview of the current state of the project, including long-term goals and major challenges

  • Put yourself into consultant mindset to see where you might be able to tackle the tough problems.

☐ Ask a peer to walk you through team structure and effective collaboration patterns - learn who has responsibility and ownership for the major systems

A Note on Mentorship and Peer Coaching

There are mentors who are invaluable as allies, helping you develop your skills and achieve career goals. For your first week, you should narrowly focus on the colleagues who have a good vantage point to understand the project/company and are accessible for questions.

Don't seek out the most senior developers - they are likely to be too busy to provide timely guidance. Nor should you place the burden squarely on your lead.


Thankfully I've never experienced a dynamic like the one above BUT there is a strong chance you are joining a team that is struggling to keep up with demands - that's why you were hired at all. Identifying a mentor or peer coach can help you learn quickly and navigate the nuances of the workplace.

Additional Resources

I hope this guide alleviates your concerns about joining a new team as a remote employee. If you are still uncertain about taking the plunge into remote work, the resources below are great points to continue your research.

Every onboarding experience is different so post in the comment section if you have additional tips/advice!