Alisson Enz
Founder & CEO
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.
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:
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.
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.
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.
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 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:
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."
At the end of week one, the manager does a 30-minute check-in. Three questions:
Document the answers. The "still confusing" items become action items for the buddy or the team. The "don't have" items get resolved immediately.
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.
Alisson Enz
Founder & CEO
Founder and CEO of EnzRossi. After years working with tech, I started EnzRossi. Here I write about hiring, remote teams, and what actually makes a developer great.
Need engineers?
Book a free 30-minute call and we'll map the right roles, stack, and timeline for your team.
