Week three, still no laptop, ticket escalated to the queue it came from

These are listed in the order worth acting on, which with employee onboarding is not the order they are usually presented in.

The failure is always at a handover

Onboarding requires a contract, a payroll record, an identity account, a device, access to systems and a desk, each owned by a different function. Every one of those steps usually works, and the sequence fails because no single person is responsible for the whole chain completing.

A delay in one step is invisible to the owners of the others, so nothing escalates until the new joiner complains. The new joiner is the least empowered person in the organisation and is being asked to project-manage its internal processes in week one. That is the entire problem, and it explains why more process rarely fixes it while a named owner usually does.

Identity is the dependency everything hangs from

Most access is granted against an identity record, so a delayed or misspelled identity account blocks everything downstream simultaneously. Name changes, non-standard characters and people with a single legal name reliably break systems that assumed a first and last name. Contractors, part-time staff and anyone in an unusual employment arrangement hit the same edge cases repeatedly.

Three clicks later, fixing an identity record after creation is frequently harder than creating it, because copies have already propagated to other systems. Checking the spelling of your own name in the first email you receive is a genuinely useful thirty seconds.

The cost is real and nobody measures it

A new employee unable to work is being paid to wait, and the cost compounds through the colleagues who cannot hand anything over. That cost falls across several budgets and appears in none of them, which is why it is never the trigger for a process improvement. Early experience also correlates with retention in most survey work, and replacing an employee is far more expensive than a laptop.

Organisations that measure time-to-productive-work rather than time-to-desk get noticeably different results. It is one of the clearest examples of a problem that persists because the cost is diffuse and the fix has an owner.

Access requests and the approval chain

Least-privilege access is correct security practice, and it means a new joiner requests access repeatedly rather than receiving it once. Each request needs an approver who may be on leave, and there is usually no delegation configured because nobody expected to need one. Role-based access, where a job title grants a standard bundle, solves most of this and requires somebody to define the roles.

Defining roles is unglamorous work with no launch date, which is why it is proposed regularly and completed rarely. In its absence the informal solution is to ask a colleague what they have access to, which is not an access control model.

The documentation problem

Internal documentation is written by people who already know the answer, which makes it accurate and useless to somebody who does not. It also decays, since a document is correct on the day it is written and nothing forces a review when the underlying system changes.

New joiners are the only people who can see this clearly, and they are also the least confident about saying so. Asking each new starter to fix the documentation as they use it is the single cheapest improvement available, and it works. It requires explicitly giving them permission, because otherwise nobody edits a document in their first month.

Practices change, and a company that does this today may have quietly stopped by the time you read it.

Starting a job in a broken process

Ask for a single named contact for onboarding on day one, since a named person converts a queue into a relationship. Keep your own checklist of what you are waiting for, with dates, because you are the only person who can see the whole list.

Chase in writing and in one place, as a single running thread is more effective than separate messages to separate teams. Find the informal expert in your team early, since they will solve in five minutes what a ticket takes a fortnight to route. And write down everything that confused you, because in six weeks you will no longer be able to see it and nobody else can.

Everything above, in order of what to do first

1. The failure is always at a handover. Onboarding requires a contract, a payroll record, an identity account, a device, access to systems and a desk, each owned by a different function.
2. Identity is the dependency everything hangs from. Most access is granted against an identity record, so a delayed or misspelled identity account blocks everything downstream simultaneously.
3. The cost is real and nobody measures it. A new employee unable to work is being paid to wait, and the cost compounds through the colleagues who cannot hand anything over.
4. Access requests and the approval chain. Least-privilege access is correct security practice, and it means a new joiner requests access repeatedly rather than receiving it once.
5. The documentation problem. Internal documentation is written by people who already know the answer, which makes it accurate and useless to somebody who does not.
6. Starting a job in a broken process. Ask for a single named contact for onboarding on day one, since a named person converts a queue into a relationship.

The takeaway

Get one named contact and keep your own dated list. Nobody else has it.

It is not you being fussy. It is genuinely badly made.