Getting a New Starter Working on Day One

Working on day one is a smaller list than people assume, and writing it down stops the arguments. They can log in to a machine that is theirs. They can read and send email from the right address. They can open the two or three systems their job actually needs. They can reach the shared files their team uses. They can print, if the job involves printing. And they know who to contact when something does not work.

Everything else can wait a week without anybody minding. Access to the reporting system, the second screen, the software they will need for the project starting next month. Separating the two lists is what makes the day one list achievable, because a list of everything is a list nobody finishes.

Write the short list per role rather than for the company as a whole. A warehouse supervisor and an account manager need different things on their first morning, and pretending otherwise means one of them spends the afternoon raising tickets.

Agree that list with the manager rather than deciding it inside IT. They know the new dispatch supervisor can do nothing useful until they are on the warehouse system, and that the marketing hire will not touch a finance report for a month. Ten minutes of that conversation removes most of the guesswork, and it makes the manager a party to the date rather than a complainant about it.

Some of this is same day work. Creating an account, assigning a licence, adding somebody to the right groups. If that were the whole job, hearing about a starter the day before would be fine.

The rest sets the real date. Ordering a machine and waiting for it to arrive. Building it and testing it. Buying a licence for software that is not on your usual subscription and getting the purchase approved. Getting an account created on a system a supplier administers, where the request goes into somebody else's queue. Any background or security check the role requires. A phone, if the role needs one, on a contract with its own ordering process.

Work out your own longest step and make that the lead time. For most businesses it is either hardware delivery or a supplier administered account, and both are outside your control, which is exactly why they need the notice. Then add a few days of slack, because the delivery that arrives late always arrives late in the week you cannot afford it.

Here is the actual problem, and it is rarely IT's. In most businesses IT sits at the end of somebody's mental list, so the request appears when the person appears. That is not carelessness. Recruitment is a long process with a lot of steps, and by the time the contract comes back the hard part feels finished.

The fix is a single change. The trigger is the signed acceptance, not the start date. Whoever handles recruitment sends one request the day the contract is returned, with the start date, the role, the manager, the location, and anything unusual about what the person will need. Nothing else changes about how anybody works.

Make it one short form rather than an email, because an email needs a conversation and a form does not. Keep the form short enough to fill in without thinking, which is easier than it sounds once access is defined by role.

And put a name against it. A process with no owner degrades within months, quietly, back to whatever people were doing before.

The most common instruction IT receives is to set the new person up the same as an existing member of staff. It is fast, it feels sensible, and it is how businesses end up with staff who can see three departments' worth of systems.

The person being copied has been there a long time. They covered for the finance manager one summer. They ran a project with the warehouse. They were given access to a supplier portal for a tender that finished years ago. None of that was ever removed, and now every new starter inherits all of it, and the next one inherits it from them.

The alternative is a role profile. For each job in the business, a written list of what that role gets by default and what needs approving separately. It takes an afternoon per department to write the first time. After that, a new starter request is a role name and a start date, and access reviews stop being an archaeology exercise.

Keep the profiles somewhere a manager can read, and treat a request that does not fit one as a signal. Either the role has changed and the profile needs updating, or somebody is being given something they should not have. Both are worth knowing.

Everything should be sitting ready and tested before the day. The machine built, named to your convention, updated, and logged into once by whoever built it to prove it works. The account created and left disabled until the start date, so it exists without being live. Licences assigned. The mailbox created with the correct address format, and any distribution lists or shared mailboxes added.

The physical side matters as much and is usually somebody else's job, so it gets missed. A desk. A chair. A monitor and the right cable, including the adaptor for whatever the machine actually has on it. A phone. A door pass. Somebody named to meet them at reception rather than a general assumption that somebody will.

Then test the login on the real machine, on the real network, as the real user. Not a check of the account settings. An actual login. It takes a few minutes and it catches the licence that did not apply, the group membership that has not synchronised yet, and the password policy that needs a reset the person cannot do because they are not there.

Set aside a slot with somebody present. First login, choosing a password, and enrolling whatever second factor you use, done while a human is standing there rather than remotely three days later by an anxious person reading an email on their phone.

Give them one sheet of paper. Their address, the names of the systems they will need, where to find the shared files, how to connect from home if they will, and how to raise a support request with a real address on it. A printed sheet works because it survives the moment when they cannot log in and most need the instructions.

Then leave them with one named person for the first week. Not the desk. A person on their team who has agreed to it. Most first week problems are not technical faults at all, and a colleague answers them in seconds while a ticket takes hours.

Book that first slot in advance and put a name against it. The most common way a well prepared first morning still goes wrong is that everything was ready and nobody was free between nine and ten, so the new person sits beside a sealed box while their manager walks about looking for help. It costs half an hour of somebody's diary, booked a week earlier.

Every ticket a new starter raises in their first week is a small failure of the process rather than a normal request. The shared drive nobody mentioned. The system that turned out to be essential. The software their predecessor used that nobody knew about. None of that is the new person's fault and all of it is preventable next time.

So read those tickets deliberately, and update the role profile when they point at something missing. Do it while it is fresh, because the second starter in that role arrives with the identical gap and by then everybody has forgotten.

Ask the new starter directly at the end of their first fortnight what they could not do and had to work around. They will tell you things the tickets never captured, and they will only be able to tell you once, because after a month they will have absorbed the workarounds and stopped noticing them.

The same trigger problem produces worse consequences on the way out. IT hears late, or never, and the account stays live. The mailbox keeps receiving. The licence keeps billing. The phone stays on the contract. The laptop stays at somebody's house.

Use one form for both directions, sent by the same person at the same moment in the process, which for a leaver is the resignation or the decision rather than the last day. The list is the reverse of the joiner list, with two additions: what happens to their email and files, and who takes over anything they were the only person doing.

That last one is worth a proper conversation before the notice period ends. Access is easy to revoke and knowledge is not, and the leaver is the only person who can tell you what they were quietly holding together.