Why new hires ignore the training you built

A small-business owner posted in r/smallbusiness with a problem that lands for anyone who has scaled a team past about fifty people. They had built the SOPs. Recorded the videos. Written the FAQs. They made onboarding mandatory, added manager check-ins, even tried turning the whole thing into a game with points. And the new hires still walked over to ask questions that were answered, in writing, three clicks away.

The replies piled into the hundreds, and most of them circled the same uncomfortable point: the materials were fine.

People just weren’t using them.

So here’s the short version before the long one. A document is a place to store knowledge. Training is the work of changing what someone does. Those are two different jobs, and most teams nail the first while quietly assuming it covers the second. It doesn’t. The fix is a change of location: move the instruction out of the library and into the step where the work happens, so the right paragraph shows up exactly when someone needs it instead of waiting in a folder nobody opens under pressure.

Documented does not mean learned

Start with the scale of the thing. Gallup found that only 12% of employees strongly agree their organization does a great job onboarding new people. So if your new hires keep asking what the doc already covers, you’re not running a broken version of a process that works elsewhere. You’re living the default outcome that almost everyone gets.

The thing teams miss is that writing something down and teaching it to someone are not the same act, and storing it well does nothing for the second one. A new hire reads your onboarding doc once, on day two, while drinking bad coffee and trying to remember forty names. A week later they hit the actual task for the first time, and the doc is a vague memory of a page they skimmed. That gap is not laziness. It’s how human memory works, and it has been measured for over a century.

The forgetting curve, replicated in 2015 by Jaap Murre and Joeri Dros, shows how fast newly learned material fades when it isn’t used right away. Read something once and most of it is gone within days unless you act on it and keep acting on it. So the very design of most onboarding, a front-loaded week of reading and watching before the work starts, is sort of built to fail. You’re filling a bucket with a hole in the bottom, then acting surprised when it’s empty by the time the real task arrives. The reading happened. The learning didn’t stick, because nothing reinforced it at the moment it mattered.

This is the same root cause behind a lot of failing workflow automation. A team writes the process down, files it, and treats the writing as the finish line. But a document that nobody reaches for at the moment of work is a document that, functionally, doesn’t exist. It’s the same reason SOPs fail when they live in a binder: the binder is real, the knowledge is real, and the work still happens from memory and guesswork because the two never meet.

Storage was never the hard part.

Why does a documented process still fail?

Because finding the answer is more expensive than asking a person, and people are rational about effort. When a new hire hits a question, they weigh two options: dig through a wiki, three Google Drive folders, and a video they have to scrub to minute eight, or turn to the desk next to them and ask. Asking wins almost every time, because it’s faster and it comes with a human who can confirm they understood. Every one of those moments is a small vote against your documentation, and the doc loses a little authority each time, until it’s the thing nobody bothers with.

Google’s DORA research measures documentation quality on attributes like clarity, findability, and reliability, and the payoff for getting those right is large: for teams with above-average docs, the impact of continuous integration on organizational performance jumps from 34% to 750%. The two attributes that decide whether a doc gets used are findability and reliability, and they’re exactly what dies in a sprawling onboarding library. The new hire can’t find the current version, and when they do find a version, they can’t tell if it’s the current one. So they stop looking. That said, the failure here isn’t the writing quality. You can have beautifully written SOPs and still field the same five questions every Monday, because clarity on a page nobody opens is wasted clarity.

The question operations leads bring to us most often is some version of “we wrote it all down, so why does nobody follow it?” And the straight answer is that writing it down was never the part that changes behavior. The library is a reference. Reference material is for people who already know they need it and have time to go read. A new hire learning a task for the first time has neither, so the library may as well be on the moon.

And the cost isn’t just the new hire’s time. Every repeat question pulls a senior person off their own work to answer something a doc already covers. Do that across a handful of new hires and your most experienced people turn into a live FAQ, re-explaining the same five things on a loop. That’s expensive in two directions at once: the new hire stays slow, and the people who should be tackling the hard problems spend their afternoons on the basics. This interruption tax never shows up in the onboarding budget, and it’s usually bigger than the cost of building the training was in the first place.

Put the instruction where the work is

Here’s the fix, and it’s less about content than about location. Instead of a training library that describes the work, you build the work as a sequence of steps, with the guidance living inside each step. The onboarding doc stops being a page somebody reads on day two and becomes the actual path the new hire walks through on day one and day ten and day thirty. Step three doesn’t link to the explainer. Step three contains the one paragraph you’d have written in the explainer, right where the person is standing when they need it.

Picture the same step two ways. In the first, it reads “set up the customer account (see the SOP).” The new hire clicks out, lands on a 2,000-word page, scrolls for the part that applies, and either finds it or gives up and asks. In the second, the step itself says: enter the customer’s legal name exactly as it appears on the contract, choose the plan from the dropdown, paste the confirmation number into the field below. No clicking out, no scrolling, nothing to lose. The guidance and the work share one screen, so following the process and reading the process become the same motion.

That’s the difference between documentation you store and a process you can track. When the instruction lives in the step, the new hire can’t skip it, lose it, or fail to find it, because it’s the thing in front of them. They read the relevant two sentences, do the task, and move on. The forgetting curve stops mattering, because they aren’t running on a week-old memory of a video. They’re reading the exact guidance at the exact moment, every time, until it becomes second nature and they stop needing it. That’s what learning by doing actually looks like, and it’s a different shape from reading-then-remembering.

We got this backwards in Tallyfy’s early days, too. When people didn’t follow a process, our instinct was to improve the document: rewrite it, add screenshots, record a cleaner video. None of it moved the needle, because the document was never where the work happened. The fix that worked was embarrassingly simple. We stopped pointing people at a manual and started putting each instruction inside the step that needed it.

The questions didn’t drop because people suddenly got studious. They dropped because the answer was already on screen, so there was nothing to ask.

What good onboarding actually looks like

Take a concrete one: a new hire’s first week. As a library, it’s an onboarding doc, an IT-setup video, a benefits PDF, and a “who to ask about what” page, all of which the new hire is told to read and most of which they won’t. As a workflow, it’s a tracked sequence with an owner on every step. Day one is account setup, with the exact links and the security note right there in the step. Day two is the first real task, with the relevant SOP paragraph embedded, not linked. By Friday, the new hire has done the work with the guidance in front of them five times, which beats reading about it once.

The shift is small to describe and large in effect. You move the procedural content out of the page and into the run, so doing the task and reading the guidance become one action instead of two competing for the same scarce attention. This is also how you stop a team’s knowledge from walking out the door. When the work lives in workflows, a person leaving takes their habits with them but not the process, because the process was on the screen, not in their head. That’s the quiet fix for tribal knowledge: not a better wiki, but work that documents itself because the documentation is how the work gets done. It’s the same logic behind a solid new employee onboarding process and behind people-operations work generally, which is why the people operations cluster keeps circling the same theme.

One thing worth being clear about: this doesn’t kill your wiki. Reference material, the why-behind-a-policy, the org chart, all of that still belongs in a knowledge base where people read to understand. The simple test is whether someone reads a doc to decide something or follows it to do something. If they read it to decide, it’s reference, and a wiki is the right home. If they follow it to do, it’s procedure, and it should be a workflow with the steps built in.

Most teams pile both kinds into the same library and then wonder why half of it rots. The procedural half was always going to rot, because procedure decays the second it’s separated from the act it describes.

Where training and AI fit

None of this means training disappears. It means training stops being a one-time event and becomes something that happens during the work, every time, by design. The new hire still needs context, a manager, and someone to explain why a step exists. What changes is that the how-to-do-it part stops depending on memory and starts depending on the step, which never forgets and never has a busy week.

There’s an AI angle here, and it cuts the same way. Plenty of teams now want an assistant that can answer a new hire’s questions, and that’s reasonable. But an assistant reading your scattered, half-stale onboarding library inherits exactly the problem the new hire had: it can’t tell which version is current, so it answers confidently from the wrong one. Point AI at a defined process instead, one it can read through a connected Model Context Protocol server, and it has a single source of truth to draw from. The lesson is the same whether the learner is a person or a model: a process that’s written down but not used will mislead both of them. Define the work, put the guidance in the step, and the training problem mostly dissolves, because there’s nothing left to forget.

So here’s the move. Pick the one task your new hires ask about most, the question you or a manager re-answer every single week. Don’t rewrite its doc. Rebuild it as a workflow, with the answer to that recurring question sitting inside the step where it comes up. Run your next hire through it and count how many times they have to come ask. That number is the whole point, and it drops fast when the answer stops hiding in a library and starts showing up in the work.