A new engineer joins your team. They are five hours ahead of everyone who could answer their questions. By the time they hit their first real blocker, the people who know the answer are offline. They sit there, stuck, wondering if this is what the job will always feel like.
Most onboarding advice assumes someone is around to ask. Remote onboarding across time zones breaks that assumption. Here is how to onboard someone who genuinely cannot tap a shoulder.
Assume the first blocker will happen while everyone is asleep
In an office, a new hire who gets stuck looks up, catches an eye, and asks. That safety net is gone when the team is spread across time zones. The new engineer will hit a wall, and there will be no one online for six hours.
So design for that moment on purpose. Before day one, ask yourself: when this person gets stuck at hour three with nobody awake, what do they reach for? If the honest answer is "they wait," you have not onboarded them. You have scheduled their frustration.
Write the setup path down and test it on a real person
Every team believes their setup docs are fine. Most are not. They were written by someone who already had the tools installed, the access granted, and the tribal knowledge in their head. They skip the three steps that actually trip people up.
The fix is boring and it works: have the last person who joined redo the setup from the doc, on a clean machine, and write down every place they had to guess or ask. Those gaps are your real onboarding backlog. A setup path a new engineer can follow alone, start to finish, is worth more than any welcome call. If you are choosing tools to support this, it is worth looking at the wider set of options for structured onboarding in this roundup of engineering team onboarding software, but the doc comes first.
Give them a first task that cannot silently fail
A good first task for a remote engineer has three traits. It is real, so it matters. It is small, so it finishes inside a day or two. And it has a clear finish line, so the engineer knows when they are done without needing someone to confirm it.
The trap is the vague first task: "take a look around the codebase and get familiar." With nobody to check in with, that turns into hours of aimless reading and quiet doubt. "Fix this specific typo in the settings page and open a pull request" is better. It teaches the whole pipeline, from local setup to review, and it ends with a visible, mergeable result.
The finish line matters more than it sounds. When a new engineer can see that they shipped something on day one, however small, the fear drops. They now know the machine works and that they can drive it. A second task that is slightly bigger builds on that, and within a week they are contributing for real instead of still wondering whether their setup is even correct.
Make decisions findable, not just documented
New engineers do not just need to know how the code works. They need to know why it is that way. Why do we use this queue and not that one? Why is this old module still here? These questions have answers, but the answers live in people's heads and in chat threads from a year ago.
You cannot write down every decision before someone joins. What you can do is make the ones you have written easy to find. Link the key architecture decisions from the README. Keep a short doc of "things that look wrong but are intentional." That last one saves more time than any tutorial, because it stops a new engineer from confidently trying to fix something that is load bearing.
Set office hours that actually overlap
If your new hire is hours ahead of the team, find the window where your days touch, even if it is only ninety minutes. Protect it. That overlap is the most valuable time you have, so do not spend it on things that could have been a document.
Use the overlap for the things that genuinely need a person: unblocking, judgment calls, and the questions that have no written answer yet. Everything else, the setup, the first task, the reading, should be doable in the hours when nobody is online. Save the human time for what only a human can do.
Turn every answered question into a written answer
The first month of any onboarding produces a flood of questions. Most teams answer them in a direct message and let the answer disappear. Then the next hire asks the same thing, and someone answers it again.
Make a rule: if a question was worth asking, the answer is worth saving somewhere the next person will find it. This does two things. It slowly builds the doc you wish you had started with. And it tells the new engineer that their questions are making the place better, not just costing someone time. Over a few hires, the pile of "had to ask" shrinks toward zero.
Let them get unstuck without waiting for a person
Even with great docs, a new engineer will need something that is not written down anywhere. The specific reason a teammate structured a module the way they did. The context behind a decision that is not in any ticket. These are the questions that keep someone stuck when the team is offline.
This is where a written record earns its keep. With StandIn, each teammate writes a short brief at the end of their day, and while they are off, it answers questions from what they actually wrote down, with a source under each answer. When the answer is not in the record, it says so instead of guessing. For a new engineer alone at hour three, that is the difference between moving forward and losing the day. It does not replace your team. It just means the answers your team already gave do not go offline when your team does.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.