The New Employee Test

I use this thought experiment with almost every business owner I work with.

Imagine someone new starts working for you on Monday. They're capable and they want to do a good job. But they know nothing about how your business actually runs. They just show up ready to work.

How long before they can actually do the job without asking questions?

The holdup won't be them. It'll be that the information they need isn't written down anywhere. It lives in someone else's head.

That's the New Employee Test. And most small businesses, when they honestly think it through, don't pass it.

What the Test Is Really Measuring

The test sounds like it's about onboarding, but what it actually finds is process gaps.

Every question your imaginary new hire would have to ask is a piece of knowledge that exists only in someone's memory. Every "we just do it this way" they'd run into is a decision somebody made years ago and never wrote down.

These gaps accumulate silently. A small business runs on the knowledge of the people in it, and as long as those people stay, things work. The process gaps are invisible because the people who fill them are always there. Nobody notices the workarounds until the workaround walks out the door.

In a lot of small offices, one person holds a whole workflow in their head: which clients get which updates, on what schedule, with which attachments. If that person leaves, nobody else knows any of it, and clients notice before the owner does.

The New Employee Test is a way to see those gaps before that happens.

How to Actually Run It

You don't need to hire anyone. You just need an hour and a willingness to be honest about what you find.

Pick one core process. Start with something that happens regularly and matters to the business: client onboarding, invoicing, project handoffs, weekly reporting. Don't try to map everything at once. One process, done thoroughly, is worth more than a shallow pass at ten.

Write down every step as if explaining it to someone who has never seen it before. Not what's supposed to happen; what actually happens. Include the unofficial steps, the things people "just know" to do, the checks that happen informally. If someone makes a call to confirm something before moving forward, that's a step. If a file gets saved in a specific place that isn't obvious, that's a step.

Identify every place where knowledge is required that isn't captured in the document. These are your gaps. They show up as vague phrases like "reach out to the client" (which client? how? using what template?), or steps that reference knowing where something is without explaining where it is, or decisions that depend on context that isn't explained anywhere.

Have someone else try to follow it without asking questions. This is the real test. Give your written process to a team member who doesn't usually do this task and ask them to work through it. Every time they get stuck or have to ask a question, you've found a gap. Update the document. Test again. Two rounds of this usually produce something a genuine new hire could follow.

What You'll Find

Most business owners who run this are surprised by how ordinary the gaps are. They're so normal that nobody thought to question them.

You'll find tasks that depend on calling a specific person, with no record of who that is or why they're the right contact. You'll find files that live somewhere logical to whoever set things up and nowhere obvious to anyone else, and decisions that depend on context nobody wrote down because everyone on the team already knows it.

You'll also find redundancy: steps that exist because someone added them as a workaround years ago and nobody ever removed them, because the workaround became part of the process before anyone noticed.

And occasionally, you'll find something more significant: a critical task that only one person on the team knows how to do at all. Usually nobody's hoarding anything; it just never got taught to anyone else. That's your riskiest gap, and it's worth fixing first.

What to Do with What You Find

Once you've identified the gaps, the fix is straightforward, if not always fast.

Close the knowledge gaps by adding the missing information to the document. Who to call, where the file lives, what the decision criteria are. If a step requires judgment that's hard to write down, add examples: "In situations like X, we typically do Y. In situations like Z, we do W instead." Concrete examples are more useful than abstract guidelines.

Address single points of failure directly. If only one person knows how to do something critical, the priority is getting that knowledge out of their head and into a form that someone else can learn from. Nobody's being replaced here. The point is that one good employee shouldn't be the only thing standing between the business and a crisis.

Eliminate the redundancies you find. If a step exists because of a problem that was solved two years ago, remove it. Processes that aren't maintained accumulate steps over time, and those steps cost time, even when they're no longer serving any purpose.

Make the documentation findable. A process document that nobody can locate is only marginally better than no documentation at all. Put it somewhere the team already looks: your shared drive, your project management tool, your internal wiki. The test for whether it's in the right place is simple: if someone needed this at 8am on a Monday, would they know where to find it without asking?

Why This Matters Beyond Documentation

Documenting processes is usually framed as a risk management exercise, and it is. But it's also the first step toward improving those processes.

When a process only exists in someone's memory, you can't evaluate it. You can't see whether it's efficient, whether steps are in the right order, or whether parts of it could be handled differently. Once it's written down, you can look at it objectively and ask: is this actually the best way to do this?

That's where most of the time savings I find with clients come from: looking at a written-out process and noticing that three of the twelve steps are redundant, or that steps four and five could be combined, or that step seven is only there because of a problem that no longer exists.

Most owners find at least one real gap on the first pass, and it's usually costing them time every week. Closing it rarely takes new software. It takes writing down what everyone already knows.

Start with one process. Give yourself an hour. See what you find.

If the process that fails the test is one only you know how to do, Only You Know How To Do It is where I write it down with you and watch someone else run it.