Onboarding engineers in remote teams

I have onboarded engineers into remote teams across four companies and a handful of side projects. The first three times I followed the standard playbook: send the new hire a Notion onboarding page, a list of repos to clone, a Slack invite, and schedule a couple of intro calls in their first week. Each time the new engineer was lost for at least a month and disengaged for at least two weeks of that.

The pattern that finally worked is the opposite of the standard playbook. Less written material. More structured pairing. Real work in week one.

This is the format I run.

Day 1: laptop and one ship

The new engineer’s first day is one ship. A small one. End to end.

Before they start, I prepare:

• A laptop, set up. If hardware is shipped, it lands the week before. If they’re using their own, the setup script in the repo runs in 30 minutes.
• A pre-staged trivial PR. Maybe a typo fix, a package.json cleanup, a missing test. Something that takes 30 minutes.
• A code repo they can clone, run locally, and see the product working in under an hour.

Day 1 is: clone, run, ship the small PR, watch it land in production. By 5pm they have shipped to prod. They are not in the codebase as visitors. They are contributors.

This is the most important day of onboarding. Get it right and the rest cascades. Get it wrong and they spend three weeks reading docs and feeling outside.

Week 1: structured pairing, not solo reading

The standard remote onboarding sends the new hire a list of docs and tells them to “read up.” That is a failure mode. They read for two days, retain nothing, and emerge knowing less than they started because the docs are stale.

Instead, week 1 is paired. Every working day:

• 90 minutes of paired work in the morning. The new engineer drives. A senior watches and explains.
• 90 minutes of paired work after lunch. Senior drives. Explains why each step.
• The rest of the day is unstructured for the new engineer to play, read code, ask questions.

By Friday they have shipped 3-5 small PRs, watched a senior ship 2-3 medium ones, and asked at least 50 questions. They have an internal map of the codebase that no document could have given them.

Week 2: a real feature, scoped tight

In week 2, the new engineer takes a real feature. Small enough to ship in a week. Big enough to touch frontend, backend, and one cross-cutting concern (auth, multi-tenancy, jobs, observability).

I scope this feature myself. I do not ask the product manager. The product manager picks features for the team’s roadmap, not for an engineer’s onboarding. The right week-2 feature is:

• Customer-visible enough that finishing it feels real.
• Bounded enough that the engineer can ship by Friday.
• Touches at least three layers, so they get a tour by doing.
• Reviewed by me and one other senior, in conversation-style review.

By the end of week 2, they have shipped a real feature, gotten real review, fixed real bugs.

Week 3: a system design review

Week 3 the new engineer participates in their first system design review. Not as the driver - as a watcher. They sit in on a 45-minute review of a non-trivial change. They take notes. They ask one question.

Week 4 they drive a review themselves, on a small change of their own design. The senior I’m pairing them with watches.

After this, the team’s design rhythm is something they have observed three times and led once. They are inside the team’s decision-making, not outside it.

What I cut from the standard playbook

The standard onboarding had: a 40-page handbook, a list of acronyms, a tour of the org chart, four hours of videos about the product, three hours of compliance training, and a slow ramp where the new engineer wasn’t expected to ship for the first month.

I cut all of it except the compliance training (legally required) and a one-page handbook (about four screens of text). Specifically I cut:

• The 40-page handbook. Most of it was wrong. The team’s actual conventions live in CONTRIBUTING.md and the linter.
• The acronym list. New hires absorb acronyms from context in 2-3 weeks. A list memorised on day 1 is forgotten by day 5.
• The org chart tour. The team they need to know is who reviews their PRs and who owns the systems they’re touching. That’s 4-5 names, not 40.
• The product videos. Faster to use the product themselves while pairing.
• The slow ramp. A new engineer who hasn’t shipped by week 2 has lost confidence. A new engineer who shipped in day 1 has built it.

What this requires from me as the lead

• Two days of preparation before the new engineer’s day 1. Setup script tested. Small PR pre-staged. Calendar cleared for pairing.
• 3-4 hours per day of pairing in week 1. This is real time. I block it.
• A real feature scoped for week 2. Picked from the backlog by me.
• 90 minutes a day of pairing in week 2, decreasing over weeks 3-4.

This is significant. It is the highest-leverage 80 hours I will spend in a quarter. The new engineer is autonomous by week 5 and contributing at a senior level by month 3. Without this investment, they’re autonomous by month 3 and senior-level by month 9.