Remote onboarding has a specific failure mode: the new hire is technically set up — they have a laptop, they’re in Slack, their calendar has some meetings — but nobody gave them a map. They don’t know where to find things, who to ask, what’s expected in the first week versus the first month, or how to tell if they’re doing well.
We’ve onboarded nine people remotely over the past three years. The process has gotten significantly better each time, mostly by adding structure where we previously relied on “they’ll figure it out” or “just ask anyone.” This is the framework we use now — a 30-day checklist broken into four phases.
Before day one: the pre-boarding setup
Onboarding doesn’t start on the hire’s first day. It starts the week before, when you remove every possible friction from their first morning.
Ops / IT tasks (completed before day one):
- Laptop shipped and confirmed received
- Email account created
- Accounts provisioned: Slack, Notion, Google Workspace, GitHub (or equivalent), project management tool, password manager
- Added to relevant Slack channels (start with
#announce-,#social-general,#team-[their team], and 1-2 active#proj-channels) - Calendar invitations sent for first-week meetings: welcome call, manager 1:1, team intro, buddy check-ins
- Onboarding Notion page created (see below)
The onboarding Notion page: This is a dedicated page for the new hire that serves as their home base for the first 30 days. It contains:
- A welcome message from their manager
- Links to every tool they’ll use (with login instructions)
- The 30-day checklist (this document, personalized for their role)
- A “who’s who” section: names, roles, time zones, and a one-sentence “what they work on” for each team member
- Links to the team handbook, communication guide, and meeting norms
We send the new hire a link to this page the Friday before they start, along with a note that says: “Read through this when you have time over the weekend — no pressure, but it’ll make Monday less overwhelming.” Most people appreciate having something to look at before day one.
Week 1: orientation and access (days 1–5)
The first week is about access, context, and one critical human connection: their onboarding buddy.
Day 1
- Welcome call with manager (30 min, video). Not a deep work session — a real welcome. What the first week looks like, what they should focus on (hint: reading and exploring, not producing), and how to reach their manager when they need something.
- Onboarding buddy introduction (15 min, video). The buddy is a peer on the team — not the manager — who’s available for the questions you feel silly asking your boss. “Where do I find the brand guidelines?” “Is it normal that I don’t have access to this repo?” “Do people actually use the #social channels?” Buddy check-ins happen daily in week 1 (15 minutes, informal).
- Self-guided tool setup. The new hire works through the onboarding Notion page, logging into tools, setting up their local environment, and confirming access. They flag anything that doesn’t work in a dedicated
#onboarding-[name]Slack channel.
We create a temporary Slack channel for each new hire: #onboarding-[first name]. This gives them a place to ask setup questions without feeling like they’re cluttering a team channel. Their buddy and manager are in the channel. We archive it after 30 days.
Days 2–3
- Team introductions. A 30-minute group call where each team member gives a 2-minute intro: what they work on, where they’re based, what they’re currently focused on. The new hire introduces themselves. Keep this casual.
- Read the team handbook. We ask new hires to read our handbook cover to cover in the first three days. It’s about 15 pages and covers: how we communicate (including our async communication stack), how we run meetings, what our Slack structure looks like, time zone expectations, and time-off policies.
- Explore the wiki. Dedicated time to browse Notion. We don’t expect them to read everything — the goal is to know what exists and where to find it.
Days 4–5
- First 1:1 with manager (30 min). A structured check-in: What’s clear? What’s confusing? Anything they need access to? This is also where the manager shares 30-day expectations in concrete terms — not “get up to speed” but “by day 30, you should be able to independently handle [specific deliverable].” (Lara Hogan’s questions for a first 1:1 are a good starting point for this conversation.)
- Buddy check-in. By end of week 1, the buddy asks: “On a scale of 1-5, how lost do you feel?” Honest answers guide how much support week 2 needs.
- First small task. Something low-stakes and completable — the point is to get them into the workflow using the real tools and real process, without the pressure of a critical deliverable. For engineers, this might be a well-scoped bug fix with a clear reproduction step. For content, it might be editing a draft that’s already been through one round of feedback. For ops, a data pull or report update with a known format.
Week 2: contribution and context (days 6–10)
Week 2 shifts from reading to doing. The new hire should be contributing to real work, but with guardrails.
- Assigned to an active project. They join a project that’s in-progress and get a specific, scoped piece of work. Their buddy or a senior team member reviews their first deliverable and gives explicit feedback — not just “looks good” but “here’s how we’d approach this differently and why.”
- Shadow a meeting. They attend a weekly sync as an observer. Afterward, their buddy explains the context they might have missed: who the stakeholders are, why certain decisions went a certain way, what the history is.
- Manager 1:1 (30 min). Focus on their first contribution: What went well? What was harder than expected? Adjust expectations if needed.
- Buddy check-ins drop to 2-3 per week. The new hire is getting more self-sufficient. Buddy is still available but doesn’t need to be proactive daily.
Milestone check: end of week 2
By day 10, the new hire should be able to:
- Navigate the team’s Notion workspace and find key documents without help
- Follow the communication norms (posting in channels, using threads, async updates)
- Complete a scoped task with normal-quality review feedback (not exceptional feedback that signals they’re struggling with basics)
If they’re not there, that’s not a failure — it’s a signal to extend week-1-style support for a few more days.
Week 3: independence with support (days 11–20)
This is the transition phase. The new hire moves from guided work to self-directed work.
- Owns a piece of a project end-to-end. Not just executing a task — planning the approach, estimating the timeline, communicating progress async, and delivering the result.
- Writes their first async update. They post a project update using the team’s standard format (we use a simple Notion template: what’s done, what’s next, any blockers). This is a forcing function for learning how to communicate progress without a meeting.
- Contributes to a decision. Either in a weekly sync or in an async discussion in Notion, they weigh in on something. The team explicitly creates space for this: “What do you think about this approach?” New hires often have valuable fresh-eyes perspective.
- Manager 1:1 (30 min). Feedback on their independent work. Discussion of how they’re feeling about the team, the pace, and the communication style. Any cultural things that are unclear.
- Buddy check-ins drop to once per week. Mostly social at this point — “how’s it going?” rather than “where do I find X?”
Week 4: full integration (days 21–30)
By week 4, the new hire should be operating at near-normal capacity (not full speed — that takes 60-90 days — but independently and confidently).
- Full project ownership. They’re assigned work the same way any other team member is. Reviews and feedback follow normal cadence.
- Manager 1:1 (30 min) — the 30-day review. This is a structured conversation:
- What’s going well?
- What’s still confusing or harder than expected?
- Is the role what they expected?
- Feedback from the manager on performance, communication, and integration.
- 60-day goals (what does “fully ramped” look like?).
- Buddy relationship becomes optional. The formal buddy program ends at day 30. Many pairs continue informally — which is the best outcome.
- Retrospective. The new hire fills out a short form: What worked in the onboarding process? What was missing? What would have helped in week 1? We use this feedback to improve the process for the next hire.
Milestone check: end of day 30
A successfully onboarded remote hire at day 30:
- Communicates asynchronously without prompting — posts updates, uses the right channels, documents decisions
- Can find information in the wiki and tools without asking for help
- Has delivered at least two pieces of independent work at acceptable quality
- Knows the team’s norms and follows them (meeting format, Slack etiquette, response times)
- Has formed at least one working relationship beyond their manager (usually the buddy)
Things we got wrong
Mistake 1: Too many meetings in week 1. Our first version had 3-4 hours of meetings daily for the first three days. New hires were exhausted and had no time to actually explore the tools and docs. We cut week-1 meetings to 1-2 hours per day max.
Mistake 2: No buddy system. For our first three hires, the manager was the only point of contact. This creates a bottleneck and makes the new hire feel like they’re constantly bothering their boss. The buddy system solved this completely.
Mistake 3: Vague “get up to speed” expectations. Without concrete milestones, neither the new hire nor the manager knew if onboarding was going well. The milestone checks at days 10, 20, and 30 give both parties a shared definition of progress.
Mistake 4: Not creating a temporary Slack channel. New hires posted setup questions in #general and felt self-conscious about it. The dedicated #onboarding- channel normalizes asking questions and keeps the noise contained.
Remote onboarding works when you treat it as a designed experience, not something that happens by osmosis. The 30-day structure gives the new hire a clear path and gives the team a repeatable process. Customize the details for your context — the timeline, the milestones, the tools — but keep the progression: access, context, guided work, independent work, full integration.