The Ask-Dave Problem: Employee Knowledge Discovery After the Retirement Wave

Every agency has a Dave. The person who's been there nineteen years, who knows which shared drive folder actually has the current version of the interagency agreement, who remembers why the eligibility system handles a specific edge case the way it does, who can answer in ninety seconds a question that would take a new hire three days and two wrong guesses to research. Dave retired in March. Nobody wrote any of it down.

This isn't one agency's story. It's the defining workforce fact of state and local government between 2024 and 2026: a wave of retirements and early-separation departures large enough to hollow out institutional memory across departments that were already running lean. This ebook is in two parts. The first half is about the problem itself: how knowledge loss happens, how it shows up in day-to-day operations, and what it actually costs. No product pitch in these chapters. The second half covers what a knowledge discovery approach looks like and where it fits once you've diagnosed the problem.

Chapter 1: The Retirement Wave, By the Numbers

State and local government has always skewed older than the private-sector workforce. Public pensions rewarded long tenure, and many agencies built entire operational models around staff who stayed twenty or thirty years. That model is now breaking, not gradually, but in a compressed window that's still playing out.

Three forces converged. First, the demographic bulge: a large cohort of public employees hired in the 1980s and 1990s reached traditional retirement age between 2023 and 2026. Second, several states and large counties offered early-retirement incentive programs during budget-constrained years, pulling forward departures that might otherwise have been staggered across a decade. Third, ordinary attrition, employees leaving for private-sector roles, remote work elsewhere, or simple burnout, accelerated across the same window, compounding the retirement effect rather than offsetting it.

Roughly 28% of the state and local government workforce is currently eligible for retirement within five years, according to workforce data tracked by public-sector HR associations. In some departments, IT infrastructure teams and long-tenured program administration units among them, the eligible share runs meaningfully higher. And eligibility understates the real number, because early-retirement incentives pulled departures forward well ahead of standard eligibility timelines in many jurisdictions.

Not every department felt the wave the same way. Public works, water utilities, and IT infrastructure teams skew older than almost any other function in local government, largely because these roles historically required years of on-the-job exposure to legacy systems and physical infrastructure that no certification program fully replicates. Finance and procurement offices, especially the staff who understand a jurisdiction's specific grant compliance history, were close behind. Front-line customer service roles, by contrast, saw more attrition than retirement: younger staff leaving for private-sector pay rather than long-tenured staff aging out.

Why This Wave Hit Differently Than Past Turnover

Government workforces have always had turnover. What makes 2024 to 2026 different is concentration. A department that might normally lose one senior employee every two or three years, giving the organization time to informally absorb that person's knowledge through overlap and mentorship, instead lost three or four in the same eighteen-month stretch. Overlap periods shrank or disappeared entirely, because early-retirement incentive programs were often structured to encourage employees to leave quickly rather than linger through a long transition.

A department IT director we've spoken with described losing an entire three-person team, the network administrator, the applications specialist, and the help desk lead, within a single fiscal year. Each had over fifteen years of tenure. Their replacements, hired within months of each other, had no one left who could explain why the network was configured the way it was. That's not an isolated story. It's the shape the retirement wave took in department after department: not gradual erosion, but sudden, compounding loss concentrated in the teams least equipped to document their way out of it.

Chapter 2: What Undocumented Knowledge Loss Actually Looks Like

Knowledge loss doesn't announce itself. Nobody sends an email titled 'we just lost the ability to process this correctly.' It shows up in smaller, stranger ways, and by the time leadership notices a pattern, the underlying cause left the building months earlier.

The Undocumented Exception

Every long-running government process accumulates exceptions: the specific way a particular grant program's reporting requirement gets handled, the reason a certain form has a field nobody uses anymore but nobody's allowed to remove, the workaround for a legacy system quirk that's been true since a migration a decade ago. The person who knew the exception rarely wrote it down, because it was obvious to them. It stopped being obvious the day they left.

The Buried Document

Institutional knowledge doesn't always disappear. Often it's still sitting somewhere: a shared drive, an old SharePoint site, an email thread from 2019, a binder in a filing cabinet that got scanned once and never indexed properly. The knowledge exists. Nobody remaining knows it exists, or where, or that it answers the exact question they're currently stuck on. Functionally, for the person searching, undocumented and buried-but-unfindable are the same failure.

The Relationship-Based Process

Some processes were never documented because they didn't run on documentation. They ran on a relationship: Dave calls Sandra in the other department because Dave and Sandra have worked together for fifteen years and Sandra just knows what Dave needs without him having to explain it fully. When Dave retires, the new person doesn't have Sandra's number, doesn't know to call her, and doesn't know the process ran on that call in the first place.

The Wrong Version, Confidently Cited

The most dangerous version of knowledge loss isn't the missing answer. It's the wrong answer, delivered with total confidence, because it's the only version anyone could find. A benefits eligibility policy gets revised in 2023. The revision lives in an updated PDF on a compliance officer's laptop. The 2019 version, wrong for two years and counting, sits in the shared drive folder every caseworker actually opens, because that's the folder they've always used and nobody moved the old file or marked it superseded. New staff don't know to distrust it. They cite it, sometimes to a resident, sometimes in a formal determination, and nobody catches the error until it's already caused a problem.

Chapter 3: What This Costs in New-Hire Ramp Time

The most measurable cost of knowledge loss shows up in how long it takes a new employee to become genuinely productive. Every agency has an official onboarding timeline. Most have an unofficial one that runs much longer, and the gap between the two is almost entirely attributable to how hard institutional knowledge is to find.

HR and workforce development research on public-sector onboarding consistently finds that new government employees report needing six to twelve months before feeling fully competent in role-specific processes, well beyond the formal 90-day onboarding period most agencies design around. The gap between formal onboarding and actual competence is, by most accounts from HR directors, driven less by task complexity than by the difficulty of finding out how things actually get done versus how the outdated procedure manual says they get done.

New hires in this gap period don't sit idle. They ask around, which consumes the time of the colleagues they're asking, disproportionately the most experienced and therefore most time-constrained colleagues. They search shared drives that were organized by someone who left two years ago, using a folder structure that made sense to that person and nobody else. They make a best guess, sometimes an expensive one, when the honest answer was they didn't know where to look and ran out of time to keep looking.

Duplicated Work: The Quieter Cost

Ramp time is visible in onboarding metrics. Duplicated work is not, and it may be the larger cost. When institutional knowledge isn't findable, staff recreate it. A policy memo gets rewritten from scratch because nobody could locate the 2021 version that already answered the question. A data analysis gets redone because the analyst didn't know a colleague in another division had already built the same report eighteen months earlier. Multiply this across a workforce of any real size and the aggregate hours lost to reinventing work that already existed somewhere in the organization becomes substantial, even though no single instance looks like a crisis.

Chapter 4: How to Measure What Knowledge Loss Actually Costs

Most agencies know knowledge loss is a problem the way they know traffic is bad: everyone agrees, nobody has a number. That's a problem when it's time to ask for budget. A CFO can approve funding for a defined cost. A CFO cannot approve funding for a vibe. This chapter covers how to put a number on institutional knowledge loss before you ask anyone to fix it.

Start With Time-to-Competence, Not Satisfaction Surveys

The most reliable proxy for knowledge loss is how long it takes a new employee to reach full independent competence in their role, measured against how long it took employees hired five or ten years earlier. If your onboarding records go back far enough, this comparison is usually available without collecting a single new data point. Pull the personnel files or performance review notes for employees hired in the last twelve months and for employees hired five years ago. Ask their supervisors, informally if needed, when each employee could handle their core responsibilities without regular help. The gap between those two cohorts is your baseline.

Agencies that run this comparison typically find the newer cohort takes 30% to 50% longer to reach the same competence threshold, and the gap is widest in departments that lost the most senior staff. That percentage, multiplied by the fully loaded cost of a new hire's salary during the extended ramp period, produces a real dollar figure. A department hiring six new analysts a year at a fully loaded cost of $95,000 each, with a ramp period that stretched from four months to six, is paying for roughly one extra analyst-year of reduced productivity annually. That's a budget line, not an impression.

Track Help-Desk and Tribal-Knowledge Tickets Separately

Most IT service desks already track ticket volume and category. Few separate 'system is broken' tickets from 'I don't know how to do this' tickets, and the second category is where knowledge loss shows up. A simple tagging change, flagging tickets that are really process questions rather than technical faults, gives you a running count of how often staff hit a wall because nobody could tell them what to do. Departments that started tracking this distinction found tribal-knowledge tickets made up 15% to 25% of total help-desk volume, a category that barely existed as a defined metric before someone went looking for it.

Estimate the Rework Rate

Duplicated work, discussed in Chapter 3, is harder to measure directly because nobody files a ticket titled 'I just recreated something that already existed.' The closest proxy is a simple retrospective question asked at the end of a major project: did any part of this already exist somewhere in the organization, and did we find out before or after we built it again? Ask this consistently across a dozen projects and a pattern emerges fast. One state agency that started asking this question found that four of eleven completed projects in a single quarter had partially duplicated earlier work, work that existed but wasn't discoverable when the second team started.

None of these measurements require new software or a consultant engagement. They require someone deciding to ask the question and track the answer for a quarter. The number that comes out the other end is usually uncomfortable. It's also the number that gets a knowledge-discovery initiative funded, because it turns an intuition every manager already has into a figure a budget committee can act on.

Chapter 5: Why the Old Fixes Don't Hold Up

Most agencies have tried something. Exit interviews with a knowledge-transfer component. Documentation mandates. Shadowing periods before a retirement takes effect. Wiki projects. Some of these help at the margins. None of them solve the underlying problem at the scale the 2024 to 2026 retirement wave created.

Exit Interviews Capture a Fraction of What Matters

An exit interview happens once, usually in the final week or two, and asks a departing employee to recall and articulate knowledge that, by definition, has become so automatic to them that they may not consciously register it as knowledge worth mentioning. The exceptions, the relationships, the reasons behind long-standing workarounds, these rarely surface in a structured 45-minute conversation designed primarily to close out HR paperwork.

Documentation Mandates Compete With Everything Else

Telling staff to 'document your processes' is reasonable in principle and consistently under-delivered in practice, because documentation competes for time against every deadline-driven task on a public employee's desk, and deadline-driven tasks always win. The documentation that does get written often goes into a shared drive folder that becomes exactly the kind of buried, unfindable resource described in Chapter 2, solving nothing for the next person who needs it unless they happen to already know it exists.

Wikis Require Constant Curation Nobody Has Time For

Internal wikis solve the discovery problem in theory: one searchable place for institutional knowledge. In practice, wikis decay. Pages go stale, nobody owns keeping them current, and staff learn not to trust wiki content because half of it describes a process that changed two reorganizations ago. A wiki is only as good as its maintenance discipline, and maintenance discipline is precisely the resource government teams are shortest on.

What a Better Capture Practice Actually Looks Like

None of this means capture is pointless. It means the capture practices agencies typically reach for first are the weakest ones available. A few practices consistently outperform the standard exit interview and documentation mandate, and none of them require new technology to start.

A structured knowledge-transfer period, four to eight weeks of overlap between an outgoing employee and their successor or a designated backfill, beats a one-time exit interview because it captures knowledge in context. The departing employee isn't asked to recall their job from memory in a conference room. They're asked what to do about the actual ticket, email, or decision sitting in front of them that week, and that produces detail an exit interview never surfaces. Agencies that can't guarantee overlap because a departure is sudden or a backfill takes months to hire should treat a documentation sprint, a focused one- or two-week period where the departing employee's sole task is writing down process knowledge, as the next-best option, ideally with a colleague conducting structured interviews rather than leaving the employee to self-document from a blank page.

The detail that makes or breaks a documentation sprint: ask for exceptions and workarounds specifically, not just process steps. A departing employee asked to 'document your job' will describe the textbook version. A departing employee asked 'what's the weird thing you do that isn't in any manual' will name the exact gaps that Chapter 2 describes. The second question produces the knowledge that actually goes missing.

Chapter 6: What a Knowledge Discovery Layer Actually Solves

Here's the reframe that matters. Most institutional knowledge isn't actually gone when someone retires. It's scattered: emails, SharePoint sites, shared drives, ServiceNow tickets, old project folders, PDF reports, Salesforce case notes. The person who left knew where to look. The person who's still there doesn't. The knowledge exists. The discovery problem is what's broken.

This is where Workplace Search fits. Rather than asking every employee to remember which of six systems holds the answer to a given question, a unified search layer connects across SharePoint, ServiceNow, Salesforce, shared drives, and internal knowledge bases, so an employee can type a plain-language question once and get an answer synthesized from wherever the relevant content actually lives, regardless of which departed colleague originally created it.

The practical shift for a new hire: instead of asking three colleagues and getting three different partial answers, or giving up and guessing, they search once. The answer that Dave used to provide in ninety seconds becomes something the system surfaces directly, sourced from whatever document, ticket, or memo actually contains it, whether Dave wrote it in 2019 or someone else wrote it in 2015.

Where This Fits Relative to Onboarding

Agencies that deploy unified knowledge search alongside a retirement or attrition wave typically frame it as an onboarding acceleration tool first, because that's the most measurable and most politically legible use case: new hires ramping faster because they can find institutional answers without waiting for a scarce, busy colleague to have time to explain. The duplicated-work reduction described in Chapter 3 tends to show up as a secondary benefit once the search layer has been in place long enough for tenured staff to adopt it for their own work, not just new-hire support. A university facing this exact overlap between retirements and new-hire ramp time saw a 47% drop in HR and IT help desk tickets after unifying staff search, a comparable result to what agencies report when the same approach is applied to post-retirement knowledge gaps.

What It Doesn't Solve

A knowledge discovery layer finds what already exists. It doesn't invent documentation that was never written and it can't recover a conversation that happened in a hallway and nowhere else. Agencies get the most value when they pair a search deployment with a lightweight capture practice, even something as simple as requiring key process memos to be saved to an indexed location rather than a personal drive, so that going forward, less institutional knowledge is created in a form that's undiscoverable from day one.

Chapter 7: What to Evaluate in a Knowledge Discovery Deployment

Agencies evaluating a knowledge discovery layer to address post-retirement knowledge gaps should look at capability against the specific failure modes described earlier in this ebook, not against a generic search feature list. A vendor demo built around a generic enterprise search use case will look impressive and tell you almost nothing about whether the tool handles a fifteen-year-old SharePoint site with three different folder-naming conventions layered on top of each other, which is the environment most agencies actually have.

Two questions surface most of what matters before you get to a formal RFP. Ask a prospective vendor to index a genuinely messy source, not the cleanest SharePoint site in the building, and see what comes back. Then ask how the tool handles a query phrased the way a confused new hire would actually phrase it, not the way a search-savvy IT tester would phrase it. Vendors that only perform well against curated demo content tend to struggle once real, disorganized government content hits the index.

If your agency already has a broader AI or search procurement process underway, run this same failure-mode table against it rather than starting a separate evaluation from scratch. The SLED AI search procurement checklist covers many of the same vendor questions in more depth, including questions specific to security review and contract terms that this chapter doesn't get into.

Chapter 8: Implementation Checklist

Agencies facing a retirement or attrition wave and considering a knowledge discovery deployment should work through the following steps in roughly this order.