What Processes Should You Actually Document?

I was on a call a few weeks ago going through a list of gaps a team had captured. Forty-some items, all real, all things somebody on the floor had raised because it slowed them down or cost them something.

Prefer listening? Check out this week’s Solo Session where I go even deeper on the topic.

About halfway through, one of the leaders stopped me and asked the question everybody in that meeting was already thinking.

“Do we really need a work instruction for every little thing that pops up? Because if we do, we’re going to have a million work instructions, and it’s still not going to cover everything.”

He was right. That’s the part most people get wrong about this conversation. He wasn’t dodging the work and he wasn’t anti-documentation. He was pointing at something real and today, I want to share my answer.

Nobody will give you a straight answer, and there’s a reason

Go looking for guidance on what processes should be documented and you’ll find two kinds of articles.

The first kind tells you that tribal knowledge is a ticking time bomb, the person who knows how to run that machine is going to retire, and you need to capture everything before it walks out the door. That’s fear-framed, it’s directionally true, and it’s almost always published by somebody selling documentation software. Their answer is always more documentation, because their answer lives inside their tool.

I’m a fan of process documentation. It exists for a reason and it solves real problems. But the advice is coming from people with a stake in the answer, and you should read it that way.

The second kind explains the difference between an SOP and a work instruction. SOP at the process level, work instruction at the task level, job aid underneath. All accurate. Also completely useless when you’re staring at forty captured gaps trying to work out which three are worth doing something about. Knowing the difference between two document types tells you nothing about whether this particular thing deserves either one.

Here’s what both miss. You cannot document your way to complete. You can write everything down, to the nth degree, and still have gaps. Still have problems your customers run into. Still have issues your team works around. The work instruction is not the finish line, and treating it like one is how companies end up with a shelf full of documents and the same problems they had before.

So the question isn’t how much to document. The question is what each gap actually needs, and documentation is only one of the answers.

Two questions that break the tie

When something lands in front of me and I have to decide whether it’s worth documenting, I run two questions.

Would this still work if you doubled the number of people doing it?

Most processes work today because of where you are right now. One person does it. She’s been doing it for six years. She knows the exceptions, she knows which customer is different, and she catches the weird ones because she’s seen them before. That’s not a process. That’s a person, and the process is standing on her.

Double the headcount and the whole thing changes. The question isn’t whether she’s good at her job. It’s whether the thing survives her.

What does it cost every time somebody gets it wrong?

Not once. Every time. What’s the exposure, internally and externally? If the impact is minor, orders keep moving, customers keep getting what they expect, then this is probably less important to document than the nine other things on the list. If a ten dollar charge gets missed on one order a year, you do not need to design a system around that.

If it touches every line item on every order for every customer, now we’re talking about real exposure and it moves to the top.

Exposure decides this. Not completeness.

The cost you’re not counting

There’s a third cost most leaders never put on the ledger, and it’s usually bigger than the one they’re worried about.

Every gray area in your operation makes somebody run a private calculation, multiple times a day. How important is this? Should I ask somebody? Should I just make the decision myself? The last time somebody just made a decision around here, they got in trouble. Was that because it cost money, or because it was the wrong call?

That burns a lot of calories.

This is basic change management showing up in the smallest possible moment. Everybody is asking “what about me.” If I get this wrong, how much risk is my job or my standing in? People are not being difficult when they hesitate. They’re protecting themselves inside a system that never told them where the line is.

Count how many times a day that happens across your team and you’ll find the real cost of leaving something undecided. It’s not the knowledge walking out the door someday. It’s the hesitation happening right now.

The reason most leaders can’t see it is that they’re the wrong person to ask. I hear “the process is obvious” constantly, and my response is always the same: obvious to who, besides you? Leadership sits a long way from the actual work. The person who knows the most about a process is the worst possible judge of what a newcomer needs to be told, because they cannot unknow what they know.

Writing it down doesn’t mean it happens

Here’s the one that changed how I think about this.

I was working with a lab products manufacturer, going through a gap their team had surfaced. Certain shipments need dry ice, and when they do, a handling charge has to make it onto the invoice. The trigger for that charge was a person hand-writing two letters on the packing slip.

Nobody in the room believed it was documented. The conclusion in the meeting was the obvious one: we should probably write this up.

Then somebody actually went and searched the work instruction. It was in there. It had been in there the whole time, in plain language, one line: if the shipment requires dry ice, write DI on the packing slip.

Documented. Trained. Still not happening consistently.

Downstream, somebody in accounting had quietly built a second process nobody designed and nobody knew about. If the letters are on the slip, he trusts it. If they’re not, he manually verifies every single order against the sales order, because he can’t tell the difference between “no dry ice” and “somebody forgot.” He’d never worked off the work instruction at all. He learned it along the way.

That’s what a documented process looks like when it depends on a person remembering something. The document did not fail because it was badly written. It failed because writing it down never addressed the actual mechanism, which was human memory on a busy shipping floor.

If it depends on somebody remembering, it isn’t a process yet. It’s a habit with paperwork.

Before you retrain anybody, ask why they missed it

Training is everybody’s fallback. Something goes wrong, somebody says it shows a gap in our internal training, and the room nods because it sounds responsible.

It’s usually wrong, and there’s a clean way to tell.

There are two reasons a person misses a step. Either they’re new and they genuinely don’t know, or the thing happens so infrequently they didn’t register it as part of the process, or they knew and forgot.

If they’re new, that’s a training issue. Train them.

If it’s infrequent, more training will not help you. That’s a system design problem. You can retrain somebody today, and if the situation doesn’t come up again for three months, I’d almost guarantee they forget again. Retraining an infrequent miss is a ritual, not a fix.

I learned that the expensive way. Years ago I was running production on chain of custody documents, the multi-part forms that connect paperwork to specimen when somebody goes in for a drug screen. Serial numbers link the forms to the vials, and those numbers deciding whether they match is what decides whether a person gets hired, or fired after an accident. Mission critical is not a strong enough phrase for it.

We batched an order of over a million documents into three runs. On the third run, the number series got duplicated. Reused from an earlier batch. Our customer caught it, not us.

So I did what everybody is trained to do. Brought the team together, ran root cause analysis, landed on operator error, retrained everyone, collected signatures on training sheets, wrote new documentation, added double-check procedures. Then I got on a call with my boss and walked him through all of it, and he asked me four words I can still hear today.

“How do you know?”

I was irritated. I’d just spent ten minutes explaining how I knew. He asked it about a hundred more times before it landed: had we tested it? Had we proven that the things we believed would prevent this actually would?

So we did. We proactively introduced the failure into production, without telling the floor, because an open book test isn’t really a test. The job ran straight through. Nobody caught it. A week after all that retraining and all those new double checks, we had reproduced the exact same problem. I wrote about the testing lesson in more detail here.

The people running the equipment were furious with me. They thought I’d tricked them. I had to stand up in a company meeting and explain that this was the good news, because the alternative was finding out from a customer again.

Operator error, operator retrained. That is where most organizations hang their hat, and it is not a resolution. It’s a note in a file that predicts the next occurrence.

What designing it out actually looks like

So what did fix it?

The real root cause was never that somebody was careless. It was that we were relying on people to visually double-check number series, and these were not one, two, three. They were fifteen-plus digit modulus numbers with letters, substitutions, and long strings of zeros. Tedious, confusing, and here’s the honest part: it didn’t matter how much time you spent on it. More care did not produce more accuracy. Looking back, we were lucky it hadn’t bitten us more often.

We built two systems.

The first tracked number series at the source. Not just the series we assigned to each production run, but the series our customers provided to us. Once both sides lived in one place, reusing a series stopped being something you had to remember not to do. It became something the system would not let you do.

The second tracked missing and duplicated numbers through production. That one’s less obvious, so it’s worth explaining. These products moved through three or four work centers before they were finished, and waste is built into that process on purpose, which means some duplication of numbers is intentional and correct. A work instruction cannot hold that distinction. So we tracked duplicates and missing numbers at every step, roll up and roll out, and put a red and green indicator on it. Miskey a number and it flags immediately: wrong digit count, wrong digits, doesn’t fit the series. We built visual management into the tool so a problem announced itself instead of waiting to be noticed by somebody who was already busy.

Then we turned that into end to end reporting for our customers, so they could see exactly what happened across a run.

Now, when people hear Planning, People, Process, Technology, what they hear in a story like this is “they built software.” We did build software. But the tool executed a process that came out of planning and people. We understood the root cause at a deep level first. We identified the limitations of the tools we already had, which was part of the problem but not the majority of it. The majority of the problem was correctly named before anybody wrote a line of code: we were relying on people to catch something people are bad at catching.

Build the tool first and you automate the wrong process faster. That’s the whole reason technology sits last.

When the root cause isn’t yours to fix

Designing it out is the ultimate answer. It’s also the one that takes the longest, between getting to root cause, building the thing, and leaving enough runway to test that it actually prevents what you think it prevents.

Sometimes it isn’t available to you at all.

That same lab manufacturer has a label printer with a software bug. Not a process problem, not a training problem. A defect in somebody else’s code. They called the vendor and got told there’s a glitch in the software, you’ll have to wait for the next update, we don’t know when that is, good luck.

That was mid-December. Nine months later there’s still no timeline. The vendor’s previous update came six years after the one before it.

So the team developed a workaround, and the workaround lives on a Post-It stuck to the laptop in the labeling room. When I asked how it was going, the operator said something that should worry anybody running an operation: these workarounds are becoming normal for us, we’ve all kind of memorized them at this point. A new hire already knows the workaround, because the person who trained him taught it to him. It’s spreading through training instead of through documents.

Her instinct about the fix was exactly right, though. She said she’d rather it not live on a Post-It that could get lost, but at the same time, it isn’t the process, so you wouldn’t want to update the work instruction for it.

That’s the correct call, and it’s worth understanding why. Changing a controlled work instruction means a document change request and an ISO process flow. Real cost, real time, for something you hope is temporary. Putting a vendor’s bug into your permanent process documentation makes a workaround look like a standard.

So you document it deliberately outside the formal system, as a temporary process, with two things attached that almost nobody attaches. A note saying what has to be true for this to go away. And a name, because somebody has to own chasing that vendor and reporting back on where the fix actually stands.

Without those two things, “temporary” is just how tribal knowledge gets born with a straight face. Nine months and no ETA is what the absence of an owner looks like.

Document the long form first, then throw most of it away

There’s an obvious objection to everything above. I’ve just spent a thousand words telling you not to document everything, and now I’m going to tell you to write the long form.

Both are true, because the long form is raw material, not necessarily the deliverable.

You cannot build a good process prompt until you’ve documented the full process. All the steps, the way it actually runs today, including the parts that only exist because of a workaround. That’s how you find the real failure points and the moments where somebody has to make a judgment call. Those failure points and decisions are what the prompt gets built from. That sequence is how we run it in the Operations Workbench too: capture the long form, then understand where it breaks, then distill.

Process prompts are a checklist done right. The reason most checklists fail is overload. People put too many items on them, so the checklist becomes a box-ticking exercise and nobody reads the items they’re checking. A prompt is short on purpose: what’s the intended output of this process, and what are the two or three things that can go wrong that somebody should be watching for.

This is also where a lot of “training issues” actually belong. Something that happens infrequently, isn’t a big risk, but you’d still rather get it right than wrong. Don’t retrain and hope they remember. Make the process be pull up this reference, and put the thing everybody forgets on that reference.

The answer nobody talks about: watch it

There’s a third option and it gets almost no airtime, because it doesn’t feel like doing something.

Watch it.

We push toward resolution to get things off our plate, and creating documentation feels like resolution. It usually isn’t. Deciding to write a document is not the same as fixing anything.

Often the honest position is that nobody in the room has enough information to decide yet. You don’t know how often this comes up. You don’t know what it costs. In that situation, the right move is to go get the data before you commit to a fix.

It also does not require buying anything. I’ve been on calls with vendors selling monitoring hardware and software, and the value is real, but the sequence is backwards. Understand the problem before you go shopping for the solution. You can put a legal pad next to the machine, or sticky notes, or a tally sheet on a clipboard, and count how often the thing happens for two weeks. It blows my mind how much grief I get for saying that out loud. It’s a short window of time to understand your exposure before you make it a standard KPI or spend money on infrastructure to measure it.

Two weeks of hash marks on a legal pad has killed more bad projects than any analysis I’ve ever run.

What to do Monday morning

Go find the high visibility, high impact things that everybody works around. A piece of software, a product line, an order type, a customer everybody handles differently. You already know what they are, because your team routes around them every day.

Pick one. Then answer four questions in order.

How often does this actually happen, and how many people touch it? If you don’t know, that’s your answer. Count it for two weeks before you do anything else.

Why did somebody miss it? New person who didn’t know is a training issue. Anything else is a system issue wearing a training costume.

What does it cost every time it goes wrong? Low exposure and infrequent, build a process prompt so the process becomes pulling up a reference. High exposure, it moves up the list.

Is the root cause mine to fix? If it is, design it out so the failure becomes impossible rather than discouraged. If it belongs to a vendor or somebody outside your walls, document the workaround outside your controlled documents, put an expiration condition on it, and give one person the job of chasing the fix.

Final Thoughts

The team that asked me whether they needed a work instruction for every little thing was asking the wrong question, and it was the wrong question in a useful way. It exposed the assumption underneath: that documenting is what you do with a problem.

Documenting is what you do to *understand* a problem. You capture current state so you can see it clearly, and then you go build a future state where the failure can’t happen. Everything gets prioritized off exposure, not off a desire to be thorough.

Stop asking what needs a work instruction. Start asking what needs to stop depending on somebody’s memory.

That’s it for today.

See you all again next week!

Dave