The procurement code stays the same. The reasons behind every exception to it usually don’t survive the person who made them.
Every public agency has one. The buyer, the contracts administrator, or the procurement officer who’s been there twenty-plus years, who doesn’t need to look up which vendor missed a delivery window three contracts ago, or why a particular clause got added to every IT solicitation after one bad experience in 2014. None of that is written down anywhere an agency’s systems can search. It lives in one person’s memory, and it walks out the door on their last day, usually with a card and a cake and very little else in the way of a handoff.
That loss doesn’t show up on a balance sheet, which is part of why it’s so easy to underinvest in preventing it until it’s already happened.
The Retirement Nobody Plans For
Succession planning in the public sector tends to focus on the parts of a job that are already written down — the position description, the workflow steps, the policy manual. It’s much harder to plan for the parts that were never written down in the first place: which vendors are reliable under pressure, which contract terms are non-negotiable versus routinely waived, and which “exceptions” to standard process exist because of a specific incident nobody else remembers.
A new hire can be handed the procurement code on day one. They can’t be handed twenty years of pattern recognition, and most agencies don’t have a system built to capture it before it leaves.
What Actually Walks Out the Door
The knowledge that disappears is rarely dramatic, which is exactly why it’s hard to notice going missing. It’s usually some combination of:
- Vendor context that never made it into the file: which suppliers under-deliver when a project gets rushed, which ones renegotiate in good faith versus which ones need firm deadlines.
- The reasoning behind standing exceptions: why one department’s contracts route through an extra review step, or why a particular clause is now boilerplate.
- Negotiation history: what a vendor pushed back on last time, and what it took to resolve it — information that would save real time the next time the same vendor is at the table.
- Informal escalation paths: who to call, and in what order, when a contract issue needs to move faster than the standard process allows.
Individually, none of these feel urgent to document. Collectively, they’re most of what makes an experienced buyer faster and more accurate than a new one, and none of it is captured anywhere a successor can search.
Turning Tacit Knowledge into an Institutional Record
The fix isn’t asking a retiring employee to write a memoir of everything they know on their way out — that rarely works, and it puts the burden in exactly the wrong place, at exactly the wrong time. The more durable approach is capturing that context continuously, as a byproduct of the work itself, so it’s already sitting in the record by the time anyone retires.
That means treating contracts, vendor communications, and exception approvals as a searchable knowledge base rather than a filing cabinet — one where a new hire can ask “why does this clause exist” or “what happened the last time we worked with this vendor” and get an answer sourced from the actual record, instead of waiting for someone who remembers.
Building the System Before You Need It
By the time an agency notices how much institutional knowledge left with a retirement, it’s too late to get it back — the only real fix is building the system that captures it before the next one happens. That’s a shift from treating documentation as a retirement task to treating it as a standing property of how procurement records get kept in the first place: every contract, every exception, and every negotiation logged in a way the next person can actually search, not just store.
The agencies that get this right don’t do it by asking more of their most experienced people on the way out. They do it by making sure the knowledge was never dependent on one person’s memory to begin with.
Good breakdown of the shift from search to execution — that is where this actually starts changing day-to-day work.