How to Capture Tribal Knowledge (Without Writing SOPs Nobody Uses)

A lab that makes quality-control samples for clinical testing had lived with the same strange problem for somewhere between ten and twenty-five years.

A value on their product, a benchmark their customers rely on, kept coming back different depending on who was measuring it. Some customers measured it and got one number while the lab measured the same sample and got another. Not every customer, just some. The team knew it happened, and had known for a long time. What they had never really known was why.

So they did what most teams do with a problem they cannot explain. They guessed and checked. Someone on the floor had built up an instinct for it over the years, a sense of which customers ran “different,” and the company leaned on that instinct every time it came up. When a new product was being designed for a first-time customer, they would build it to their own target, ship it, and sometimes find out the customer’s instrument read it “wrong.” Then they would remake the product and work backward to figure out the number that customer actually needed.

That is tribal knowledge. Not a missing document; A working understanding that lived in one person’s head and got applied, imperfectly, whenever the situation came up.

Here is the part worth sitting with. In a single guided conversation, the why finally surfaced. It turned out some customers’ instruments do not measure that value directly at all. They measure a related property and calculate the benchmark from it, and because of how the lab formulates the product, that calculation lands somewhere different. Ten to twenty-five years of “we just have to guess and check,” answered in one sitting. One of the people in the room actually said it out loud: “We’ve always known it’s different for some customers. But this answers why. We’ve never known why.”

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

Everybody says capture tribal knowledge. Nobody tells you how.

If you have spent any time around operations, you already know the importance of documenting your processes and capturing tribal knowledge. People talk about it relentlessly. Capture it before it walks out the door. Get it out of people’s heads. Write the SOP.

None of that is wrong. It is just aimed at the wrong part of the problem.

The hard part was never the document. The hard part is getting the knowledge out of the person in the first place. That is the gap nobody talks about when they tell you how to capture tribal knowledge, and it is the reason most documentation efforts quietly fail. Everyone treats the writing as the work and the capture as a given. In reality it is the other way around.

Why your best people can’t hand you what they know

I was in a kickoff once where someone on the team pushed back on the whole idea. Her take, more or less: doesn’t everybody just know how to go find the answer? Why do we need to capture that?

It is a fair question, and the answer is the whole point. No, and in fact she did not know how to find the answer when she first started either. She learned it over the years, she built up the judgment, the shortcuts, the sense of where to look and who to ask, until finding the answer felt like something she had always known how to do. That earned, invisible skill is exactly what makes her valuable. It is also exactly what she cannot see anymore.

This is why people gloss over the good stuff when you ask them to write it down. They are not hiding anything. The judgment calls have become automatic, so automatic that they no longer register as knowledge. Ask for the steps and you get the steps. The reasoning underneath stays buried, because to them it is just “how it works.”

I run into the same thing in my own work. I have been doing operations for almost thirty years, and I am genuinely bad at telling stories about it, not because there are none, but because there are thousands, and the details have flattened into things I just accept as true. Pull any one of them out and there is a whole lesson inside. But left to my own devices, I will skip right past it. Experience does that to everyone. The more you have, the more invisible your own knowledge becomes.

Now stack that on top of what happens when you sit someone in front of a blank screen, and you’ll get nothing that actually moves the needle. When I was building out our operations workbench, this became obvious fast in early testing. Tell someone, “We built this to capture all of your tribal knowledge,” and the very next thing out of their mouth is a question. I don’t know what to put in here. Where do I start? What am I even supposed to capture? People are great at answering questions and great at asking them. What they are not good at is staring at an empty box and reverse-engineering everything they know into it. The blank page does not pull knowledge out. It produces a thin, surface-level list that misses everything that mattered.

That is why “just write an SOP” gives you a document nobody uses. The format guarantees the shallow version, and a shallow SOP is worse than none, because now everyone assumes the knowledge is captured when it never was.

The real skill is knowing what to ask

Part of the reason I have been effective at creating process documentation over the years is not that I am a better writer. It is that I know what questions to ask and where to probe. I know how to take an answer and go one layer deeper, then another, until we hit the single point of failure or the decision that actually drives the outcome.

Most people have never had to build that skill. It is its own craft, separate from doing the work. And until recently, if you did not have someone with that skill in the room, you were stuck. You either hired an experienced facilitator to tug on the threads, or you settled for the surface version.

So the first move in capturing tribal knowledge is not “open a document.” It is to ask the kind of question that gives a person somewhere to start, and that pokes directly at the critical thinking they built up over time. I rotate through about two dozen of these but here are a handful that you can start with:

– What knowledge would be lost if you left? What about if someone else on your team left?
– What is a process that works differently than other people think it does?
– What is something you learned the hard way that could save someone else the pain?
– What is something that took you a long time to learn that you now take for granted?

Notice what these do. They do not ask for steps. They ask for the stuff underneath the steps. They hand someone a doorway instead of a blank wall. Once they answer one, the conversation has a thread, and you pull it.

Here is the part most people get wrong: there is no fixed script and no clean stopping point. Think about a five whys. Five is a guide, not a rule. Sometimes the root cause is obvious in three. Sometimes it takes seven. Capturing tribal knowledge works the same way. You keep asking, guided by what you are actually trying to surface, until the threads in the conversation tell you that you have gone deep enough. The goal is not to fill out a form. It is to get past the symptom to the thing underneath it, the same way a good root cause analysis does.

This is the piece I designed the company brain around. Because it is an AI-guided conversation that understands the goal, the rules of engagement, and the output we are after, it can read a person’s answer and surface the next relevant question, instead of marching through a static checklist. But you do not need the tool to do this. You need to ask open-ended questions and refuse to stop at the first answer.

Capture, observe, synthesize

Getting one person to talk is the start, not the finish. The full workflow has three stages, and skipping any of them is where most efforts fall apart.

Capture. One person shares what they know from their own perspective, guided one question at a time, not dumped into a blank document. The goal here is not a polished procedure. It is an honest first-person account of how the work actually happens, judgment calls and all.

Observe. Now you add context. A single process is often run by more than one person, and each of them carries a slightly different version in their head. So you gather several captures of the same process, and they do not match. This is the good part. The places where two people describe the same job differently are exactly where your gaps live. Someone with a broader view, a facilitator or a leader, looks across those narratives and asks the obvious question out loud. “You described it this way. She described it that way. Let’s talk about the difference.” Sometimes one way is better. Sometimes both are wrong. Either way, you have surfaced something nobody had named before.

Synthesize. Take the narratives and the observations and pull them into one current-state document everyone agrees on. Not the version one person remembers. The reconciled version. That is the document that becomes usable across the whole organization, because it carries the context, not just the steps.

I will be straight with you about where this stands. We are early in testing the full loop with clients. The capture stage is where the lab story above came from, and it is the stage that changes how people think the fastest. Observe and synthesize are the next layers, and they are how a pile of individual perspectives becomes one trustworthy picture of how the work really happens. From there you have the foundation to improve it: capture ideas, agree on which are worth testing, run the test, and move from a current-state process to a future-state one with the history intact. Capture is just the door you have to walk through first, and it is the door everyone tries to skip.

You can’t predict how far the knowledge travels

Here is what makes the work worth it, and it is the part the “write your SOPs” crowd never gets to.

When you actually capture the knowledge, not just the steps, you can use it in places you never expected, and you usually cannot predict, going in, how far and wide a single piece of tribal knowledge will reach.

Go back to the lab. Once they understood why their benchmark read differently for certain customers, the immediate win was obvious. They could stop guessing. They could catch it proactively at the quoting stage, asking a new customer about their method up front and designing to the right target instead of backing into a remake. They could build a checklist moment: this is a known gap, make sure it is closed before we commit.

But the reach did not stop at operations. That same captured knowledge is something they can turn into a way to educate their customers, teaching prospects about a blind spot that exists across their whole industry. They have not done it yet. It is on the list, and they are actively building the plan. But the opportunity only exists because the knowledge got captured and made usable. Most companies, especially ones in a traditional sales cycle who are not already educating their market, would never even see that opportunity. It would stay invisible, locked in one person’s head, costing remakes, forever. A piece of tribal knowledge that had been a quiet operational headache for a decade can become a customer conversation, a marketing angle, a reason a buyer trusts you over the next vendor. You just have to get it out first.

This is also why the order matters. The framework I come back to most puts technology last on purpose: planning, then people, then process, then technology. Capturing tribal knowledge is people-and-process work. A tool only amplifies what you feed it. Skip the human part and jump to software, and you just automate the shallow version faster.

What to do Monday morning

You do not need a tool to start this. You need to start asking better questions.

Begin with the people who have been there the longest. Sit down and ask the open-ended stuff. What is something you just know? What does the rest of the team keep coming to you to figure out? What is something you know how to get around when you hit it, whether it is a customer quirk or an internal snag?

Then pull the thread. Whatever they tell you, go one layer deeper. Ask why. Ask what happens if they are not there that day. Ask who else does this and whether they do it the same way. Keep going until the conversation tells you that you have reached the bottom.

Let go of the idea that the finish line is a binder full of SOPs. It does not matter whether the result lives in SharePoint, OneDrive, Google Drive, Dropbox, or a manual on a shelf. Where it lives is not the point. Whether you captured the context that makes it usable is the point. The SOP is one output. The real prize is the understanding underneath it, the kind you can use to fix root causes, train new people, and even sharpen how you sell.

Final Thoughts

The knowledge that runs your shop already exists. It is sitting in the heads of the people who have been doing the work for years, so deep that they cannot see it anymore. The problem was never that it was not written down. The problem is that nobody ever pulled it out the right way.

Documenting processes and capturing tribal knowledge is not about the document. It is about the ingestion. Ask the right questions, in the right order, and keep pulling until the threads run out, and the knowledge comes up. Skip that part, and you end up with an outdated SOP that misses everything that mattered. The gap was never the writing. It was the asking.

That’s it for today.

See you all again next week!

Dave