A short checklist covering access, context and a first task that is small enough to finish.
A new developer's first week sets the pattern for the months after it. When the week goes well, they finish it with a change in production and a clear idea of how your team works. When it goes badly, they finish it still waiting for a password.
Most of what decides the outcome happens before they start.
Sort out access before day one
Make a list of every system the developer will need: source control, the ticket tracker, chat, the staging environment, cloud consoles, the design files. Request all of it a few days ahead.
Then test it. Ask someone to log in as the new account and clone the repository. Access that exists on paper but fails in practice is the most common reason a first day is lost.
Give context, not a tour
A two-hour walk through every service is forgotten by lunch. A one-page note is kept and reread. It should answer four things:
- What the product does and who pays for it
- How the code is laid out, in a few sentences
- How a change gets from a laptop to production
- Who to ask about what
If the project has a README that a stranger could follow to run the app locally, you are ahead of most teams. If it does not, writing one is a good first task.
Pick a first task that can ship
Choose something small, real and low risk: a minor bug, a missing validation message, a test for an untested function. The point is not the change itself. The point is to travel the whole path once, from ticket to branch to review to release.
Avoid starting with a large feature. It delays the first review by weeks, and problems with style or approach surface late.
Agree how you will talk
Decide three things on the first day:
- Where questions go, and how quickly to expect an answer
- Which hours overlap, and what happens in them
- When the developer should stop and ask rather than keep trying
The third matters most. Remote developers often wait too long before asking, because they do not want to interrupt. Give a rule, such as asking after thirty minutes stuck.
Review the week together
On the last day, spend twenty minutes on what slowed things down. Missing documentation, a flaky test suite and unclear ownership all show up in the first week. Fixing them helps the next person who joins as well.
A good first week is mostly preparation. The developer supplies the skill. The team supplies the conditions for using it.