A first-week checklist for new joiners in software development companies

Picture a backend engineer who joins on a Monday. Her Okta login works, but the Bitbucket invite is stuck in an approval queue and the VPN profile fails on her Mac. The Dockerfile will not build. By Thursday she has read the Confluence runbook three times and committed nothing. The fault lies with the process, not with her.

This page gives a sheet you can copy, then explains who fills each line and what the blanks tell you. The sheet fits custom software houses, web agencies, app studios, product teams and test labs. For the wider picture, see the software development hub.

Joiner: ________  Squad: ________  Start date: ________  Buddy: ________
T MINUS 5 DAYS (IT admin and hiring manager)
[ ] Laptop imaged with IDE, Docker Desktop, VPN client and password manager
[ ] SSO profile, mailbox, Slack workspace and Jira seat created
[ ] Git host invite sent, CODEOWNERS entry drafted, branch protection noted
[ ] Staging sandbox login and seed data script located
[ ] First ticket chosen: a labelled starter bug with a reproduction note
DAY 1 (manager and HR)
[ ] Squad introductions at standup, working hours and core overlap explained
[ ] Client map: who pays, what the contract covers, what upsets them
[ ] Data handling note and device policy read and signed
DAYS 2 TO 3 (buddy)
[ ] Repo cloned, containers up, unit tests green on the laptop
[ ] Walk through of pre-commit hooks, lint rules and the CI pipeline
[ ] Pairing hour on the starter bug
DAY 4 (buddy and reviewer)
[ ] Pull request opened, reviewer named, Sonar findings read together
DAY 5 (manager)
[ ] Pull request merged, or review comments answered
[ ] Friction log read: slow steps, stale wiki pages, missing access
[ ] Fortnight plan written down and shared
Initials: Joiner ____  Buddy ____  Manager ____  IT ____

The hiring manager owns the sheet. IT owns the first block. The buddy owns days 2 to 4. HR owns the welcome and the signature lines. The joiner owns only the friction log, which is a plain list of anything that cost them more than twenty minutes.

1. 1

   Open the sheet a week before the start

   Send it to IT and the buddy the day the offer is accepted. Anything unticked at T minus 2 goes to the manager.

2. 2

   Keep the starter bug genuinely small

   A typo in a validation message, a missing null check or a flaky test. It should merge within the week.

3. 3

   Pair before you review

   One hour on the first build teaches more than a long wiki. The buddy sees where the joiner stumbles.

4. 4

   Show the release path

   Even a junior who is not on the pager should watch one deployment and one rollback.

5. 5

   Close with the friction log

   Read it on Friday and fix at least one item before the next joiner arrives.

• Web developers: staging URL, CMS admin seat, Figma viewer access, the design tokens file and the browser matrix the client cares about.
• Mobile developers: Apple developer team invite, Play Console role, signing key handling rules and the device shelf register.
• Enterprise product engineers: access reviewed by a security lead, a bastion host account and a read-only database role first, write access later.
• Testers: defect life cycle in Jira, test data refresh schedule, the regression suite owner and the device lab booking sheet.
• Leads: the sprint calendar, the capacity sheet, the client escalation list and one retrospective to sit through.

A tester joining a software testing company needs the defect taxonomy early. An enterprise team usually adds a slower access review, as its onboarding page describes.

• Unticked access lines mean the request was raised on the joining day instead of the week before.
• No pull request by Friday means the starter bug was too large, or the buddy was pulled onto a release.
• An empty friction log usually means the joiner is polite, not that everything worked. Ask three direct questions.
• A missing client map line means the joiner will build blind and guess what the customer values.

• Which setup step ate the most hours?
• What did the wiki claim that the laptop disproved?
• Who answered you fastest, and who was hard to find?
• Which meeting did you not need to attend?

• The buddy is also the person holding the release branch and cannot spare an hour.
• The wiki points to a sandbox that was retired two sprints ago.
• Credentials arrive by chat message instead of through the vault.
• Nobody tells the joiner whether the squad works remote on Fridays.
• The welcome mail lists forms but names no human to call.

Link the sheet to your wider employee onboarding process and to the 30-60-90 plan. Review it each quarter with the last three joiners. If you want help drafting it for your squads, share your requirements.