Remote onboarding: our first 30 days, day by day
We got it wrong the first time. This is the plan we use now. Steal anything you like.
On this page
We hired our first remote employee two years ago and got it wrong. She spent her first week waiting for accounts and her second week wondering whether she was doing the right things. She stayed anyway, and helped us write the onboarding plan we now use for everyone.
Here it is, day by day. Steal anything you like.
Before day one
The week before someone starts, their manager does four things:
- Sends the laptop, set up, so it arrives at least two days early.
- Creates every account and tests that each one works.
- Writes a one-page "first month" note: what we hope they will have done by day 30, and who to ask about what.
- Books the first week's calls, so the calendar is full on day one and empty by day ten.
Nothing makes a new person feel less welcome than waiting three days for a password.
Week one: people and product
Day 1. A welcome call with the whole team, fifteen minutes, no presentations. Then an hour with their manager to read the first-month note together. The afternoon is free.
Day 2. They use Tally as a customer would: sign up, add tracking to a test site, build a dashboard. They write down everything that confuses them. That list is gold, and they will never see the product with fresh eyes again.
Day 3–5. One short call a day with a different teammate, about their work. Everyone else answers questions in writing.
Week two: a first real task
In week two, every new person ships something small but real. For engineers, it is usually a bug fix. For support, answering real customer emails with a colleague reading over their shoulder. For designers, improving one screen.
Small is important. The goal is not the task; the goal is to go through the whole process once, from the first question to the result in the hands of a customer, and to feel the satisfaction of having done it.
My first bug fix went out on day eight. I told my mum. She did not understand what I had done, but she was very proud.
A Tally engineer
Weeks three and four: owning something
By week three, the new person owns something: a part of the product, a set of customers, a process. They have a weekly thirty-minute call with their manager, and they write a short note every Friday about what went well and what did not.
The checklist
| When | What | Who |
|---|---|---|
| Week before | Laptop, accounts, first-month note | Manager |
| Day 1 | Welcome call, first-month note | Team, manager |
| Day 2 | Use the product as a customer | New person |
| Days 3–5 | One call a day with a teammate | Team |
| Week 2 | Ship one small real thing | New person, buddy |
| Weeks 3–4 | Own something; weekly one-to-one | Manager |
| Day 30 | Review the first-month note together | Manager |
Day 30
On day 30, the new person and their manager read the first-month note again. What happened, what did not, what surprised them. Then the new person writes one change to the onboarding plan itself. Every version of this plan since the first has been improved by the person who just went through it.
What we still find hard
Time zones. When a new person is six hours from the rest of their team, the "one call a day" plan becomes one call a day at an awkward hour. We now pair every new person with a buddy in a nearby time zone, even if they do different jobs. It helps. It is not perfect.
What new people tell us
We ask every new person the same three questions on day 30: what helped most, what was missing, and what they would tell the next person. The answers are surprisingly consistent. What helps most is the first-month note, because it answers the question "am I doing the right thing?" before anyone has to ask it. What is missing is usually a person: someone to ask silly questions without feeling silly. That is why we added the buddy.
And the advice for the next person is almost always the same: write down every confusing thing in the first week, because by week three you will not notice it any more.
