Every SaaS company has them. Two people, sometimes one, who hold a process together through memory and habit. They’re usually excellent, they’re usually loyal, and they’re usually the reason nobody has ever needed to write the process down.
The support lead who knows which escalations go straight to engineering. The implementation manager who remembers which enterprise account has the custom SSO setup. The ops person who’s the only one who can untangle billing when a renewal fails.
The arrangement works. That’s what makes it dangerous. A dependency that visibly fails gets fixed. A dependency that quietly works piles up for years, and the cost only becomes visible at the exact moment you can least afford it.
Running the test
It takes twenty minutes and no preparation. List your five most important workflows. For each one, name the people who’d have to be reachable for it to run normally this week. Then ask, for each workflow, what actually happens if those people are out for five working days.
You’re looking for one of four answers.
- It runs. Someone else picks it up from documentation and it proceeds at close to normal speed. Rare, and worth noticing where it’s true.
- It runs badly. It continues, more slowly, with errors that get caught later. Common, and manageable.
- It stops and nobody says so. Work queues quietly. Nothing escalates, because nobody outside the workflow knows what normal looks like. This is the answer that should concern you most.
- It stops loudly. Customers notice within days. Painful, but at least the company finds out immediately.
The third answer is the expensive one, because a process that fails silently has already been failing silently in smaller ways.
Why this isn’t a documentation problem
The obvious response is to write everything down, and companies that reach for that response usually produce a wiki nobody opens.
The reason is that the document gets written by the wrong person, at the wrong altitude, from the wrong source. Someone senior writes what the process is supposed to be, in the language of a policy manual, based on an idealized version they last ran three years ago. The result doesn’t match what actually happens, and the first person who follows it discovers that within an hour. After that, the whole category of documentation quietly gets filed under things that don’t reflect reality.
A procedure that doesn’t match the real work doesn’t just fail to help. It trains your team to ignore procedures, which is worse than never having written one.
What actually reduces the dependency
Write from observation, not from memory
Watch the work happen, on a screen share if that’s easier. Include the workarounds nobody mentions in meetings, because the workarounds are usually where the real knowledge lives. Then have the person who does the job confirm it, in their own words. Reading a procedure should feel like recognition, not instruction.
Start with one workflow, not the library
Companies that launch a complete documentation program usually stall partway and abandon the rest. Companies that document the single workflow with the most dependency packed into it finish it, and then find the second one easier. Narrow scope isn’t a lack of ambition. It’s the reason the work gets finished.
Give it an owner and a review date
Documentation decays. The product ships a release, a step changes, a customer asks for something different, and a few releases later the procedure is subtly wrong. A named owner and a scheduled review is the difference between a living document and an archive.
Test it by having someone else run it
The only real proof is a person who doesn’t normally do the work following the procedure and getting a correct result. Everything before that is a document nobody has stress-tested. This step takes an afternoon, and it’s the one most companies skip.
What this is worth beyond risk. Companies that document their core workflows discover two side effects. Ramping a new hire gets a lot faster, and the business becomes more valuable, because an acquirer or an investor pays more for an operation that doesn't depend on two specific people staying.
The version of this that trips people up
The test is usually run against illness and vacation. The scenarios that actually happen are less dramatic and more likely.
Someone moves to a four-day week. Someone is promoted to team lead and keeps doing their old job informally for a year, badly, in the gaps. Someone starts parental leave with two months’ notice, which sounds generous until you try to transfer five years of undocumented judgment inside it. Someone leaves for a competitor, and the handover is polite and thin.
None of those are emergencies. All of them expose the same gap, and the companies that handle them well are simply the ones that had already written the thing down.