A few years back, I sat in on a knowledge management kickoff at a mid-sized fintech company. The CTO opened the meeting with a confident claim: "We know where our expertise lives. It's mostly Marcus and Priya, and we've already got them scheduled for interviews next month."
Three weeks later, after actually mapping the org's critical decisions, it turned out Marcus and Priya were maybe forty percent of the picture. The other sixty percent belonged to a support engineer nobody had thought to ask, a former ops lead who'd since moved to a different team, and — this is the part that got everyone's attention — a set of judgment calls that lived in old Slack threads from a guy who'd left the company two years earlier.
Nobody had lied. Nobody had hidden anything. The organization just didn't know what it didn't know.
And that's the whole challenge with knowledge discovery. The expertise rarely lives where the leaders think it lives.
Thats why we dedicate a entire part of our knowledge management system to Knowledge discovery. We call it Discover, and its the first phase of the FutureProof5:0 Expertise Engine, the five-phase process for turning hidden expertise into something you can actually see, keep, and use.
Discover comes first because everything after it — capturing the knowledge, turning it into something reusable, putting it to work, keeping it current — depends on actually knowing where to look.
The Five Phases of the Expertise Engine
Before getting deeper into Discover, it's worth laying out the whole process, because Discover only makes sense in context.
The Expertise Engine runs in five phases. Discover is where you identify the hidden expertise in the first place — the thing this piece is about.
Capture comes next, and it's about getting that knowledge out of someone's head through structured conversations before it disappears, whether it belongs to a single executive or a team that's about to turn over.
Transform takes what's been captured and turns it into something reusable — playbooks, frameworks, decision guides — built once and usable again, whether that's one leader reusing it across a career or a company reusing it across its teams.
Activate is where that expertise actually gets used: delivered to the people, teams, or systems that need it, right when they need it.
And Evolve is the ongoing part — refining and updating what's been captured as the technology, the team, and the roles around it keep changing.
The whole thing runs at two scales at once:
An individual technology executive can run through these five phases on their own career, discovering, capturing, and packaging their own judgment into something they own.
An organization can run the same five phases across its teams, uncovering where expertise is concentrated and turning it into something the company doesn't lose every time someone leaves.
Same framework, same five steps, different outcomes.
Discover is where both versions start. If you get this phase wrong nothing that happens in the other four phases matters much, because you'll end up capturing and packaging the obvious stuff while the expertise that actually mattered stays exactly where it was: hidden.
You can't inventory what you can't see
Most companies think they've got a handle on their institutional knowledge because they know who the smart people are. Everyone can point to the senior architect, the veteran on-call engineer, the person whose name shows up on every incident channel. That's real, and it's useful. But it's also just the visible layer.
The expertise that actually puts a company at risk is usually the stuff nobody thinks to mention, because it doesn't feel like expertise to the person who has it.
It feels like common sense. It feels like "well, obviously you'd check that first." It feels like the thing you'd assume everyone knows, right up until the person who knows it leaves and three teams discover, all at once, that they didn't.
I've seen this play out with a database migration where the only person who understood a specific legacy dependency was a contractor who'd rolled off the project eighteen months prior.
Nobody flagged him during the knowledge audit because, technically, he wasn't even employed there anymore.
His name wasn't on anyone's list of "people who know things." But the workaround he'd built was still running in production, and nobody currently on staff fully understood why it worked the way it did.
That's a Discover failure. Not a documentation failure. A failure to even identify that the knowledge existed somewhere worth looking.
Discover runs at two different scales, and most people only run it at one
Everything so far has been about where the expertise organization is sitting, which is often unnoticed, across different teams. But Discover works the same way at the individual level, and it's just as easy to miss.
If you're a CIO, CTO, or CISO, you've almost certainly got some version of the Marcus-and-Priya problem inside your own career.
Not knowledge you're hiding, the knowledge you've stopped noticing, because it's become instinct. The way you can tell in the first ten minutes of a vendor call whether the roadmap they're pitching is real.
The pattern you've learned to spot that tells you a migration is going to run long before anyone else on the team sees it coming. The judgment behind a call you made years ago that you'd still make the same way today, and could probably explain in detail if someone asked, except nobody ever does.
At the organizational level, Discover means finding where valuable expertise is concentrated, and where it's exposed, across teams. At the individual level, it means something a little different: uncovering the specific experience, connections, and judgment that actually make you valuable, separate from your title, separate from the company you happen to work for right now. Most executives have never done this deliberately.
They've just accumulated it.
Where this usually goes wrong
Most attempts at knowledge discovery start in the wrong place. Someone sends around a survey asking employees to "document what you know," and the results come back thin, because most people genuinely don't think their day-to-day judgment counts as knowledge worth writing down.
The senior engineer who's been quietly preventing a class of bugs for years through habits nobody's ever asked her to explain isn't going to list that on a form. She doesn't think of it as a skill. She thinks of it as just doing her job carefully.
So the survey approach captures what people already believe is valuable, which tends to be the official, credentialed stuff — and misses almost everything that actually differentiates a good team from a mediocre one.
The better approach starts from decisions and outcomes rather than from people's self-reported expertise.
You look backward at what actually happened: incidents that got resolved faster than expected, migrations that went smoothly when they had every reason not to, technical debates that got settled without months of back-and-forth. Then you ask a different question. Not "what do you know," but "how did that go well, and who made it go well, and what did they know that made the difference." That question gets you somewhere. The first one usually doesn't.
It's not just about people who might leave
There's a version of this that gets framed purely as succession planning — find the people who might quit or retire, capture what they know before they're gone. That's part of it, but it undersells the point.
Discover isn't only about risk. Sometimes the most valuable thing you find isn't a landmine, it's a pattern that's already working and nobody's noticed it's replicable. A platform team might have quietly developed a way of running migrations that has a far better track record than anyone realizes, purely because the people doing it never stopped to ask why their approach kept working when other teams' didn't. That's not a gap to fill. That's an asset sitting in plain sight, uncatalogued.
Most organizations only go looking for expertise once something's already gone wrong — an outage that took too long to fix, a departure that left a hole nobody expected. By then you're not discovering, you're recovering, and recovering is a lot more expensive.
What good discovery actually looks like
It's slower than people expect, and less tidy. It involves talking to people who wouldn't have made anyone's first list — the person two levels down from the architect, the engineer who handles the weird edge cases nobody wants to touch, the person who left six months ago but still gets pinged with questions because everyone knows, unofficially, that she's the one who actually understands that system.
It also means asking questions that don't sound like they're about expertise at all. Not "what's your area of expertise," but "what's the thing you get asked about that nobody else seems to know the answer to." Not "document your process," but "walk me through the last time something went sideways and you fixed it — what did you notice that other people might have missed."
That second kind of question tends to surface the real stuff. The kind that isn't written down anywhere, isn't in anyone's job description, and would be genuinely hard to replace.
Why this has to come first
It's tempting to skip straight to capture — get people writing things down, recording videos, building a knowledge base. But you can't capture what you haven't found, and most organizations are sitting on a much bigger pool of critical, uncaptured judgment than they think.
Skipping Discover just means you end up documenting the obvious stuff while the real risk (or opportunity) stays exactly where it was.
If you're not sure how much of your organization's expertise is actually visible to you right now versus quietly sitting with people nobody's thought to ask, or how much of your own expertise is still tangled up in your job title instead of standing on its own, that's worth finding out before you invest in anything else.
The outcome of doing Discover well isn't a finished deliverable. It's visibility into your most valuable expertise, whether it belongs to one leader or an entire team. Everything downstream in the Expertise Engine, from capturing that knowledge to putting it to work, depends on getting this part right first.
The FutureProof5:0 Expertise Value Assessment includes a Discover section built for exactly this, a quick way to see how much of your critical expertise, individual or organizational, is genuinely accounted for, and how much is still sitting with people (or in old Slack threads, or in your own head) nobody's gotten around to asking.
Take the complimentary Expertise Value Assessment →