The short version
- Remote onboarding is not an information problem. It is a question-asking problem: the new engineer has forty questions and one person they feel able to ask.
- Plan the first thirty days around who answers what, not around what to read. Reading material is the part that already exists.
- Ship something small in week one. Nothing accelerates a new joiner like a merged change, and nothing delays them like waiting for answers.
- Across time zones the cost doubles: a question asked at 10:00 in one zone can cost a full day.
Onboarding documents are rarely the bottleneck. Most teams have a readme, a setup guide, and an architecture page, and a new engineer can work through all of it in two days. Then they hit their first real task and the questions start, and the speed of their first month is set entirely by how fast those get answered.
"Week one is forty questions and one person to ask."
Not an information problem
The questions a new engineer has are not the ones documentation anticipates. They are specific, contextual, and often slightly embarrassing: why does this test suite take twenty minutes, is this pattern still how we do things or is it old, who actually decides whether this goes in the release, is it normal that the staging environment is broken.
None of those are in a readme. All of them are known by three or four people, and the new joiner has been assigned one of them as a buddy. So forty questions queue against one person's availability, and the joiner starts rationing them, which is where the real damage begins.
A four-week plan that is about questions
| Week | Goal | Who answers questions |
|---|---|---|
| 1 | Environment running, one small change merged | Buddy, with two protected hours a day |
| 2 | One real ticket, end to end, reviewed closely | Buddy plus the area owner |
| 3 | Working from the normal board, normal review | The team channel, not the buddy |
| 4 | Owns something small. Writes down what confused them | Normal routes |
Notice that the third column changes each week, deliberately. The most common onboarding failure is that the buddy remains the sole route through month two, which is bad for the buddy and worse for the joiner, who never builds relationships with anyone else.
Week four's second task is the cheapest documentation improvement available: the new joiner is the only person who can see which parts were confusing, and they lose that vision within a month.
Ship something in week one
A merged change in the first week does more for a new engineer's confidence and understanding than two weeks of reading. It forces them through the whole pipeline: environment, tests, review, deployment, and it surfaces the broken parts of your setup immediately.
Pick the task before they start, keep it genuinely small, and make sure it is real rather than contrived. Fixing an actual small bug beats a sandbox exercise, because the review conversation is real and they meet the actual review standards.
The time zone multiplier
Everything above gets harder when the new joiner is not in the same zone as their buddy. A question asked at 10:00 their time meets an empty inbox, and they face the choice that costs the most in onboarding: guess, or wait a day.
Most new joiners guess, because waiting feels like being slow in their first fortnight. Then the guess surfaces in review, and they learn that asking would have been better, and now they ask everything, which overloads the buddy. Both failure modes come from the same cause.
Where possible, put a new joiner's buddy in their own time zone even if the buddy knows the area less well. Overlap matters more than depth in the first month. The broader pattern is in managing an offshore engineering team.
Where the forty questions should go
Most of a new joiner's questions have existing answers held by two or three colleagues. The problem is access, not knowledge, and the joiner is the least able person on the team to ration their own asking.
StandIn changes where those questions land. Each person on the team confirms a ninety-second brief at the end of their day, and while they are off, their StandIn answers questions from it in their words, with a source under every answer, clearly labelled, and never guessing. A new engineer can ask about the state of a piece of work, why an approach was chosen, or who owns a decision, at the moment the question arises, without deciding whether it is worth interrupting anybody.
The effect is specific: the joiner stops rationing questions, the buddy stops fielding forty of them, and the questions that do reach a human are the ones that needed judgement. See StandIn for the first 30 days.
Common Questions
How long should remote engineering onboarding take?
Aim for a merged change in week one, a real ticket in week two, and normal work by week three. Full productivity takes longer and depends mostly on how fast questions get answered rather than on how much was read.
Should a new remote hire have a buddy?
Yes, with protected time for it, and with a deliberate plan to reduce the dependency each week. A buddy who is still the sole route in month two is a sign the onboarding did not connect the joiner to the rest of the team.
What is the biggest remote onboarding mistake?
Front-loading reading and assuming the questions will be small. The reading is the easy part; the month is decided by the questions, and by whether the joiner feels able to ask them.
Should the buddy be in the same time zone?
Usually yes, even at the cost of some expertise. In the first month, availability beats depth, because a new joiner blocked for a day loses more than they would have gained from a more knowledgeable answer.
Log off like you mean it.
Your StandIn answers the questions that come up while you're out, from what you actually wrote down, so the return pile stays small.