Every engineering org has a Dave.
Dave's been there nine years. Dave remembers why the payments service still calls that deprecated internal API — something about a Q3 outage in 2021 and a vendor that didn't honor a contract. Dave knows which "temporary" workaround in the auth layer is actually load-bearing. Dave is the reason the last platform migration didn't quietly break three downstream teams.
When someone asks a hard architecture question in Slack, the answer is usually the same: "ask Dave."
We say this like it's a compliment. It isn't. It's a risk disclosure.
What technical teams have traditionally called "tribal knowledge" is really an undocumented single point of failure
Technical leaders talk about tribal knowledge with a kind of affection — as if it's a sign of a mature, battle-tested team. And in one sense, it is: that knowledge is real, it's earned, and it's usually more accurate than anything in the wiki. The problem was never that the knowledge exists. The problem is where it lives.
If it only lives in Dave's head, you don't have institutional knowledge. You have a countdown timer. Dave gets promoted, gets recruited, gets tired, gets sick, retires, or just goes on a two-week vacation during an incident — and the organization discovers, in real time, exactly how much it didn't actually know about its own systems.
This shows up everywhere in technical organizations, not just architecture:
- Incident response: The post-mortem captures what happened, but not why an experienced engineer chose rollback over a hotfix.
- Build vs. buy: Three years later, nobody remembers why the original decision was made, so the organization debates it all over again.
- Platform migrations: Edge-case decisions survive in the architecture, but the reasoning behind them disappears.
- Engineering standards: Hard-won lessons eventually look like arbitrary bureaucracy because nobody remembers the failure that created the rule.
You can't document your way out of this
Most organizations respond to knowledge risk by asking people to document more. Write the SOP. Update Confluence. Record the handoff. Complete the post-mortem.
Useful? Yes. Enough? No.
Because documentation captures what. Expertise capture gets to why:
- Why did you make that decision?
- What alternatives did you reject?
- What did experience tell you that the data couldn't?
- What signals were you watching?
- What would cause you to make a different decision next time?
That's the knowledge organizations can't afford to lose — and it's the part that never makes it into Confluence, no matter how thorough the SOP is.
The real risk isn't losing Dave. It's not knowing what you'd lose.
Most technical leaders can name their Daves. Far fewer can actually answer the harder question: if Dave left tomorrow, what specifically would you lose, and how would you know you'd lost it?
That's not a rhetorical question. It's usually the first place this breaks down — not in capturing expertise, but in discovering it in the first place. You can't extract what you haven't identified. Most organizations don't have a real inventory of where their critical judgment actually sits; they have an org chart and a set of assumptions.
There's another side to the problem
The organization isn't the only one losing value.
If you're the Dave — the technology executive whose judgment sits behind years of architecture decisions, transformations, incidents, and hard-earned lessons — much of your most valuable expertise may exist only in your head.
The organization is exposed because it hasn't captured it.
But so are you.
When you leave, you may discover that decades of valuable expertise were attached to your title, your team, and your employer — but never transformed into assets you actually own and can carry forward.
Two versions of the same problem
For an organization, the exposure looks like operational risk: knowledge concentration, succession gaps, decisions that can't survive a departure.
For an individual technical executive, it looks like an asset problem: years of judgment that exist nowhere except in your own head and your own reputation, undocumented and therefore un-leverageable.
Different stakes, same root cause — expertise that was never deliberately discovered, captured, and put to use before it was needed.
Find out where your technology expertise is at risk
Most organizations know who their "Daves" are. What they don't know is exactly how much critical expertise depends on them — or what would disappear if they walked out the door tomorrow.
The FutureProof5:0 Expertise Value Assessment™ helps you identify where valuable technology expertise is being lost, trapped, or underused across five areas: Discover, Capture, Transform, Activate, and Evolve.
In about ten minutes, you'll get a clearer picture of where your technology expertise is vulnerable — and where there may be opportunities to create more value from what your people already know.