Your New Hire Is the Best Process Auditor You Will Get

Every operations article tells you to document your processes before you hire. It is correct and it is why the documentation never gets written, because the weeks you are short-handed enough to be hiring are the weeks nobody has a spare afternoon.

There is a version of this that works, and it costs almost nothing. It just runs in the opposite order.

Why do SOPs never get written?

Because the conditions that create the need also remove the capacity. You notice the gap when someone leaves, when a new person joins, or when you try to take a week off. All three of those are moments when the people who could write the documentation are covering extra work. So it moves to next quarter, permanently.

The other reason is that writing procedures from the inside is genuinely hard. After a few years you cannot see the steps anymore. They have compressed into one motion called "doing the job."

What makes a new hire a good process auditor?

They are the only person in the building who does not know how anything works. That is not a deficiency to be corrected as fast as possible. For a short window it is the most useful instrument you have, because everything undefined is visible to them and invisible to everyone else.

Your experienced staff cannot give you this. They stopped noticing the gaps years ago, which is what competence looks like from the inside.

How long does the window last?

About three weeks. After that they stop noticing and start coping. They learn who to ask, they build their own workarounds, and the friction becomes background. By month two they are as blind to it as everyone else, and they will not be able to reconstruct what confused them in week one.

This is why the instruction has to be given on day one. Retroactively, it does not work.

What should a new hire actually write down?

Two lists, kept separately, and the separation is the whole trick:

• Every step they had to ask about. Not the answer, just the fact that the step was not discoverable.
• Every answer that turned out to be "it depends."

Tell them it is part of the job, not a test of how quickly they are picking things up. Otherwise they will underreport to look competent, which defeats the exercise.

Why is the "it depends" list the valuable one?

The first list is your first real procedure, assembled for free by the only person qualified to assemble it. That is useful.

The second list is better, because every "it depends" marks a decision nobody has actually made. It depends on the customer. It depends on how busy we are. It depends on who is asking. Each one of those is a rule that exists only in somebody's judgment, and every one is a place where two employees will produce two different answers on the same day.

That list tells you what to fix first, which is a question most operators answer by instinct and by whichever problem shouted most recently.

Does this replace real process documentation?

No. It gives you the starting draft and, more importantly, the priority order. Documentation written top-down describes the process as leadership imagines it. This produces the version a person actually encounters, which is the version that needs fixing.

How do you start this with your next hire?

Give them a notebook on day one and the two-list instruction. Sit down with them at the end of week three, before the window closes. Expect the second list to be longer than you are comfortable with, and expect two or three items on it to be things you would have sworn were settled years ago.

Then pick the messiest line on the "it depends" list and turn it into a written rule with a name attached. That is one afternoon, and it is worth more than the manual you have been meaning to write since spring.