Onboarding a remote developer: the first two weeks

A remote developer can be a regular part of your sprint after two weeks, as long as access works on day 1 and a small, real task is ready in the first week. What slows a start down is nearly always waiting, for an account or for a review that sits for days. You can fix most of that before the developer's first day.

What to prepare before day 1

Most of the work happens before the first day, and much of it is on the client side. We take care of the laptop: managed and encrypted, with a centrally managed account, SSO and two-factor authentication. Access to your own systems is something only you can grant.

Have this ready before the developer starts:

• access to the repository, with rights to push branches and open pull requests
• an account in your issue tracker and chat, plus invites to the recurring meetings
• a development or test environment with usable test data, without personal data from production
• the secrets needed to run the project locally, shared through your vault or secrets manager and not through chat
• a README that explains how to start the project locally

My advice is to have someone on your own team follow that README on a clean machine a week in advance. Whatever fails then will fail on day 1 too, and you would rather find that out yourself than have a new colleague lose a day on it.

Day 1: get it running and meet the team

Day 1 has a modest goal: by the end of it, the application runs locally and the developer has spoken with the people they will work with.

Schedule a one-hour video call with the lead on your side. Explain what the product does and what the team is working on right now. Show the architecture at a high level, ideally with a diagram that already exists. Drawing a new one for onboarding takes time, and a month later it is out of date.

Also name one person as the go-to contact for the first two weeks: someone who answers questions within a few hours and does not mind being interrupted. Serbia is on Central European Time, like the Netherlands, Germany and Belgium, so this can happen during office hours.

A first commit on day 1 is a nice bonus, and a small fix to the README is enough for it. It shows straight away whether the whole chain works, from branch to review to CI.

Week 1: one small change that goes live

In the first week, the developer ships one change to production. Pick a bug or a small feature that can be done in a few days and touches several layers of the code. Changing a label in the frontend teaches little. A new field that runs from the database to the screen shows the whole project, including migrations, tests and deployment.

Write the ticket as you would for an experienced colleague who does not know the product yet: what needs to happen, why, and how you can tell it is done. There is more on that in writing tickets a remote developer understands.

Review the first pull requests quickly, preferably the same day. A first PR that sits for three days teaches a new developer that waiting is normal here. Use the review to explain the conventions nobody wrote down. Those questions will come anyway, and they are cheaper in a PR than in production.

Bring the developer into the daily stand-up from day 2. There is little to report at first, but it is how they learn what is going on and who is working on what.

Week 2: part of the sprint

In week 2, the developer picks up regular sprint tickets, the same size as the rest of the team takes on. Let them estimate in planning too. After a few tickets you can see where things go fast and where context is still missing.

At the end of the second week, book half an hour with the developer, the lead on your side and the tech lead on ours. Talk about what is going well and what is still in the way, such as missing access or knowledge that sits with one person. That conversation lines up with the end of our two-week trial: if it does not work out, you pay nothing.

What to skip

A few habits cost more than they return in the first weeks:

• A week of reading documentation without a task. Reading sticks when you need it for something concrete.
• A large, vague first project such as "have a look at performance". There is no end point to it.
• All the knowledge in one long call on day 1. Spread it over the first week and tie it to the tasks.
• Granting access piece by piece, whenever something turns out to be missing. Each time, the work stops until someone sorts it out.

What to expect after two weeks

After two weeks, the developer has shipped a few changes and knows who to ask about what. They will not be as fast as someone who has worked on the product for a year, and they do not need to be. What you should see is tickets that get done without much back and forth, and questions that keep getting more specific.

If you do not see that, look at the first week before drawing conclusions about the developer. Was access missing, did tickets lack context, did reviews sit for days? Fix that first. You can read how we set up the rest of the collaboration under how we work.