A remote joiner forms their opinion of your company in about six hours. If the laptop has not arrived, the email account does not exist, and the person who was supposed to call at 10:00 is in a client meeting, they have learned something true about how the organisation runs, and no amount of good intention in month two undoes it.
The good news is that a first week that works is almost entirely a logistics problem, and logistics problems are solvable with a checklist. What follows is the version that works for a small Indian software company hiring somebody who will work from Coimbatore, Madurai or Kochi and may never sit in your office.
Two things make it different from an in-office first week. Nobody will notice if the new person is quietly stuck for two days, so the plan has to create contact rather than assume it. And the tracking conversation — which in an office happens naturally when they see everyone else using the tool — has to be had deliberately, on day one, by you.
What must be ready before day one
This is the part that decides the week, and it has to be finished the week before, not on the morning itself.
Hardware, delivered and switched on
Not dispatched. Delivered, unboxed by them, powered on, and confirmed working — ideally three or four days early. Courier a laptop to Tirunelveli on the Friday before a Monday start and you have a reasonable chance of starting the week with no machine, and there is nothing you can do about it on the day.
Ask the joiner to power it on and message you when it boots. Five minutes of their time, and it converts the single biggest failure point in remote onboarding into a non-event. If you are sending a company machine, have the admin account set up and the disk encrypted before it leaves.
Every account created and tested
Email, chat, code repository, the project board, the time tracker, VPN or database access, the shared drive. Created is not enough — log into each one yourself from a clean browser and confirm it works. Roughly a third of “the account is not working” problems on day one are an invitation that was never actually sent, and finding that out yourself takes ten minutes.
Give access at the level they need in week one, not everything you might eventually grant. It is easier to add production access in month two than to explain to a client why a three-day employee had it.
A named buddy who knows they are the buddy
Not the manager. A peer, ideally one or two years ahead of them, who has been asked and has agreed. The buddy’s job is to be the person it is not embarrassing to ask a stupid question, which is a role the reporting manager structurally cannot fill.
Tell the buddy what is expected: a 20-minute call each morning for the first week, and answering messages within an hour or so. Block that time in their calendar and reduce their own commitments for the week, or you have asked somebody to do two jobs and they will do the visible one.
A first task that ships
Pick it before they join. Small, real, and genuinely deployable inside the week — a bug with a clear reproduction, a small form validation, a report column. Not a toy task, and not a documentation-reading exercise.
The reason is not productivity. It is that shipping something in week one tells a new person they are capable here, and it walks them through your entire pipeline — local setup, branch, review, merge, deploy — while somebody is watching and available to help.
The paperwork and the calendar
Offer terms, reporting line, working hours in IST, leave policy and the monitoring policy all confirmed in writing before they start. And send the day-one calendar to their personal email on the Friday, with times, links, and who each call is with. A remote joiner sitting at 09:30 wondering whether anything is going to happen is a bad start that costs nothing to prevent.
Most remote onboarding failures are not judgement failures. They are a laptop stuck in transit, a VPN credential nobody generated, and a buddy who was never told. All three are on a checklist that takes an hour to work through the week before.
Day by day
The shape below assumes a Monday start, an eight-hour day, and a joiner who will be remote permanently. Adjust the task, not the rhythm.
Monday: people, tools and the honest conversation
Do not start with the codebase. Start with people, because that is the thing remote work makes hardest and the thing that decays if left to week three.
- 09:30 — a 30-minute call with the manager. What the company does, who the clients are, what this person is for, what a good first month looks like.
- 10:00 — the tracking and monitoring conversation. Twenty minutes, today, not later. The section below covers exactly what to say.
- 11:00 — introductions, in small groups. Four short calls of fifteen minutes beat one all-hands where a new person watches twelve squares of video.
- Afternoon — log into everything, with the buddy on a call, and fix whatever does not work while somebody is there to fix it.
- 16:30 — ten minutes with the manager. Did today work? What is missing? This call is short and it is not optional.
Tuesday: the codebase and a running environment
A guided tour from the buddy: the repository layout, where the main flows live, how a request gets from the browser to the database, what is old and not to be copied. Ninety minutes, screen shared, informal.
Then the local environment, and this is where you find out whether your setup documentation is real. Sit with them for the first attempt. If it does not run by Tuesday lunch, that is your bug and not theirs, and it should be fixed in the documentation the same day so the next joiner does not hit it.
Wednesday: the first task, paired for the first hour
Hand over the pre-chosen task with a proper explanation of the context, not just a ticket link. The buddy pairs for the first hour to establish how the team works — branch naming, commit style, how much is done before opening a PR — and then leaves them to it.
Check in once in the afternoon, briefly. A new person will not tell you they are stuck on day three; they will assume they should be able to work it out.
Thursday: finish, review, respond
The pull request goes up. Whoever reviews it should do so within a couple of hours, and should review it properly — a first PR waved through teaches a new joiner that review is a formality, and a first PR torn apart teaches them something worse. Be specific, explain the why on anything stylistic, and approve when it is right.
Responding to review comments is a skill and this is where it gets set. It is also the best early signal you will get about how somebody handles being corrected.
Friday: ship it, then talk honestly
Merge and deploy, with them watching or, better, doing it. Then thirty minutes with the manager, and ask questions that invite real answers: what was confusing, what took longer than it should have, what surprised you, is there anything you expected that has not happened.
Write down what they say. A person in week one sees every rough edge in your onboarding clearly, and in three weeks they will have stopped noticing. This is the only week you get that information.
The tracking conversation, on day one
If your company uses a time tracker, activity monitoring or screenshots, the new person finds out at some point. The only question is whether they find out from you in hour two or by noticing something in week three. The second version costs you trust that is expensive to rebuild.
Have the conversation live, not by email, and cover four things:
- What is recorded. Specifically. Hours against tasks while the timer runs, activity level, idle time, screenshots at whatever interval you have configured, leave and time off. If screenshots are on, say the interval and say who can see them.
- What is not recorded. Equally specifically, because this is the part that actually settles people. Nothing when the timer is off. Not their personal phone or personal accounts. Not keystrokes or message contents. And, if it is true, that nobody is ranked against anybody else by hours logged.
- Why it exists. Name the decision it feeds. “We quote fixed-price work and we need to know what things actually take, so we bid properly and so nobody is asked to absorb a bad estimate.” A reason people can evaluate is far better received than a reason about accountability.
- Who sees it. Them, their manager, the founder. Not their colleagues. Then show them their own dashboard on the call, so the first thing they see of the tracker is their own view of their own data.
Give them the written policy the same day and ask them to acknowledge it. That is not bureaucracy for its own sake — consent and notice are what the Indian legal position broadly expects from an employer who monitors, as we covered in the post on employee monitoring law in India.
Invite the question you are dreading. “Is there anything about this that bothers you?” A person who asks on day one and gets a straight answer is settled. A person who never asks has usually decided something and not told you.
What to measure in week one without hovering
There is a real tension here. You genuinely do not know whether a remote hire is working out, and the instinct is to watch closely. Watching closely in week one produces a person who performs activity rather than doing work, and it is also the surest way to make a good hire start looking elsewhere.
Measure the things that are about the work, not about the person:
- Did the first task ship? The single most informative fact of the week. If it did not, find out why — a blocked environment and a struggling developer look identical from outside and need opposite responses.
- How long did the environment take? This measures your documentation, not them. Under half a day is healthy; two days means fix the docs.
- Did they ask questions? Silence is the worrying signal in week one, not too many questions. Somebody who asked nothing in five days is either exceptional or quietly stuck, and it is usually the second.
- Did the review comments get addressed properly? Not whether there were few. Whether the response showed they understood the point.
- Are the hours roughly normal? Seven to nine hours a day. Below four suggests they are blocked and not saying so. Eleven-hour days in week one are not commitment, they are a person who is frightened, and that is a problem to solve now.
What not to do in week one: comment on activity percentages, compare their logged hours to anybody else’s, or mention screenshots at all unless there is a genuine issue. The tracker in the first month is for you to notice a person struggling, not for you to evaluate their output.
The 30-day check
Put a 45-minute conversation in the calendar for day 30 on the joining day, so it exists before anybody needs it. It is a proper review, not a friendly catch-up, and it is the thing that catches a mis-hire while it is still recoverable for everybody.
Work through five questions honestly before the conversation:
- Has anything they wrote reached production? After a month, on a normal task load, the answer should be yes several times over.
- Do they ask questions, or go quiet? Two days of silence followed by “I was stuck on this” is a pattern to address immediately — usually it is fear rather than ability, and it is fixable if you name it.
- Is the second task faster than the first? Absolute speed in month one means very little. The rate of improvement means a great deal.
- Does review feedback repeat? The same correction three times is the strongest early warning signal there is, stronger than anything about speed.
- Would the buddy choose to work with them again? Ask privately. It is the most accurate single data point you will get, and it is rarely volunteered.
Four or five yeses and you have hired well — say so plainly, because people in month one rarely know. Two or fewer and the honest move is to say what is not working, specifically, with a clear thirty-day expectation. Most people who hear that in month one either fix it or leave on their own terms, and both are better outcomes than the version where nobody says anything until month six.
The reason to do this at thirty days rather than ninety is kindness as much as commercial sense. A person who is failing usually knows, and being left to discover it slowly over a quarter is worse for them than a direct conversation while there is still time to act.
What to do on Monday morning
- Write the pre-arrival checklist down as an actual list and put it somewhere the next hiring manager will find it.
- For anyone joining in the next month, confirm today that the laptop is ordered and will arrive a week early.
- Choose the first task now, for the next joiner, and write one paragraph of context against it.
- Ask one person to be the buddy, explicitly, and reduce their week’s commitments by the hours it will take.
- Write the monitoring policy in one page of plain language, if it does not exist, and make it a day-one document.
- Put the day-30 review in the calendar on the day the offer is accepted, not on the day you remember.
And if you have somebody who joined remotely in the last six months, ask them this week what their first week was actually like. You will get a more useful answer than any checklist, including this one, and it will be specific to your company.
