Onboarding someone into a process, faster

The first three months, and where they go

Ask a manager how long a new person takes to become useful and the answer is months. That time goes on finding things out, not on the hard parts: which system, which screen, which field, who signs this off, what to do when the normal path does not apply.

| When | What is actually happening | |---|---| | Week one | A folder arrives. A procedure for a system version that has changed, a project deck, a spreadsheet nobody can explain. Very little is retained, because none of it is anchored to work they have done. | | Weeks two to six | They shadow, then start doing, and hit something undocumented every few hours. Each question is small. There are hundreds, and each costs two people's attention. | | Months two and three | They can do the normal case. What they still lack is the exceptions, which is exactly what nobody writes down, because to the person who knows them they are not remarkable. |

The cost is not the new person's salary. It is the senior person's attention, taken in five-minute pieces, for months.

What changes with a record

Not a better document. They can ask, and get an answer, without interrupting anyone.

| What they can do | Why it matters | |---|---| | Follow one real case end to end | The actual sequence of what happens to a thing as it moves, across departments. That is how people build a mental model. | | See only their own role's work | Sorting relevant from irrelevant is most of what takes so long. One lane is a much shorter thing to learn. | | Find the screenshot on the step | Somebody already made those. Attached to the step, they answer "which screen, which field" at the moment it is asked. | | See what is not confirmed | Marking which parts are verified tells a new person where to be careful, rather than presenting everything with equal confidence. |

The question they ask in week two, and are embarrassed to keep asking, is "walk me through what I actually do on Tuesday". No document set answers it, because the answer is assembled from six places: the process, their role, the steps they own, the systems those run on, the rules that apply, and the job aids someone made. All six exist. None is joined up.

Where to start

Do not document everything first. That is how this becomes a project that never finishes.

1. Pick the process where onboarding hurts most. Usually the one with the most exceptions.
2. Gather what already exists, including the out-of-date material. Especially that.
3. Get a draft out of it and have someone who knows the work correct it.
4. Point the next new joiner at it and note what they still have to ask.

Step four is the one people skip, and the one that tells you whether this worked.