If your operation has a person whose name gets mentioned in every important sentence about how things work, you don't have an employee. You have a single point of failure with a paycheck. The day that person quits is the day you find out how much of your business was actually in their head.
I've been on both sides of this conversation. As the person whose head held the operation, and as the consultant who walked in after that person left. Neither side is fun.
The pattern is familiar in every growing SMB. There's one person who has been there since the early days. They know how invoicing actually works, including why the three customers are billed differently from everyone else. They know which vendor to call when the shipping system goes down. They know the password to the legacy server. They know the workaround for the broken integration. They know which spreadsheet the real numbers are in. They know it all because they built it, mostly by themselves, mostly in a hurry, mostly without writing anything down.
Then they leave. Maybe they quit for another job. Maybe they retire. Maybe they get hit by a bus, which is what the tech industry calls the bus factor, which is the number of people who have to get hit by a bus before the project stops working. For most SMB operations, the bus factor is 1.
When the one leaves, the operation doesn't stop, but it slows down to the speed of figuring out what they used to do. Decisions take longer because nobody is sure how the previous decision was made. Customers wait because nobody knows the special handling. Vendors call about overdue payments because no one knew the payment was supposed to be approved before it was processed. The new person hired to replace the departed knowledge expert is competent and qualified, and they spend their first six months reverse-engineering things that should've taken an afternoon to learn.
The cost of this is real, and it's mostly invisible until it lands. SMB owners discount it because it hasn't happened to them yet. SMB owners who have been through it don't discount it.
The reason undocumented processes accumulate isn't laziness. It's that documentation feels low priority compared to the work itself. The work has a customer waiting. The documentation doesn't. So the work gets done, the documentation gets deferred, the deferral compounds, and ten years later the operation runs on tribal knowledge because nobody ever had a quarter when documentation was prioritized over delivery.
Documentation isn't the most fun work in business. It's also the difference between a business that can scale and one that can't, and between a business that survives transitions and one that doesn't. Treat it accordingly.
Identify the processes that exist in only one head. Walk through your operation department by department and ask each person what they do that nobody else knows how to do. Be honest in the asking. The point isn't to shame anyone. The point is to find the single points of failure. You're going to find more than you expected. The team has been quietly carrying knowledge for years because nobody asked them to write it down.
Document the painful ones first. Not in priority order of what's easiest. In priority order of what would cause the biggest problem if the person carrying it suddenly left. The invoicing exceptions. The vendor relationships. The customer onboarding sequence with the weird middle step. The legacy system credentials. These are the things that get a video walkthrough, a written runbook, and a second person who actually executes the process once a quarter so the knowledge stays warm.
And make documentation a part of how work gets done, not a separate project. Every time someone does something for the first time, the documentation for that thing is created or updated as part of the work. Every time someone changes a process, the doc reflects the change. Treat the documentation like code. Version it. Review it. Keep it close to the work. If documentation is a separate project that has to fight for attention, it'll lose the fight every quarter, and you'll be back where you started.
Get the knowledge out of their heads. Put it where someone else can find it. Then keep it current.
Tribal knowledge is a liability you don't see until the tribe member walks out the door. Pay it down before they do.