ADAMAS Blog
What Happens When a Key Employee Leaves Your Business
Here is what happens: the org chart looks fine for about three weeks. Then someone asks why a vendor was switched last spring, or why the pricing model has that one strange exception, or why a client gets handled differently than the playbook says, and nobody can answer. The person who could answer is gone, and they took the only copy of the reasoning with them. What looked like a personnel change turns out to be lost knowledge, and lost knowledge is expensive.
The visible cost is the one everyone plans for: recruiting, onboarding, the productivity dip while a replacement ramps up. Industry estimates put that at 50 to 200 percent of the role's annual salary. For a $70,000 operations manager, that is $35,000 to $140,000 in direct cost. Most founders know this number, or something close to it, and budget for it the way they budget for any other line item.
The cost nobody plans for is the rework. It is invisible until it isn't, and it is usually larger than the recruiting bill.
The decisions don't leave a paper trail, even when the work does
Think about how decisions actually get made in a company your size. Someone proposes an approach. There's a conversation, maybe over Slack, maybe in a meeting that nobody wrote up, maybe just in someone's head during a drive home. A direction gets chosen. Three competing options get quietly rejected. The decision becomes "how we do things," and within a month nobody remembers it was ever a decision at all. It's just how the business runs.
This is fine, as long as the person who made the call is still around to answer "why do we do it this way?" The moment they leave, that question becomes unanswerable, and unanswerable questions get answered twice. Once, originally, by the person who left. And again, six months later, by whoever inherits the problem and has no idea it was already solved.
That second pass is the rework cost. We've seen it land anywhere from $50,000 to $500,000 for companies in the $2M-$5M range, depending on how central the departing person was and how long it takes someone to notice the wheel is being reinvented. It shows up as a new hire spending three weeks redesigning a process that was already redesigned eighteen months ago, for the exact same reasons that got rejected the first time. It shows up as a client relationship that quietly sours because the new account lead doesn't know that this particular client hates being upsold, a fact that lived entirely in one departed salesperson's head. It shows up as a vendor contract that gets re-negotiated back to terms the company already proved didn't work.
None of this shows up on a balance sheet labeled "cost of employee turnover." It shows up as slow quarters, frustrated new hires, and a vague sense that the company keeps "relearning the same lessons." That phrase, by the way, is the tell. If you've heard someone on your team say it, you already have this problem, and someone has already left who hasn't been replaced by anything except a gap.
Why job descriptions and SOPs don't catch this
Most founders who think about this problem reach for the obvious fix: more documentation. Standard operating procedures, onboarding wikis, process maps. These are good things to have, and you should have them. But they solve a different problem than the one that actually hurts.
An SOP tells a new hire what to click and in what order. It does not tell them why the process has the exception it has, or what was tried before this process existed and why it didn't work, or which stakeholder will be upset if this changes and why that matters more than it looks like it should. SOPs document the current state. They are silent on the reasoning that got you there, and that reasoning is exactly what a departing employee takes with them.
An SOP records what the process is. It does not record why: which approaches were already tried and rejected, which exceptions exist and what caused them, which constraints shaped the current design. New employees inheriting a role get the process. They almost never get the reasoning, because nobody wrote it down. The previous person didn't write it down because they didn't think of their daily decisions as something worth recording. They were just doing their job.
What actually has to survive a departure
If you strip this down to what matters, three things need to survive when someone leaves, and only one of them is usually protected.
The first is the work product itself: the files, the client list, the code, the contracts. This almost always survives, because it lives in systems the company owns.
The second is the relationships: who trusts whom, who needs to be looped in on what, who the client actually wants to talk to. This partially survives, usually through frantic handoff meetings in the final two weeks, which is better than nothing but rarely complete.
The third is the reasoning: why decisions were made, what was rejected and why, what the unwritten rules are and where they came from. This almost never survives, because there was never a place for it to live. It existed only as long as the person who held it was in the room.
A decision ledger is simply a place for that third category to live, captured as decisions get made rather than reconstructed after someone gives notice. Not a wiki that someone has to remember to update on a quiet Friday. A running record, attached to the actual decisions as they happen, of what was decided, why, what alternatives were considered, and who was involved. When someone leaves, the ledger doesn't walk out the door with them, because it was never only in their head to begin with.
The 30-day plan if someone just gave notice
If you're reading this because someone on your team just resigned, here is what to do in the next two weeks, while their knowledge is still extractable.
Sit down with them and ask a different question than usual. Not "what do you do all day," but "what have you decided in the last six months that nobody else would know to revisit?" Ask about the weird exceptions. Ask what they'd be worried about if they were the one inheriting their own job. Ask which relationships are fragile and why. Write all of it down somewhere that isn't a single document buried in someone's downloads folder, because that document will be exactly as findable in a year as the knowledge in the departing person's head was.
Then do the harder thing: build the habit of capturing this in real time, for everyone, going forward. Not as a quarterly audit nobody enjoys, but as a lightweight log that sits next to where decisions already get made. The goal isn't more process. It's making sure that the next time someone walks out the door, they leave the reasoning behind, not just the result.
The verdict
A resignation letter ends an employment relationship. It does not, on its own, end the institutional memory that person was carrying, but it starts a clock on how long that memory stays accessible. Most companies let the clock run out and call the resulting confusion "growing pains." It isn't growing pains. It's an unrecorded decision, made by someone who's no longer there to explain it, being made again by someone who doesn't know it already happened.
FAQ
What is the first thing to do when a key employee resigns?
Before anything else, find out what they know that nobody else does. Sit down and have them walk through their open decisions, the reasoning behind recent calls, and the known problems in their part of the business. You have two to four weeks of access to that knowledge. After that, it is gone.
How much does it really cost when a key employee leaves?
Direct replacement costs (recruiting, onboarding, ramp time) typically run 50 to 200 percent of the role's annual salary. On top of that, the rework cost from decisions that have to be re-litigated because the reasoning left with the person commonly runs $50,000 to $500,000 for a $2M-$5M company, depending on how central that person was.
Can documentation really prevent the damage of losing a key person?
Documentation prevents the damage that comes from forgotten reasoning, not the damage that comes from losing a skilled pair of hands. A decision log will not replace someone's talent, but it will stop their successor from re-making the same mistakes and re-deciding the same questions.
What should a founder document before someone gives notice?
The decisions that were made and why, not just the processes that were followed. Process documentation tells someone what to click. Decision documentation tells them why the business does things this way, which vendors were rejected and why, and which ideas were already tried and failed.
Is this only a problem for very small companies?
It gets worse as a company grows past the founder-does-everything stage, because more people now hold pieces of institutional memory that nobody else has. A 30-person company can lose more critical context from one departure than a 3-person company, because the founder no longer personally knows everything that person knew.
Where to start
If you want a clear picture of how much undocumented decision-making is currently sitting in people's heads at your company, and what it would cost you if any one of them left tomorrow, the Clarity Audit is a short way to find out. It takes less than an hour and tells you exactly where your institutional memory is concentrated, and how exposed you are.
You can also read more about how ADAMAS works on the homepage.
Related reading: When Your Company's Knowledge Lives in One Person's Head