Getting a new starter working in your systems

A new starter arrives and spends their first week discovering what they cannot open. Each discovery costs somebody else an interruption.

By the time the access is right they have learned a set of workarounds, and workarounds outlive the problem that created them.

Have the account ready before the first day

An account created on somebody's first morning guarantees a slow day for them and a distracted one for whoever creates it.

Created the week before, with the access matching the job, it turns the first hour into work rather than administration.

Access follows the role, not the person

Access granted person by person drifts within months, because nobody unwinds a temporary permission.

Our guide to permissions covers setting them on a team so a new starter inherits the right access on day one.

Teach three things, not thirty

Every system has dozens of features and a new person needs a handful. Overwhelming them on day one means none of it lands.

The three that matter are usually where the work arrives, where it gets recorded, and where to look when something is wrong.

Let them do it, rather than watch it

A demonstration teaches recognition. Doing the task teaches the task, including the small confusions a demonstration skips.

Sitting beside somebody while they enter their first real record catches the misunderstanding immediately. Finding it in the data next month costs far more.

Their first entries deserve a look a few days later as well. A misunderstanding that produced ten records is still cheap to fix; one that produced two hundred is not.

Where the work is shared, pairing a new starter with somebody experienced for a week beats any written guide.

Notifications need setting early

A new starter receiving everything learns to ignore all of it within a week, and that habit is hard to undo.

Turning on the few events their job actually needs makes each one meaningful. Our guide to tuning notifications covers choosing them.

The first week belongs in writing

A checklist for the first week gives the fifth hire the same start as the first. Nothing then depends on who happens to be working.

It also improves each time somebody uses it, which an informal handover never does.

Check back after a fortnight

Week one questions are about where things are. Week three questions are about how the work really runs, and they are the more useful ones.

A short conversation at that point catches the habits forming, while a correction still costs nothing.

Closing an account matters as much as opening one

A departing person keeps access until somebody remembers to remove it, and their work needs reassigning to a person rather than left assigned to nobody.

The same checklist that opens an account should close it, on the last day rather than the following month.

A departing person's records also need a home. Jobs, tasks and matters assigned to them become invisible the moment the account closes, and nobody notices until something is late.

Reassigning that work on the last day, rather than discovering it a fortnight later, is the difference between a handover and a gap.

A new person finds the problems nobody else sees

Somebody learning a system meets every confusing label and missing instruction with fresh eyes.

Asking at the end of the first fortnight what made no sense produces a better list of fixes than any internal review.

What to change first

• The account exists the week before somebody starts
• Access comes from the team, so the role carries it
• Three things get taught, not thirty
• The new starter enters the first real record themselves
• Only the notifications their job needs arrive
• One checklist covers the first week and the last day