To onboard a remote developer well, get their access working before day one, have them merge a small change in the first week, and give them a real piece of work in the second. The first two weeks decide more about a developer's first year than the interview did. One who spends week one waiting for accounts will still get there, just slower. One who ships on day two and meets the right people by Friday is working like a teammate from the start.
This guide is a practical plan for those two weeks, written for the engineering lead on the client side of a remote or nearshore engagement.
Remote developer onboarding checklist
The short version, for pinning to a ticket:
Before day one
- Every account requested: source control, issue tracker, chat, cloud console, CI, error monitoring, design tool
- A buddy chosen (a teammate, not the lead)
- A small, real first task picked
- Shared working hours and the urgent-question channel written down
- Welcome call on the calendar for day one
Week one
- Every account confirmed working during the welcome call
- Project running locally
- First pull request opened, reviewed the same day, merged
- Introductions to product, design and whoever runs deploys
Week two
- A piece of work with some ambiguity in it
- Included in planning as a participant
- Reviewing someone else's code
- A fifteen-minute check-in on what to fix about onboarding
The rest of this guide explains each step.
Before day one
With a contractor engagement, the paperwork (the contractor agreement, identity and tax documentation, and payment setup) is handled by the contractor of record before the developer starts. If you work with sourceBOLD, that's us; what a contractor of record is covers it in more detail. What's left is the part only your team can do.
A week before the start date:
- Request every account. Access is the most common reason a first week stalls, and requests almost always take longer than expected.
- Pick a buddy. One engineer who answers the small questions. Ideally not the lead, because the lead is the person people hesitate to interrupt.
- Choose the first task. Small, real and shippable in a day or two: a bug with a clear reproduction, a missing test, a small UI fix. The goal is a first merged change, not an impressive one.
- Agree on working hours. Write down the shared window. If you're spanning time zones, our guide to Latin America time zones shows how the clocks line up with US time.
Week one: access, context and a first merged change
Day 1. A short welcome call with the lead and the buddy. Confirm every account works while you're on the call, not after. Walk through how the team works: where decisions are written down, how code review runs, what "done" means. Then hand over the first task.
Day 2. The developer gets the project running locally and starts the task. Expect setup questions. Each one is a gap in your onboarding docs, so write the answers down where the next person will find them.
Day 3. The first pull request goes up. Review it the same day, to the same standard as anyone's. Being gentle with a new person's first change is kind in the moment and confusing a week later, when the real standard shows up.
Days 4 and 5. Merge the first change. Hand over a second task in a different part of the system. Short introductions with the people they'll depend on.
By Friday you want three things to be true: they can run the project, they've merged a change, and they know who to ask about what.
Week two: a real piece of work
Hand over something with a little ambiguity. A feature slice or a meaningful bug, with enough unknowns that they'll need to ask questions and make a judgment call. This is where a senior developer starts showing you what you engaged them for.
Include them in planning. Put them in the next planning or refinement session as a participant, not an observer. Ask for their estimate on something and listen to how they reason about it.
Let them review someone else's code. Reviewing is one of the fastest ways to learn a codebase, and it tells the team the new person's opinion counts.
Hold a short check-in. Fifteen minutes, three questions: what's been confusing, what's slowing you down, and what would you change about how we onboard? The third is the most useful question you'll ask, because a new person sees the gaps a settled team no longer notices.
Signs remote onboarding is working
- Pull requests are getting smaller and more frequent, not larger and rarer.
- Questions are shifting from "where is this?" to "why is it this way?"
- They raise blockers in standups, not just progress.
- Someone else on the team has asked them a question.
Warning signs to act on early
- A long silence. Several days with no pull request and no question usually means someone is stuck and doesn't want to say so. Ask directly.
- Access still incomplete in week two. Fix it that day. Every day it lingers teaches the developer they're a guest.
- Receiving work without context. A developer who's only handed tickets will behave like a vendor. Put them in the conversations where the context lives.
The short version
Access before day one, a merged change in week one, real work in week two, and a check-in that asks what to fix. None of it is complicated. It's just easy to skip, and teams that skip it spend month three wondering why the new developer still feels new.
If you're at the stage before this one, how to interview a senior software developer in one hour covers the conversation that comes first. And if you'd rather start with developers who arrive vetted and ready, how it works walks through a sourceBOLD engagement from brief to first day.