Read summarized version with
To capture tacit knowledge, stop treating it as something mysterious and start treating it as seven specific things you can ask about: decision points, preconditions, exceptions, failure modes, ownership, definitions of done, and jargon. Get those seven down and people can follow your procedure on a bad day too, not just when everything goes right.
I’m Yuval, founder of Glitter AI. I’ve written and inherited a lot of SOPs, and the bad ones are almost never bad because a step is missing. Every step is there. The reasons aren’t.
Below is what that looks like, and how I get the missing layer out of people’s heads and onto the page.
Teach your co-workers or customers how to get stuff done – in seconds.
What tacit knowledge actually means at work
Tacit knowledge is knowledge that’s hard to articulate, as opposed to the kind that’s already conceptualized, codified, and written down. Wikipedia’s entry on the term attributes it to the philosopher Michael Polanyi and his 1958 book Personal Knowledge.
That’s the philosophy version. The workplace version is smaller, and a lot easier to fix.
At work, tacit knowledge is the stuff your expert never types because it feels too obvious to type. Nobody’s hiding it. They just don’t think of it as information; it’s how the job goes.
Explicit knowledge is the click. Tacit knowledge is why that click and not the other one, what had to be true before you clicked it, and what you do on the day it fails.
So you aren’t hunting for some hidden essence of craft. You’re asking seven questions, each answerable in a sentence, and writing the answers down.
The seven things that live in the tacit layer
Each one comes with a question that draws it out. Ask it out loud, in those words, and you’ll usually get an answer. If you wait for the expert to volunteer it, you’ll be waiting a long time.
1. Decision points
The question: “Where do you have to choose between two ways of doing this?”
A decision point is any place in the procedure where the next step depends on something. Most SOPs flatten these into a single path, because on the day it was written the expert happened to take that path.
For example: “If the customer is on an annual plan, the refund goes through finance. Monthly, you can issue it yourself.”
Every “it depends” you hear is a decision point in disguise. Push on it. What does it depend on? Write that condition as an if-then, not a vibe.
2. Preconditions
The question: “What has to be true before you start?”
Preconditions are the access, the data, and the state of the world that the procedure quietly assumes. The expert can’t see them, because the expert already has every one.
Something like: “You need admin rights in the billing console, and this only works after the invoice has actually settled, not just been marked paid.”
In my experience, this is the most common reason a new hire gets stuck on step one of an otherwise perfect document.
3. Exceptions
The question: “When does this not apply?”
Exceptions are the cases the procedure is not for. Leave them out and the SOP reads like it covers everything. So people use it where it was never meant to apply, and then trust whatever comes out.
Here’s one: “This is the standard return flow. Anything marked damaged in transit goes to the carrier claim process instead, and you never restock it.”
A nice side effect: the document gets shorter, since you no longer have to hedge inside every step.
4. Failure modes
The question: “What goes wrong most often, and what do you do then?”
My favorite, because the answer comes instantly. Ask someone who does a task every week what goes wrong and they’ll tell you in two seconds. Ask them to “document the process” and it never comes up.
Say: “About one in ten syncs times out. Wait five minutes, hit retry once, and if it fails again it’s a duplicate record, not a network problem.”
Failure modes aren’t edge cases. They’re the ordinary Tuesday your document pretends never happens.
5. Ownership and handoffs
The question: “Who owns this part, and who do you go to when it’s stuck?”
Procedures written by one person tend to assume one person does everything. Real processes cross desks. That crossing is usually where things stall.
A typical one: “You submit the request. IT provisions the account, usually same day. If it’s been more than a day, ping the IT channel, not the individual.”
Name the role, not the person, since people leave and roles stick around. Also spell out what “stuck” looks like, so the reader escalates instead of waiting politely for three days.
6. Definitions of done
The question: “How do you know it worked?”
A definition of done is the visible confirmation at the end of a step or a stage. “Click Save” isn’t it. It’s whatever you see afterwards that tells you the save actually went through.
For instance: “The record shows status Active and the audit log has a new entry with today’s date. If the status says Pending, the webhook didn’t fire.”
With this in place, a list of instructions becomes something a person can check on their own. Without it, the only feedback they get is whether someone complains later.
7. Jargon
The question: “Is there a term here a new person wouldn’t know?”
Every team invents its own vocabulary and then forgets it did. To the people using those words, they just sound like English.
Example: “A ‘soft close’ means the books are provisionally closed but still open for adjustments until the 5th.”
Don’t ask the expert for a glossary. Ask them to define the three or four terms they already used while explaining the process. Those are the ones worth defining.
Teach your co-workers or customers how to get stuff done – in seconds.
The test: can your SOP survive something going wrong?
I use a quick test. It takes maybe ten seconds a document.
Read your SOP and ask: if the reader follows this exactly and the third step returns an error, does the document help them?
Most SOPs fail. They describe the happy path, since that’s what the author had in mind while writing. The happy path is also the only version a new person can’t handle on their own.
I learned this one the expensive way at Simpo, the company I ran before Glitter. Simpo built no-code in-app walkthroughs for product managers, we’d raised $15.5M, and we were about twenty-one people split between Tel Aviv and San Francisco, with me in SF.
We had a new-hire setup checklist, and honestly it was good. Every tool, every account, every step, in order, and I’d reviewed it myself.
Then someone started, hit the account provisioning step, and got an error. Nothing in the checklist explained the error. Or who owned provisioning. Or whether to retry or escalate.
So they did what anyone would: waited a bit, then asked the person next to them, who didn’t know either and asked someone else. A full day of a new person’s first week went to a problem that one line would have prevented. Something like: “If provisioning returns an error, it’s almost always a stale license seat. Post in the IT channel, don’t retry.”
None of the steps were wrong. What was missing was the tacit layer, and that morning it was the only part that mattered.
How to audit an SOP you already have
Finding out how thin a document is doesn’t require rewriting it. Pick one existing SOP and run this pass. Budget about twenty minutes, and do it with the expert in the room or on a call, not by yourself.
- Read it end to end and mark every “it depends” you know is hiding. Anywhere the document states one path and you suspect there are two, put a mark in the margin. Those are your decision points.
- Look at step one and ask what the reader needs before step one. Access, permissions, data, timing, a prior process being finished. Write the preconditions as a short list at the top.
- Ask the expert the failure question. “What goes wrong most often here, and what do you do?” Write down the answer and what they do about it. Repeat once per stage, not once per document.
- Highlight every handoff. Anywhere the work leaves the reader’s hands, name the owning role and the escalation path. If you can’t name it, that’s a finding in itself.
- Check every step for a confirmation. If a step tells you to do something but not what you should see afterwards, add the definition of done. This is usually the biggest single batch of edits.
- Circle every word a new hire wouldn’t know. Define them at the bottom. Don’t rewrite the body to avoid the jargon, because your team actually speaks that way.
- Re-run the test. Follow it exactly, imagine the third step failing, and see whether the document still helps.
One rule: don’t make up answers. If the expert can’t tell you what happens when a step fails, mark it as something to confirm rather than writing a plausible guess. A confident wrong line is worse than a gap. Nobody ever goes back to check it.
Where each missing piece belongs in the finished document
Finding the tacit layer is half the job. The rest is placing it where the reader bumps into it at the right moment, and that’s rarely a section at the end called “Additional Notes.”
- Preconditions go at the top, before step one, as a short “before you start” list.
- Decision points go inline, at the step where the choice happens, written as if-then.
- Definitions of done go at the end of the step they belong to, in the same breath as the action.
- Failure modes go directly under the step that fails, not in a troubleshooting appendix nobody scrolls to.
- Exceptions go near the top, in scope, so the reader knows before investing ten minutes whether this document is for their situation.
- Ownership and handoffs go inline at the handoff, with the role named.
- Jargon goes in a glossary at the bottom, where it doesn’t interrupt the flow.
If your documentation lives in more than one place, this is also the moment to fix that, because a tacit layer split across a wiki, a spreadsheet, and someone’s DMs is a tacit layer nobody will find. Getting to a single source of truth is what makes the rest of this stick.
A practical note on capture. Plenty of the tacit layer gets said out loud; it just never gets typed. When people narrate a process while they record their screen, they say things like “I always check this first” and “if this errors out, that means the seat is stale” without thinking of it as documentation. Glitter records your screen and turns that narration into the written guide, so the sentences you’d otherwise lose end up in the text instead of evaporating. It won’t ask you the seven questions, though. That part’s on you, so it’s worth answering them out loud, on purpose, while the recording runs.
Why the FAQ section is the tacit layer in disguise
Open the FAQ of any SOP people actually use. Nearly every entry maps to one of the seven.
“What if the customer already has an account?” is a decision point. “Why isn’t the export working?” is a failure mode. “Who approves this?” is ownership. “What does soft close mean?” is jargon.
Which is why asking an expert for FAQs rarely works. “What are some FAQs for this process?” gets you a blank stare, because nobody stores their knowledge in that shape.
Ask instead: “What does a new person get wrong in their first week?” You’ll get five real questions in thirty seconds. Those are your FAQs, and they’re the tacit layer with a different label on it.
The glossary works the same way. Skip “give me definitions” and ask which words they just used that a newcomer wouldn’t get.
What happens when nobody captures it
I won’t put a number on this, because every study you’ll see quoted on knowledge loss is either unsourced or measuring something else. The shape of the cost, though, is easy to describe, and you’ve probably seen it firsthand.
The documentation looks fine. It passes review. Everyone assumes the process is covered.
Then the person who actually knows the process goes on vacation, changes teams, or leaves, and the first time something deviates from the happy path, the whole thing stops. Someone digs through Slack history. Someone guesses. Usually the guess is fine. Occasionally it’s expensive.
Meanwhile the expert who left was answering those questions all along, in DMs, one at a time, which is exactly why nobody noticed the document was thin. A human was serving the tacit layer live, and it looked like a working system until the day it didn’t.
More documentation probably won’t fix it. The same documents with the seven things added will get you most of the way, along with and a team where asking “why do we do it that way?” is a normal thing to say out loud rather than an admission you don’t know something. That second piece is mostly a knowledge sharing culture problem, and it’s the part no tool solves for you.
Start with one SOP: the one that would worry you most if its author quit tomorrow. Run the twenty-minute audit on it this week and see how many of the seven are missing.
My guess, from doing this to my own documents more times than I’d like to admit, is five.
Teach your co-workers or customers how to get stuff done – in seconds.
Frequently Asked Questions
What is tacit knowledge and why is it hard to document?
Tacit knowledge is knowledge that is difficult to articulate, as opposed to explicit knowledge that has already been written down. It is hard to document because the person who holds it does not experience it as information, they experience it as just how the job goes, so they never think to write it down.
How do you capture tacit knowledge from an employee?
Ask specific questions rather than asking them to write things up. Go through the process one stage at a time and ask where they have to choose between two ways, what has to be true before they start, what goes wrong most often, who owns each handoff, how they know a step worked, and which terms a new person would not know.
What is the difference between tacit and explicit knowledge?
Explicit knowledge is codified and transferable as it stands, like a written step that says which button to click. Tacit knowledge is the reasoning around that step: why this option and not the other one, what conditions had to be met first, and what to do when it fails.
What should an SOP include besides the steps?
Preconditions before step one, decision points written as if-then at the step where the choice happens, exceptions in the scope section, failure modes under the step that fails, the owning role at each handoff, a definition of done for each step, and a glossary of team jargon.
How do you document exceptions and edge cases in a procedure?
Ask the expert when the procedure does not apply, then state those cases near the top in the scope section rather than hedging inside every step. Point each exception at the process that does handle it, so the reader knows where to go instead.
What is a decision point in a process and how do you write one?
A decision point is any place where the next step depends on a condition. Write it inline at the step where the choice occurs, in if-then form, naming the condition explicitly: for example, if the customer is on an annual plan, route the refund to finance, otherwise issue it directly.
How do you write a definition of done for a task?
Describe the visible confirmation the person should see when the step succeeded, not the action they took. A good definition of done names a status, a message, a record, or a log entry the reader can check, and says what they see instead if it failed.
Why do SOPs fail when something goes wrong?
Most SOPs are written as a single happy path because that is what the author had in mind while writing. They contain the actions but not the failure modes, escalation paths, or decision points, so the moment reality deviates, the reader has nothing to fall back on.
How do you capture tacit knowledge before an employee leaves?
Prioritize the processes only they can run, and sit with them for short focused sessions per process rather than asking for a written brain dump. Walk each process stage by stage, probe for decisions, exceptions, failures and ownership, and read your understanding back to them so corrections happen while they are still there.
Can tacit knowledge be fully written down?
Not entirely. Genuine skill, judgment built over years, and pattern recognition resist being written down. But the operationally important part, the decisions, conditions, exceptions, failures, owners, confirmations and vocabulary, can be captured in ordinary sentences, and that is usually the part missing from documentation.
