Photo by Lauren Mancke on Unsplash

While the global pandemic saw a spike in layoffs, some companies continued to hire web developers. And that meant onboarding had to happen remotely.

I joined a new company last month when the pandemic was in full swing. This company was not remote-first, so remote onboarding was new to them and being a receiver of that onboarding was new to me. It's understandable that in this unprecedented situation, there will be room for improvement.

If you've landed a job with a company that is still in their early stages of refining remote onboarding, here are some things I hope you will find helpful:

Face faces until you're sick of faces

Think of how you could be onboarded in-person: You'd meet with an HR person to fill out paperwork. You'd be introduced face-to-face to key team members. It would be filled with just meeting new people and perhaps reading documentation.

Being told to read a Confluence page (documentation) should not be a replacement for the more high-touch, engaging onboarding you'd have at a traditional office. Substitute any in-person meetings that would've helped you get onboarded, with a video call. Your manager will most likely reach out and set you up with the basics, but ask for introductions or a "buddy" you can lean on for daily questions.

Reaching out to someone out of the blue, and asking them for their help, can be tougher to get a response. Especially in this remote time, it's easier to ignore people remotely than in person.

Once you've gotten the introductions and people agree to have video chats over coffee, amazing! Ask questions to get an idea of company norms and culture, or the ways of working. We make sense of our world by comparing things to past experiences, so try asking "I used to do __ at my old company; do you do that around here?".

Other good introductory questions to ask:

  • Team member roles
  • Definition of "done"
  • Project management rules (who has final say if something conflicts/changes)
  • Sources of truth (design, copy, requirements)
  • Priorities
  • Key people (ask for introductions to them)

These meetings can also serve as a way to build relationships. Most people are willing to be helpful. And if they're not, you'll learn who's a jerk and watch out for that next time. Your goal isn't "bothering" people. Your goal is to be empowered to be helpful and take loads off people's shoulders.

Incessantly ask questions

What do you ask, though? Often times, you don't know what you don't know, right? And sometimes we get worried about the volume of questions we ask. But here's what you ought to know:

Your team will expect any new team member to ask questions. No one enters a company knowing every nuance and undocumented rule. Ask lots of them and ask all the time. This is not the time to feel shy or embarassed that you don't get something. Take plenty of notes and refer to them any time you feel like you've asked the same question before.

Keep a log of everything you do

If you don't have time to write down what you've done throughout the day, make it your personal policy to take 10 minutes at the end of the day to reflect on the top 4 things you learned: a process, a person, an opportunity, and an accomplishment.


In web development, developers follow processes to move project tickets through a board: status changes, adding testing instructions, notifying people to review, etc.

Processes vary for every team and workplace, but it's a good idea to nail down something you're going to do all the time. If you're getting asked to correct something more than twice, it's a good idea to write it down and make certain what's expected of you. For example: "after peer review, move the ticket to the new status, notify the dev lead via Slack to perform final review, and follow-up if you haven't seen action taken within X hours/days".


I was once on a project that had 4 PMs. Before that, I was part of a team that had one PM who had final say on everything. When dealing with multiple 'managers', I made certain I understood who to go to whom for what. Eventually it will be second nature, but in the beginning of a new working relationship, it's important to nail down names and roles. For example: "For questions on marketing copy, talk to Lee. For questions about user interface copy, talk to Alex."

We think we can keep all this stuff in our heads until one day we confuse two similar people and they take offence to it. I was once on a team with two developers and they had the same first name (yes!!). Although they understood that people got them mixed up all the time, it shows respect and care that you took the time to understand their role and purpose.


If you noticed a broken or inefficient process (and you will find many!), write that down. Think about how long it took to do something, and how much time could be saved if you did X or Y. With every complaint about how something is a shit show, have questions on its origins. And bring those questions to your 1:1s. For example, "I notice we work on features that depend on ___ being built first, so we get blocked. I wonder if we could link our project tickets with epics/themes so we understand how each part depends on or fit with each other."

While it's the PM's job to make sure those issues don't happen, you are adding your experience from a developer's perspective. That is valuable insight that helps a project manager ensure their developers are always occupied. You aren't showing up as a complainer. You're not waltzing in pointing out what's broken. You are gathering information. Highlighting root causes. Re-shedding light to a problem that others ignored for a long time.


Even if all you did was update marketing copy, or centre-aligned something, it's still work that had to be done and someone saw value in it! No one is keeping tabs of what you've been doing, so when it comes time for performance check-ins or reviews, you have your list of features you helped push out, regardless of how small or big they were.

Pair up

I used to play a video game and struggled to finish a level because I wasn't changing anything about my approach. I'd search up the game and level title on YouTube and watched how someone else completed the level and it blew me away! All to say, I understand why people watch other people play video games on Twitch.

In the same vein, ask a developer if they'd be willing share their screen for a bit of time while they work on a ticket. You'll get a sense of what they're working on, and their approach to problems. You get to see their code with fresh eyes and make recommendations they didn't consider.

Get context

Often times, you need business context to understand what your priorities are as a developer. For example, the business might be under pressure to make their site accessible because they have a deadline looming to have their site audited. Or their reputation was trashed when their users information got leaked recently. This helps you know why you're doing certain kinds of work.

Ask to be included in planning meetings (just to be a fly on the wall and listen in, not necessarily to contribute). Planning meetings are gold, because it's where product owners and/or project managers (going forward, preferred to as "PM") prioritize what needs to be done in upcoming sprints. They're typically limited to just the development team lead and PMs, and then work is cascaded down to the developers (you). But it helps to listen in and gather context and key stakeholders, and business requirements will help you understand why you're doing the work.

You might hear a lot of unfamiliar terms, acronyms, names, or internal services. These are important to soak up, because you might be asked about them again later. Get a sense of timelines, scope, and urgency.

Don't be so hard on yourself

I would get anxious to tears when I still felt "new" at a company or job. I still do. Most teams will know that you're still learning the ropes and will have patience and compassion as you get up to speed.

Unless you've been faced blatant harassment by teammates, it takes a few months to know if a new gig is a good fit. An employment relationship is a healthy balance of learning and contributing. Yes, you are hired for your skill set to build out features and push out software that makes a company money. But you need to be happy that you're getting the experience you want for future you.

So give yourself that time and get the experience you want.

All the best 💜