An onboarding template for a distributed engineering team is fundamentally different from an in-office one. The in-office version assumes ambient learning: the new hire absorbs how the team works by sitting near it. The distributed version cannot assume any of that. Everything that would normally be picked up by being in the room has to be written down, scheduled, or assigned to a person.
The template below is the version that has worked on real distributed teams. It is structured as a six-week plan, not because every onboarding takes six weeks, but because six weeks is the horizon at which most failure modes have already shown up. If the new hire is shipping by week four and well-connected by week six, the onboarding worked. If they are still asking who owns what in week six, it didn't.
When to use it
- You hire engineers across more than two time zones.
- Your team is fully remote or remote-first.
- Your onboarding currently relies on synchronous shadowing that does not work for the new hire's time zone.
- New hires consistently take longer than six weeks to be productive.
The template structure
This is the structure of the template. Copy it into a Notion page, a Linear doc, or a markdown file in your repo — it works in any of them.
ONBOARDING — [new hire name] Start date: [date] Buddy: [name] Manager: [name] WEEK 0 (BEFORE DAY ONE) [ ] Laptop shipped [ ] All accounts provisioned (auth, repos, cloud, vendor logins) [ ] Buddy assigned and notified [ ] Welcome message scheduled in #team channel [ ] Onboarding doc shared (this one) WEEK 1 — ORIENTATION [ ] Day 1: 30-min welcome with manager, no real work [ ] Day 1: 30-min with buddy — show me the team [ ] Read: team README, architecture overview, decision authority map [ ] Read: last quarter's decision records [ ] Watch: any recorded all-hands or team meetings from the last month [ ] First commit: any trivial change (typo, comment fix). Goal is the full PR-to-merge cycle on day one. [ ] Async intro post in team channel — by the new hire WEEK 2 — FIRST REAL WORK [ ] First real ticket. Should be scoped to one day. [ ] Buddy 1:1 each day this week (30 min, async-friendly) [ ] Manager 1:1 (30 min) [ ] Meet someone outside your immediate team (cross-team coffee) [ ] Read: the team's last postmortem [ ] Local dev environment fully working WEEK 3 — DEEPER WORK [ ] Multi-day ticket, paired with buddy [ ] First on-call shadow (if applicable) [ ] Skim: the team's last six PRs in your area [ ] Identify one piece of documentation that is wrong, fix it. WEEK 4 — INDEPENDENCE [ ] Owning a ticket end-to-end without prompting [ ] First on-call carry (if applicable) [ ] Manager 1:1: any blockers from the first month? WEEK 5 — INTEGRATION [ ] Lead a design discussion or write a small RFC [ ] Review someone else's PR (not your buddy's) [ ] Cross-team coffee #2 — different team WEEK 6 — RETROSPECTIVE [ ] Onboarding retrospective with manager: - What was missing from the docs? - What took too long? - What was unexpectedly good? [ ] New hire updates the onboarding doc with their fixes. ASYNC NOTES - All buddy 1:1s should default to async-friendly (written check-ins with optional synchronous overlap). Time zones make daily real-time 1:1s expensive. - The buddy is responsible for answering "who do I ask about X" so the new hire is not pinging the whole team. - The buddy is NOT responsible for the new hire's performance. That is the manager's job.
Governance, not a status channel
StandIn is async governance infrastructure. Engineers declare working state before they go offline. Representatives answer from the record, cite the source, and refuse when the answer is not there.
Request access →How to use it well
- The buddy is the single highest-leverage onboarding intervention. A buddy with explicit time set aside for the first month outperforms any documentation, any onboarding tool, and any process. Pick someone who actually wants to do it.
- Schedule the day-one trivial PR. The PR is not about the change; it is about exercising the full toolchain on day one. Local setup, repo, CI, review process, merge. Anything that fails surfaces immediately rather than in week three.
- The week-six retrospective updates the document. The new hire is the only person who can tell you what is missing from the onboarding doc. Their first contribution to the team's documentation should be fixing the doc that brought them in.
- Default all 1:1s to async-friendly. A daily fifteen-minute written check-in plus a weekly synchronous call usually outperforms five daily videos for time-zone-mismatched pairs.
- Do not skip the cross-team coffees. They feel like the most disposable item. They are the item that prevents the new hire from being a stranger to the rest of the org six months in.
What to skip
Skip dedicated onboarding software at small scale. A Notion page plus repo READMEs plus a Linear project for the first-month tickets plus a buddy covers most of the value for free. The case for a dedicated product appears above about thirty engineers, when manager-to-manager variance in onboarding starts to cost the team.
Skip the "drink from the firehose" first week. A first week packed with synchronous meetings is the wrong defaults inverted: it gives the new hire face time but no traction. One real PR by Friday is worth more than ten meetings.
Frequently asked questions
Is this template free?
Yes. The plan above is the whole template. Copy it into your team's onboarding doc and tailor the dates.
Can I edit it?
Yes. Most teams cut the on-call sections if they have none, and add a customer-shadowing section if they have a customer-facing component to their work.
Do I need to give my email?
Not for this. The downloadable version is a polished Notion template; the email is only for our newsletter list.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.