A new developer joins your remote team. They get a welcome email with seventeen links. A Slack message that says "let me know if you have questions." A calendar invite for a one-on-one next week.
By day three, they're stuck on environment setup. By day five, they've read a lot of docs but haven't pushed any code. By week two, they feel disconnected and behind.
This is the default onboarding experience at most companies. It's not intentionally bad. It's just not intentionally good. Here's the playbook we use with every engineer we place. It gets people productive in 48 hours.
Before day one (the pre-boarding checklist)
Onboarding starts before the developer's first day. If you wait until day one to set up accounts, you've already wasted their most motivated hours.
72 hours before start date, complete these:
- Create all accounts: GitHub/GitLab, Slack, Jira/Linear, AWS/GCP (whatever they need), email, VPN
- Add them to the relevant Slack channels (team channel, project channels, social channels)
- Send them a welcome doc with: team roster and roles, product overview (2 pages max), tech stack summary, link to the dev environment setup guide
- Assign a buddy (more on this below)
- Put three meetings on their day-one calendar: a 30-minute welcome call with their manager, a 45-minute product walkthrough with the buddy, and a 30-minute architecture overview with a senior engineer
The goal: by the time they open their laptop on day one, every account works and they know exactly what their first six hours look like.
Day one morning: orientation and context
9:00 AM: Welcome call with manager (30 min). This is not a process overview. It's a human conversation. "Here's what the team is working on this quarter. Here's where you'll fit in. Here's what success looks like in your first 30 days." Keep it specific. "You'll be working on the checkout flow refactor with Ana and Marcus" is better than "you'll be joining the platform team."
9:45 AM: Environment setup. This should take less than an hour if your setup guide is current. The buddy should be available on Slack during this window to answer questions in real time. If setup takes longer than an hour, your guide is out of date. Fix it.
11:00 AM: Product walkthrough with buddy (45 min). Screen share. Walk through the product as a user. Show the main flows. Point out the parts that are clean and the parts that are messy. Be honest. "This module is well-tested. This other one is legacy code that nobody wants to touch." Honesty builds trust faster than a polished presentation.
Day one afternoon: first commit
1:00 PM: Architecture overview (30 min). Senior engineer walks through the codebase structure. Not every file. The big picture: how services communicate, where data lives, how deployments work, where the CI/CD pipeline is configured. Draw a diagram if it helps.
2:00 PM: First task. This is critical. Have a small, well-defined ticket ready. Something like: "Update the copy on the settings page" or "Add a missing field to the API response." The ticket should be completable in 2-3 hours and should touch the real codebase, not a sandbox.
The goal is a merged PR on day one. It doesn't matter if the change is tiny. The psychological impact is huge. "I shipped code on my first day" creates momentum that carries through the first week.
5:00 PM: End-of-day check-in with buddy (15 min). Quick call. "How did it go? Anything confusing? Anything blocking you?" This is not optional. Remote developers won't always proactively share when they're stuck. Give them a structured moment to do it.
Day two: first real contribution
Morning: Second task. This one should be slightly more complex. A bug fix that requires understanding a specific module. A small feature that touches two services. Something that requires reading existing code, not just adding new code.
Afternoon: Join a team ceremony. Sprint planning, refinement, or a team retro. Doesn't matter which one. The point is to see how the team communicates and makes decisions. Encourage the new developer to ask questions during the meeting. "What does that acronym mean?" is a perfectly valid question on day two.
The buddy system
The buddy is the most important part of this playbook. Without a buddy, new developers default to reading docs in silence and feeling lost.
A good buddy is not necessarily the most senior person on the team. They should be someone who:
- Knows the codebase well enough to answer "where does X happen?" questions
- Is responsive on Slack (replies within 30 minutes during work hours)
- Is patient with questions that might seem obvious
- Has bandwidth: don't assign someone in the middle of a critical deadline
The buddy commitment is roughly 2-3 hours of availability spread across the first week. It's not a heavy lift, but it needs to be explicit. "You're Alex's buddy this week" is different from "keep an eye out for the new person."
Week one checkpoint
At the end of week one, the manager does a 30-minute check-in. Three questions:
- "What's clearer now than it was on Monday?"
- "What's still confusing?"
- "Is there anything you need that you don't have?"
Document the answers. The "still confusing" items become action items for the buddy or the team. The "don't have" items get resolved immediately.
What most companies skip
Three things that most companies skip and shouldn't:
A pre-selected first task. Telling someone to "look around the backlog and pick something" on their first day is paralyzing. Pick the task for them. Make it easy. Make it real.
Async documentation that's actually current. If your README hasn't been updated in six months, it's worse than having no README. Outdated docs create false confidence and wasted time. Before a new person starts, have the buddy verify that the setup guide works.
Social connection. Remote developers need to know their teammates as people, not just Slack avatars. Schedule a casual team call during week one. No agenda. Just conversation. This sounds soft, but it directly impacts how comfortable someone feels asking for help when they're stuck.
The 48-hour onboarding playbook isn't complicated. It's just intentional. Every hour of the first two days is planned. Every question has a person to answer it. Every task is pre-selected and scoped.
The companies that get remote onboarding right don't do anything magical. They just refuse to leave it to chance.
