Last updated: March 16, 2026
Hybrid onboarding fails when the experience is inconsistent between in-office and remote days. New hires who happen to join on an office day get hallway introductions, context from overheard conversations, and spontaneous help from nearby colleagues. New hires who join on a remote day get a Zoom link and a Notion doc. The template below produces a structured, repeatable onboarding experience that works the same whether the new hire is at their desk at home or sitting in the office.
Week 1: Orientation and Access
The first week is about getting to productive as quickly as possible without overwhelming. Every task should have a clear owner and a deadline.
Day 1 — Access and accounts:
# .github/ISSUE_TEMPLATE/onboarding.yml
name: New Hire Onboarding
description: Checklist for onboarding a new team member
title: "Onboarding: [NAME] - Start Date: [DATE]"
labels: ["onboarding"]
body:
- type: checkboxes
attributes:
label: "Day 1: Access and accounts"
options:
- label: "Create GitHub account and add to org"
- label: "Create Google Workspace account"
- label: "Add to Slack workspace and key channels"
- label: "Send 1Password invite for team vault"
- label: "Add to Linear team (or Jira project)"
- label: "Add to PagerDuty rotation (observer, not on-call yet)"
- label: "Create calendar invite for first 1:1 with manager"
- label: "Add to recurring team ceremonies (standup, sprint planning)"
Day 1 — Environment setup (async):
# Send this setup script before the start date
# dev-setup.sh — works for macOS
# Install Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Install mise (tool version manager - replaces nvm, pyenv, etc.)
curl https://mise.run | sh
echo 'eval "$(~/.local/bin/mise activate zsh)"' >> ~/.zshrc
# Clone and run project setup
git clone git@github.com:your-org/dev-setup.git ~/dev-setup
cd ~/dev-setup && ./setup.sh
Send this with a README that covers: what the script does, what to do if it fails, who to ask for help. Async setup completion means the new hire arrives (or logs on) ready to write code, not running brew install.
Week 1: Social and Context
First 1:1 with manager (Day 1 or 2):
Cover three things: what success looks like in the first 30/60/90 days, how the team communicates and makes decisions, and what the new hire should NOT spend time on in the first two weeks. That last item is important — new hires often try to tackle everything and end up context-switching too much to build deep understanding of anything.
Team introductions — async first:
New hire intro template (post in #introductions Slack channel):
Hey team 👋 I'm [Name], joining as [Role].
Background: [2 sentences on where you're coming from]
What I'll be working on: [project or area]
Where I'm based / hours: [timezone and rough working hours]
Outside work: [1 interesting thing — this is what people actually remember]
Looking forward to meeting everyone. Feel free to reach out directly.
Async intros work better than going around a Zoom call. People can read them at their own pace, the new hire isn’t put on the spot, and the message is searchable later.
Week 2-4: Ramp-Up Tasks
The goal of weeks 2-4 is a meaningful first contribution — something shipped or merged, not just setup tasks checked off.
Starter issues process:
Label 5-10 issues as good-first-issue before the new hire starts. These should be:
- Scoped to less than 2 days of work
- Self-contained (don’t require deep system knowledge)
- Have clear acceptance criteria
- Have someone available to answer questions
The new hire picks one, works through it, and ships it. Nothing builds confidence faster than having a real contribution in production in the first two weeks.
First PR review process:
Assign a designated reviewer for the first 3 PRs. The reviewer’s job is not just to approve good code — it’s to explain the team’s conventions, point out patterns they’ll see everywhere, and highlight any context about why things are done a particular way. This context is impossible to find in documentation; it lives in the heads of experienced team members.
Hybrid-Specific Considerations
Calendar blocking for office days:
For hybrid setups, coordinate which days the new hire comes to the office so they overlap with the broader team. Avoid having a new hire’s office days be the days most of the team works from home.
Recommended first-month hybrid schedule:
- Week 1: 3 days in office (orientation, introductions)
- Week 2-4: 2 days in office, overlapping with team anchor day
- Month 2+: Standard hybrid schedule (team-specific)
Remote-day async support:
On remote days, new hires lose the ability to tap someone’s shoulder. Replace this with:
- A designated async help channel (#help-engineering or similar)
- Documented escalation path: comment on GitHub issue → ping in Slack → schedule call
- Response SLA: someone responds to new hire questions within 2 hours during working hours
The 2-hour SLA is critical. A new hire who asks a question and waits 6 hours for a response will either give up and work on the wrong thing, or feel unsupported and start disengaging.
90-Day Check-In Template
At the 90-day mark, run a structured check-in:
90-day onboarding check-in questions:
1. What are you most uncertain about in how the team works?
2. What information was hardest to find and should be better documented?
3. What would have helped you in your first two weeks that you didn't have?
4. What's your confidence level (1-10) in: the codebase / the deployment process / team communication norms?
5. Is there anything about your setup (tools, hardware, access) that slows you down?
The answers feed directly into improving the onboarding template for the next new hire.