First-week onboarding checklist for a new hire, day by day, for a remote team
An employee onboarding checklist for a remote first week: what to do before day one, a day-by-day list of accounts, policies, buddy and first ticket.
On this page
A first-week onboarding checklist for a remote hire has five parts: accounts and hardware ready before day one, a day-one call that ends with the person's first small task, a buddy who is not their manager, the policies they need to read and acknowledge spread across the week rather than dumped on Monday, and a thirty-minute check-in on Friday that asks what was confusing. Everything below fits on one page and takes the manager about three hours across the week.
We are a remote company of under fifteen people, and this is the list we run for every hire. It exists because the first version of our onboarding was a Slack welcome and a link to the handbook, and the second hire we made that way quietly spent four days waiting for access to the repository.
Why the first week decides more than you think
Gallup's research on onboarding reports that only 12% of employees strongly agree their organisation does a great job of onboarding new employees, and that when managers take an active role, new hires are 3.4 times as likely to call their onboarding exceptional. The figure is from Gallup's 2019 onboarding perspective paper, drawing on its State of the American Workplace data, and nothing we have seen since suggests small companies do better than large ones.
At a company of five to fifteen people the cost of a slow first week is concrete. The person was hired because the team is stretched; every day they are waiting on access is a day the team is still stretched and now also paying a salary. And the habits set in week one, whether they ask questions in the open or quietly wait, whether they ship something small or sit in meetings, tend to last.
Before day one
Everything on this list is done by the end of the working day before the start date. The owner is the manager unless noted.
- Signed offer letter and any agreements filed, and the start date confirmed in writing.
- Hardware shipped to arrive two working days before the start, with a tracking number sent to the person.
- Accounts created: email, chat, the workspace, the code host, the password manager. Invitations sent to the personal email for anything they need to log in to before their work email works.
- A buddy named and told. Not the manager; someone at a similar level who started in the last two years.
- The first ticket chosen: a real, small, bounded piece of work that can ship in the first week. A documentation fix, a one-screen bug, a copy change. Written up with enough context to start.
- Day-one calendar sent: a welcome call at the start of their day, a buddy call after lunch, nothing else.
- A short "who's who" page: every teammate, one line each, what to go to them for.
- Policies to acknowledge queued, with the ones that matter on day one (security, acceptable use) separated from the ones that can wait (expenses, leave).
The week, day by day
Each day lists the items and who owns them. "Done looks like" is what you check at the end of the day.
Day 1: arrive, meet, ship nothing yet
- Welcome call with the manager, 45 minutes: what the company does, what the team is working on this month, what the first week looks like, where to ask questions. (Manager)
- Log in to every account on the list; report anything that does not work in the open team channel, not by DM. (New hire)
- Acknowledge the day-one policies: security, acceptable use, confidentiality. (New hire)
- Buddy call, 30 minutes: how the team actually works, the unwritten things, where the bodies are buried. (Buddy)
- Read the who's who page and the current cycle's goal. (New hire)
Done looks like: every account works, two policies acknowledged, the person has said something in the team channel.
Day 2: the codebase, the product, the first ticket
- Walk through the product as a user for an hour; write down everything confusing. (New hire)
- Development environment running, or the equivalent for a non-engineering role. Pair with the buddy if it takes more than two hours. (New hire, Buddy)
- Read the first ticket and ask the manager questions about it. (New hire)
- Sit in on one team meeting, camera on, no obligation to speak. (New hire)
Done looks like: the environment builds, the ticket is understood, the confusing-things list exists.
Day 3: do the work
- Work on the first ticket. Ask for a review by the end of the day even if it is not finished. (New hire)
- First review, within two hours of the request, kind and specific. (Buddy or Manager)
- Acknowledge the second batch of policies: expenses, leave, equipment. Check leave balances are showing correctly. (New hire)
- Add their profile details, emergency contact and bank details for payroll. (New hire)
Done looks like: a review has happened, the HR record is complete.
Day 4: ship, and meet the rest of the company
- Address the review and ship the first ticket. (New hire)
- Fifteen-minute calls with three people outside the immediate team, picked from the who's who. (New hire)
- Read last month's company update or metrics page. (New hire)
Done looks like: something the person made is in production or published.
Day 5: check in
- Friday check-in with the manager, 30 minutes, four questions: what was confusing, what took longer than it should, what do you need that you do not have, what should we change in this checklist. (Manager)
- Write the confusing-things list into the onboarding page as suggested edits. (New hire)
- Set the first-month goals together: two or three outcomes, written down. (Manager, New hire)
- Buddy relationship continues weekly for the first month, then as needed. (Buddy)
Done looks like: the check-in notes exist, the month-one goals are written, the checklist has at least one edit from the new hire.
Owners and timing at a glance
| Item | Owner | When | Done looks like |
|---|---|---|---|
| Accounts and hardware | Manager | Day before start | Every login works on day one |
| Buddy assigned | Manager | Week before start | Buddy has a call on the day-one calendar |
| First ticket | Manager | Week before start | Written up; shippable in a week |
| Day-one policies | New hire | Day 1 | Acknowledged in the People record |
| Dev environment | New hire, buddy | Day 2 | Builds locally |
| First review | Buddy or manager | Day 3 | Review within two hours of request |
| First ship | New hire | Day 4 | In production or published |
| HR details | New hire | Day 3 | Profile, emergency contact, bank details complete |
| Friday check-in | Manager | Day 5 | Notes written; checklist edited |
| Month-one goals | Manager and new hire | Day 5 | Two or three written outcomes |
From the first week to 30, 60 and 90 days
The first week is about access, one shipped thing and a buddy. The next three months are about scope.
- By day 30: the person owns one small area, has shipped several times, and has had a second check-in. The month-one goals from day 5 are reviewed; most will have moved.
- By day 60: they have run something end to end: a feature, a client call, a hiring loop. They have given a review, not just received one.
- By day 90: they are on the on-call or support rota if the team has one, they have proposed one change to how the team works, and the manager has written a short note on whether the hire is working, shared with the person. If there is a probation period, this is when it is confirmed.
Keep the 30/60/90 goals on the same page as the first-week checklist so nobody has to find a second document.
Where the checklist lives
A checklist in the manager's head is what produced our four-day repository wait. It needs to be a page the new hire can see, with boxes the owners tick.
In Atrix, the onboarding checklist template is a page you duplicate per hire, and the self-serve items sit in the same place: the person acknowledges policies, sees leave balances, submits expenses and signs agreements in People, and can do the self-serve parts from the iPhone app (Android is in testing). Hiring an applicant through the pipeline creates the employment record the checklist attaches to. The People feature page lists what the record holds. The limits: Atrix does not provision accounts in other tools for you, and it does not send the hardware; those boxes are still ticked by a person. For the leave rules the new hire will acknowledge on day 3, the leave policy template is a starting point.
FAQ
What should be on an employee onboarding checklist?
Before day one: accounts, hardware, a buddy, a first ticket, a day-one calendar. During the week: a welcome call, policy acknowledgements split across days, the development environment, a first review and a first ship, HR details, three cross-team calls, and a Friday check-in that sets month-one goals.
How long should onboarding take?
The first week gets the person working; the first ninety days get them to full scope. A checklist that ends on Friday of week one is the first stage, not the whole thing. Review at 30, 60 and 90 days.
Who should own onboarding at a small company?
The manager owns the checklist and the check-ins. A buddy who is not the manager owns the day-to-day questions. The new hire owns their own progress through the list, which is why they need to be able to see it.
Should new hires acknowledge all policies on day one?
No. Security, acceptable use and confidentiality on day one, because they affect what the person can touch. Expenses, leave and equipment on day three, once there is context for them. Ten policies on a Monday morning are read by nobody.
What is a good first ticket for a new hire?
Real, small and bounded: a documentation fix, a one-screen bug, a copy change, a report nobody has had time to write. It should be shippable in the first week with one review, and it should matter slightly, so that shipping it feels like work rather than a test.
Does Atrix automate onboarding?
Partly. It provides the checklist template, the policy acknowledgements, leave balances, expenses and e-signed agreements on the person's record, and the hire-to-teammate step from the pipeline. It does not create accounts in other tools or ship hardware; those stay on the checklist for a person to do.
Next step
Duplicate the onboarding checklist template for your next hire and fill the "before day one" section a week out. If you are still writing the offer, our startup offer letter template covers that step, and the People feature page shows what the person's record holds once they start.
Sources
Gallup, "Why the Onboarding Experience Is Key for Retention" and Gallup, "Creating an Exceptional Onboarding Journey for New Employees" (2019 perspective paper), the source of the 12% and 3.4x figures.