The first week decides a lot. A new person either feels they have joined a team, or that they have logged in to a void. In an office, other people nearby soften the void. Remotely, nothing does. If nothing is written down and nobody has been asked to look after them, they sit at home with a laptop, wondering whether it is too early to ask a question.
At a company with no HR team, onboarding is whoever hired the person, and it competes with everything else they have to do that week. That is the honest position we are in, and probably the position of most small companies. What follows is not a description of a system we run. It is what we believe a good first week and first month look like, written down so we hold ourselves to it.
Before day one, three things should exist
The worst first day is the one spent waiting. Waiting for an account, for someone to explain what the company does, for a task. Each wait is small. Together they say: we did not prepare for you.
We think three things should be ready before the person logs in.
Accounts that already work
Email, chat, the code repositories, whatever tools the team uses. All created, all tested, all listed in one message with a sentence on what each is for. If a login fails on day one, the person's first experience of the company is a support request. That is on the company, not them.
A written overview
Not a handbook. One document, a few pages, that says what the company is, what it builds, who is on the team and what each person does, and how the week runs. It should also say what nobody will tell them otherwise: how to ask for help, what the working hours actually are, where decisions get made. A flat team without written norms is not free of norms. It has unwritten ones, which are the hardest thing for a new person to learn.
One real first task
Something that ships. Small enough to finish in the first few days, real enough that someone uses the result. Chosen in advance. More on this below, because we think it is the most important item on the list.
Pair them with one person, not with the team
A flat structure has a quiet failure mode: when everyone is responsible for the new person, nobody is. Questions go to a group channel and sit unanswered because each reader assumes another will reply.
The fix is to name one person. Not a manager, since there may not be one, but a buddy: the person whose job for the first few weeks is to be asked things. They check in every morning, answer the questions that feel too small for a channel, and are the one the new person can message without wondering whether it is a bother.
This costs the buddy real time, and that should be admitted rather than hidden. Their output will dip for a fortnight. That is the price of the new person's output existing at all, and it is a good price.
The first task should be small and shippable
There is a temptation to start a new person on something impressive. We think that is a mistake. The interesting work depends on context they do not have yet, and a task that cannot be finished in the first week teaches them only that they are slow.
A good first task can be finished, reviewed and put in front of a real user within days. To take a made-up example: fixing a wrong label on a settings page, or adding a missing validation message to a form. It is small. It is also a complete tour of how the company works: where the code lives, how a change is proposed, who reviews it, how it gets deployed. By the end the person has seen the whole path once, and everything after is a larger version of a path they already know.
It also gives them something to point at. "I shipped this" in week one does more for belonging than any welcome message.
Feedback in the first month
Nobody enjoys correcting someone who has been on the team for nine days. It feels harsh. So it gets postponed, and by the time it comes, the habit is set and the correction is bigger.
We think the first month should have more feedback than any month after it, small and frequent rather than saved up. A comment on a pull request. A sentence at the end of a call. "That was good, and next time do it this way" said the same day, not in a review a month later.
Two things make this easier. First, say early that it is coming. A buddy who says, "I will tell you when something is off, and I would like you to tell me too," has permission to do it later. Second, feedback should run both ways. A new person sees the company with fresh eyes for a few weeks and then stops. Asking them in week two what confused them is the cheapest audit of the company's habits it will ever get.
Ending the first month with a real conversation
At the end of the month, the person who hired them should sit down with them and talk honestly. What has gone well, what has not, what they want to do next. Not a form, not a rating. A conversation, with the founder or buddy having written down beforehand what they actually think, so it is not improvised.
This is also the point to check what was promised in the interview. If the role was described one way and has turned out another, better to name that at week four than at month six.
Interns and fellows are not small full-time hires
An intern or fellow arrives in a different position from a full-time hire, and treating them the same is a kindness that does not work.
A full-time hire has usually done the job somewhere before. They need context, not instruction. An intern often has not, and needs something closer to teaching. The first task should be even smaller, the check-ins more frequent, and the feedback explicit about why, not just what. "Use this pattern" is enough for an experienced engineer. For an intern, "use this pattern, because the other one breaks when the list is empty" is the whole point of them being there.
Two more differences matter. Interns and fellows have an end date, so the first week should include a plain statement of what they should have done or learnt by the end, revisited midway. And they are often more afraid of asking than a full-time hire, because they feel they have less standing. A buddy for an intern needs to ask more, not wait to be asked.
What should be the same is the respect. Real accounts, a real task, a real review. An internship built on made-up work wastes their time and the company's.
What this costs, honestly
A week like this costs a company with no HR team something it is short of: founder time and the buddy's time, in a week when the product still needs building. It is tempting to skip the document, create accounts as needed, and let the person find their own way.
We think the skipped week does not save time. It moves the cost to the new person, who spends it lost, and then back to the company, which spends three months finding out what they never learnt. Preparing well is cheaper. It just has to be paid for first.
