What It Is
Remote onboarding is the process of bringing a new employee into a distributed company — equipping them with the tools, context, relationships, and clarity they need to do effective work — without the informal scaffolding of a shared physical office.
In an office, new hires absorb a lot passively: they hear conversations, observe culture, build relationships through proximity, and get redirected informally when they are headed in the wrong direction. Remote removes all of that. Effective remote onboarding replaces these passive mechanisms with deliberate ones.
Why It Works
Structured onboarding creates early confidence in distributed work. New hires in distributed companies face a double challenge: learning the job and learning to navigate an async environment at the same time. Companies that provide clear structure for both reduce anxiety and accelerate contribution.
Multiple support contacts solve the “who do I ask?” problem. 37signals assigns three support people to every new hire: an Ops buddy (technical setup), a 37signals buddy (cross-team cultural guide), and a manager (project direction). This matches the three categories of problems a new hire encounters and prevents any single person from being overwhelmed. (Source)
GitLab’s 2-week minimum onboarding acknowledges the real ramp cost. GitLab anticipates that remote onboarding takes at least 2 full weeks before team-specific work begins, plus a third week for team-specific training. This is structured, self-directed, and async — not a passive experience. (Source)
Automattic’s support rotation onboarding is genius. Every new Automattic hire spends their first two weeks in customer support — regardless of role. This ensures every employee understands the product from the customer perspective before doing any other work. Engineers who have done support write code differently. (Source)
Starting real work in week one signals trust. 37signals starts new hires on actual projects with support in their first week. GitLab encourages participation (without heavy contribution pressure) in the first two weeks. Starting real work early signals that the company trusts the new hire and reduces the “waiting to be told what to do” dependency.
Where It Fails
Onboarding that is too self-directed produces confusion, not independence. Distributed companies that pride themselves on autonomy sometimes mistake onboarding for a test of self-direction. New hires should not have to figure out how to onboard — that is the company’s job to design. Self-directed onboarding works after the structure is established, not instead of it. [Inference — practitioner observation; the structured-onboarding stance is consistent with what GitLab and 37signals actually publish, but no cross-company study measures the failure mode.]
Loneliness in the first month is the most commonly acknowledged failure. GitLab explicitly names it in their handbook: “The first month in a remote role can feel lonely, especially if you’re transitioning from a traditional office setting.” The coffee chat system, buddy programs, and social calls partially compensate. They do not fully solve the problem without active investment. (Source)
The 2-week onboarding assumption is wrong. Most new hires do not feel fully productive in 2 weeks. 37signals says most people feel fully integrated in “about 3 months.” (Source) Companies that expect 2-week ramp and then measure performance against fully-ramped peers are either setting the new hire up to fail or setting the expectation incorrectly.
Onboarding into a 2,000-page handbook is a real problem. GitLab acknowledges this. Reading the handbook is necessary; the handbook is overwhelming. Their solution: structured onboarding issues that sequence the reading and break it into phases. But the problem does not disappear — it is managed. (Source)
Best Examples
37signals / Basecamp — Three Buddies + Real Work in Week One.
- Pre-configured laptop arrives before start date
- Day 1: personal Basecamp project with role-specific to-do lists
- Three designated contacts: Ops buddy (technical), cultural buddy (cross-team), manager (direction)
- Recurring 1:1 with manager established on Day 1
- Real project work begins in first week
- 90-day ramp expectation
(Source)
Automattic — Trial Project + Two Weeks in Support.
- Paid 2–6 week trial project before full-time offer
- First two weeks of full-time employment in customer support
- Annual one-week customer support rotation forever after
- Team meetup within first year
- P2 blog onboarding documentation
(Source)
GitLab — Structured Issue-Based Onboarding.
- Onboarding issue opened 4 days before start by People Ops
- Self-driven, async, structured around three dimensions: organizational, technical, social
- 2 full weeks of structured onboarding before team-specific work
- Buddy program + Slack #new_team_members channel
- Bi-weekly “Ta-New-Ki” call for incoming hires before start date
- Coffee chat program for building cross-team relationships
(Source)
Implementation Guide
1. Design onboarding before the first hire, not during. Every new hire deserves a consistent, designed experience. Improvising onboarding for every new person is expensive and produces uneven results. Document the process once, maintain it, and personalize only the role-specific parts.
2. Assign three support contacts, not one. Separate the technical setup contact (Ops), the cultural guide (buddy from outside their team), and the work direction contact (manager). These three problem categories require different people.
3. Create a personal onboarding project or issue. 37signals’ personalized Basecamp project and GitLab’s onboarding issue serve the same function: a single place where the new hire can see what they need to do, in what order, with relevant context. Not a document. An actionable checklist.
4. Start real work in week one. Even small contributions. This signals trust, accelerates integration, and gives the new hire context about how work actually happens. Monitor and support; do not postpone.
5. Plan for a 90-day ramp, not two weeks. Set performance expectations against a realistic ramp curve. Define what “good” looks like at 30, 60, and 90 days. Communicate this to the new hire on day one — ambiguity about what is expected is one of the most common sources of new hire anxiety.
6. Build in social infrastructure. Coffee chats with people outside their team. A Slack channel for new hires. Optional but encouraged social calls. These are not extras — they are the substitute for the organic relationships that proximity builds in a physical office.
Common Mistakes
Over-automating onboarding. A series of automated emails and video modules is not onboarding — it is content delivery. Onboarding requires human contact, especially in distributed teams where the new hire cannot observe the culture through proximity.
Onboarding into documentation instead of work. Weeks of reading before the first real project produces anxiety and boredom, not confidence. Start actual work early and let documentation be the context for the work, not a prerequisite.
Making the buddy system optional. If the buddy relationship is not established in week one with a specific person and a specific check-in, it does not happen. The buddy program requires a named person, a defined check-in schedule, and active reinforcement from People Ops.
No formal 90-day check-in. Without a structured check-in at 60–90 days, small problems become large ones silently. New hires who are struggling often do not self-report in time because they do not want to be seen as failing.
Sources
- Getting Started — 37signals Employee Handbook: https://books.37signals.com/3/the-37signals-employee-handbook/7/getting-started
- How We Work — Automattic: https://automattic.com/how-we-work/
- Complete Guide to Remote Onboarding — GitLab: https://handbook.gitlab.com/handbook/company/culture/all-remote/onboarding
- GitLab Onboarding Process: https://handbook.gitlab.com/handbook/people-group/general-onboarding/
- All-Remote Drawbacks — GitLab: https://handbook.gitlab.com/handbook/company/culture/all-remote/drawbacks
Inferences
- Automattic’s support rotation onboarding (two weeks in customer support before anything else) is the most underappreciated onboarding practice in the remote-work canon. It serves three simultaneous purposes: product understanding, customer empathy development, and cultural integration through low-stakes cross-functional collaboration. Most companies could adopt a version of this — even a 3-day support shift at the start — and get significant value.
- The buddy system only works when it is structured and required. Every company that describes a buddy program includes language like “they will reach out during your first week.” The word “will” is doing a lot of work. In practice, buddy relationships that are not scaffolded with a specific check-in cadence and accountability become nominal — “I’m here if you need anything” rather than an active relationship.
Work with Alex
If your onboarding process is “read the wiki and figure it out,” and you’re losing new hires in their first 90 days to confusion and disconnection, Alex helps distributed teams build the structured onboarding systems that actually work.