The new engineer had been hired fully remote. On day one, she received login credentials, a Slack invite, and a message saying "let us know if you need anything." By week two, she was lost—no clear projects, no idea who to ask questions, no understanding of how anything fit together.
"It felt like I was invisible," she told me. "I'd send messages and wait hours for replies. I didn't want to bother people, so I just sat there trying to figure things out alone. It was the loneliest I've ever felt at a job."
She lasted four months before finding a role at a company that actually onboarded people.
Remote onboarding fails when companies apply in-office assumptions to distributed work. The casual learning that happens naturally in an office—overhearing conversations, grabbing someone after a meeting, watching how things work—doesn't exist remotely. The informal mentorship, the ambient context, the social integration—all of it must be deliberately designed.
After helping over 40 companies build remote onboarding programs at SmithSpektrum, I've learned that the difference between successful and failed remote hires often comes down to the first 90 days[^1].
Why Remote Onboarding Is Different
In an office, new hires learn through osmosis. They hear conversations about how decisions get made. They see who talks to whom. They can ask quick questions without scheduling a meeting. They pick up cultural norms by watching how people behave.
Remote eliminates all of this. Every piece of context that an office hire absorbs passively must be actively transmitted to a remote hire. That requires explicit design work that most companies underestimate.
The psychological dimension matters too. Starting a new job is inherently anxiety-inducing. Am I doing okay? Do people like me? Am I contributing enough? In an office, you get constant micro-signals that answer these questions—a smile from a colleague, casual positive feedback, inclusion in lunch conversations. Remote new hires get radio silence punctuated by scheduled meetings. Without deliberate intervention, they spend weeks wondering if they're failing while having no way to check.
The companies that succeed at remote onboarding recognize this asymmetry and design for it explicitly. They don't assume new hires will "figure it out." They create structures that substitute for the informal learning and social connection that offices provide naturally.
The First Week: Reducing Anxiety and Building Connection
The first week sets the tone. Your goals are simple: make the new hire feel welcome, give them enough context to orient themselves, and ensure they have human connections—not just access to tools.
| Onboarding Phase | In-Office Equivalent | Remote Adaptation | Success Metric |
|---|---|---|---|
| Day 1 orientation | Office tour, desk setup | Video welcome, shipped equipment | Can access all systems |
| Week 1 | Shadowing, lunch with team | Structured 1:1s, Slack intros | Knows who to ask |
| Month 1 | Osmosis learning | Documentation + buddy system | First PR merged |
| Month 2-3 | Full contribution | Gradually reduced check-ins | Owns a feature |
Before they start, send equipment early enough that it arrives with time to spare. Nothing says "we're not prepared for you" like a new hire spending day one waiting for a laptop. Include a welcome package if you can—some companies include swag, a handwritten note from the hiring manager, or a gift card for a first-week coffee run.
On day one, have their manager meet with them immediately—within the first hour. Don't let them sit alone wondering what to do. This meeting should cover: what the first week looks like, who they'll be meeting, what they should focus on learning versus doing, and explicit permission to ask "too many" questions. End by scheduling their next one-on-one.
Assign an onboarding buddy who isn't the manager. This should be a peer—someone who can answer the questions new hires feel awkward asking their manager. "Is it okay to message people directly or should I wait for replies?" "How do people actually use Slack here?" "Who should I talk to about X?" The buddy relationship only works if you explicitly empower the buddy and build in check-in time.
Schedule a team welcome meeting, but keep it social rather than substantive. Let people introduce themselves, share something personal, ask the new hire questions. The goal is human connection, not information transfer. New hires remember who made them feel welcome; they forget the slides from their first presentation.
Front-load the human interaction in week one. Days packed with meetings are exhausting, but for new remote hires, they're better than days of silence. Build in video conversations even if they seem unnecessary. The new hire is building their mental map of the organization, and that requires seeing faces and hearing voices.
Documentation: The Backbone of Remote Onboarding
Remote onboarding lives and dies by documentation. Without good docs, new hires must schedule meetings to get information that should be self-service. With good docs, they can move quickly while reserving synchronous time for things that actually need discussion.
Start with an onboarding guide—a single document that serves as the new hire's home base for the first few weeks. It should answer: What should I read first? Who are the key people? Where do I find things? What are the important communication norms? What should I accomplish in weeks one, two, and four?
Architecture documentation matters enormously for engineers. How does the system work? What are the major components? How do they fit together? New engineers joining a remote team can't lean over to a colleague and ask for an architecture overview. If it's not written down, they're stuck.
Process documentation prevents confusion and the awkward feeling of doing things wrong without knowing it. How do pull requests work here? What's the deployment process? How do people handle on-call? What's the meeting culture? Every company has implicit norms; remote companies must make them explicit.
Cultural documentation captures the things that are "just understood" in offices. What does work-life balance actually look like here? How do people communicate urgency versus routine? What's the expectation around response times? Is it okay to decline meetings? These feel like soft questions, but they're what new hires spend mental cycles wondering about.
The documentation doesn't need to be perfect to be valuable. Even rough documentation is better than none. And the act of creating onboarding documentation often reveals gaps in your processes that affect everyone, not just new hires.
Structured Learning: The Onboarding Program
Beyond documentation, new engineers need structured learning experiences that build their knowledge systematically.
I recommend a 30-60-90 day framework with explicit goals for each phase.
In the first 30 days, focus on learning and small wins. The new hire should understand the codebase well enough to make meaningful contributions, learn the key systems and processes, build relationships with their immediate team, and ship at least one small PR that makes it to production. The last point matters—shipping something, even something small, creates psychological momentum.
In days 30-60, focus on increasing independence. The new hire should own a meaningful project or feature, need less hand-holding for routine tasks, and start contributing in meetings rather than just listening. They should know who to go to for different types of questions and have relationships extending beyond their immediate team.
In days 60-90, focus on full productivity. The new hire should be contributing at a level appropriate to their experience, participating fully in team processes, and beginning to identify improvements to make—questions like "why do we do it this way?" are signs of healthy integration.
Each phase should have a check-in meeting where the manager and new hire discuss: What's going well? What's confusing? What help do you need? Are you getting enough face time with people? These check-ins surface problems early, before they compound into resignation.
Building Relationships Remotely
The hardest part of remote onboarding is the relationship-building that offices facilitate naturally. New hires need to feel part of a team, not just holders of a job.
Schedule one-on-ones with key collaborators during the first two weeks. Don't wait for relationships to form organically—they won't. Proactively introduce the new hire to people they'll work with, and give those conversations enough time to be more than transactional.
Include the new hire in existing team rituals. If the team has coffee chats, game sessions, or social channels—include them from day one. Don't wait until they've "proven themselves" to invite them to the human parts of work.
Encourage video-on culture, at least for onboarding. I know video fatigue is real, and many remote teams default to cameras off. But for new hires especially, seeing faces matters. Consider a cameras-on norm for onboarding-related meetings even if other meetings are cameras-optional.
Create opportunities for informal interaction. Some companies use random coffee pairing tools. Others have optional end-of-week hangouts. The mechanism matters less than the intent: give new hires chances to connect with colleagues about something other than work.
Common Failures and How to Avoid Them
The most common onboarding failure is expecting too much self-direction too early. Remote work requires self-direction eventually, but new hires don't know enough to direct themselves yet. Providing clear guidance in the first weeks isn't coddling—it's setting them up to be independent later.
Another common failure is the information dump. Sending new hires fifty documents on day one and saying "read these" doesn't work. Information without context doesn't stick. Pace the learning, and tie documentation to practical exercises that reinforce it.
Failing to check in regularly is devastating remotely. In an office, managers see their team members throughout the day. Remotely, you have to create check-in touchpoints explicitly. If a new hire is struggling and you don't notice for three weeks, you've lost them.
Not assigning real work early enough creates drift. New hires want to contribute. Endless onboarding with no actual work feels like purgatory. Within the first two weeks, they should be working on something real—even if it's small and heavily supported.
Finally, treating remote onboarding as a scaled-down version of in-office onboarding misses the point. Remote onboarding isn't less onboarding—it's different onboarding, with different requirements and different failure modes.
The engineer who felt invisible for two weeks before giving up? Her company eventually rebuilt their onboarding from scratch. They created a 30-60-90 day program with explicit milestones, assigned onboarding buddies, built a documentation library, and required managers to meet with new hires daily during week one.
Their next remote hire thrived. She shipped her first PR on day four, had one-on-ones with six teammates by the end of week two, and told her manager after 90 days that it was the best onboarding experience she'd ever had—remote or otherwise.
Remote onboarding requires design. The companies that invest in it retain their hires. The companies that wing it lose them—often before they've contributed anything meaningful.
References
[^1]: SmithSpektrum remote onboarding advisory, 40+ companies, 2020-2026. [^2]: GitLab, "Remote Onboarding Guide," 2025. [^3]: Buffer, "State of Remote Work," 2025. [^4]: Harvard Business Review, "The Right Way to Onboard Remote Employees," 2023.
Building a remote onboarding program? Contact SmithSpektrum for process design and implementation support.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum