The short answer
Prepare three things before day one: every access they will need, an environment that runs from documented steps, and a small genuine task that touches real code without being critical. A merged change in the first few days establishes the loop everything else depends on.
The common failure is not technical. It is that nobody owned the first week, so day one goes on waiting for a VPN account and day three on working out why the local build fails.
Access, sorted before they arrive
- Source control, with the right permissions on the right repositories
- Issue tracker and whatever board the team actually uses
- Chat, and the specific channels they need rather than all of them
- Development and staging environments
- Any third-party service the local build touches
- Documentation, including the internal wiki people forget exists
Access requests that route through IT can take days. Start them a week ahead. It is the cheapest thing on this list and the most common cause of a wasted first week.
The environment has to work
If setting up locally is an afternoon of undocumented steps for your own team, it will be two days for someone new. This is worth fixing regardless of augmentation, because it is a tax on every person who joins.
- Write the setup steps down and have someone follow them exactly.
- Fix everything that does not work, including the steps people do from memory.
- Automate what can be automated, ideally to a single command.
- Include how to run tests and how to see the application working.
- Note the common failures and their fixes at the bottom.
Choose the first task carefully
| Good first task | Bad first task |
|---|---|
| Small bug with clear reproduction | Vague investigation with no obvious end |
| Touches real code, low blast radius | Critical path with a deadline |
| Has an obvious way to verify it worked | Requires product decisions nobody has made |
| Prepared in advance with context | Found on the morning they start |
| Goes through the full process end to end | Skips review because it is small |
The right column is how people end up idle in week one. The left column is prepared the week before, by whoever is hosting them.
Answer the questions before they are asked
Write a short page covering the things every new developer asks: how branches are named, what a pull request needs, who reviews, how deployment works, what the environments are, who decides product questions, and where the things that are not in the repository live.
This document takes an hour and saves that hour many times over. It also improves with each person, because each one finds something missing.
Two habits worth setting early
A short daily check-in for the first fortnight, separate from any standup. Ten minutes to surface the questions someone would not raise in a group.
And an explicit invitation to say when something is unclear or badly documented. New people see problems your team stopped noticing years ago, and that window closes after a month or two.