Tribal Knowledge: The $2.3 Million Resignation

A US manufacturing company lost $2.3 million in four months. Not from a security breach, not from a market downturn — because a single machinist retired. His 35 years of experience walked out the door with him. The cost of preventing that? $10,300.

In manufacturing, they call this tribal knowledge. The stuff that lives in people's heads, not in systems. IT service companies have the exact same problem — they just talk about it less.

The 80% Problem

80 percent of critical operational knowledge in companies is undocumented. At IT agencies, that number sounds abstract until you map it to your own team.

The senior developer who's the only person who understands the legacy system for your biggest client. The support lead who carries every workaround for that one API issue in her head. The project manager who knows that Client X gets anxious two days before every deadline and needs a phone call — never an email.

50 percent of IT support activities rely entirely on tribal knowledge with no documented SOPs. That works. Until it doesn't.

30 percent of knowledge workers' time goes to searching for and recreating information that already exists somewhere in the company.

Thirty percent. On a team of ten, that's three full-time equivalents producing nothing new — just rediscovering what's already there. IDC measured this, and honestly, after running teams myself, the number feels low.

The Bus Factor

Software developers have a term for it: bus factor. How many people would need to disappear tomorrow for a project to grind to a halt? At many IT service companies, the honest answer is one.

The numbers behind this are sobering. Replacing a departing employee costs 50 to 250 percent of their annual salary, depending on specialization. Contact centers see 30 to 45 percent annual turnover. And 70 percent of service organizations expect significant problems from knowledge loss when experienced staff leave.

Poor knowledge transfer costs large enterprises up to $47 million annually. At a 30-person agency the absolute figures are smaller. The relative damage is often worse because there's less redundancy to absorb the hit.

When Atlas Quits

I've seen this play out firsthand. At eins+null, my previous company, we had a team lead who knew every quirk of our core platform. Undocumented, naturally. When he resigned, it took us three months to reconstruct his implicit workarounds. Some of them we probably never found.

The header image for this article shows a man holding up the globe on his shoulders. Most IT service companies have exactly that person — the Atlas without whom nothing supposedly works. That's not a compliment. It's a risk.

What Aviation Figured Out

Aviation faced the same problem — with considerably higher stakes. 70 percent of flight accidents traced back to human error, many of them to poor knowledge transfer between crew members.

The answer arrived in the 1980s: Crew Resource Management. The core idea sounds almost too simple — implicit knowledge gets systematically converted into checklists, SOPs, and team training. No pilot relies on "everyone knows that." Instead, there are challenge-response checklists: one person calls out, the other verifies. "Landing gear down?" — "Landing gear down, confirmed."

Result: up to 50 percent fewer errors.

Medicine took a similar path. The SBAR protocol — Situation, Background, Assessment, Recommendation — was designed for shift handoffs. Not because doctors are forgetful, but because structured handoffs cut errors by 30 to 50 percent.

Both aviation and medicine had one advantage: the consequences of poor knowledge handoffs were visible. People died. At IT agencies, the consequences are quieter — a lost client here, rework there, an onboarding that takes twice as long. Quieter, but cumulatively no less expensive.

Structure Over Memory

So what do you do about it? Four levers that, from what I've seen, make the biggest difference:

Knowledge audits. Not once a year — continuously. Who knows what? Where does only one person hold the key? The honest answer to that question is almost always uncomfortable. That's exactly what makes it useful.

Structured handoffs. Whether it's a project handoff, a client transition, or a shift change in support: a fixed structure — who takes over what, what context is missing, where the risks sit — keeps knowledge from falling through the cracks. It's essentially medicine's SBAR protocol adapted for IT services.

Documentation as a byproduct. The problem with "we need to document better" is universal. It never happens because nobody has the time. Better approach: documentation emerges as a side effect of normal work. Ticket resolutions that automatically feed a knowledge base. Project notes that stay visible in the client portal. If knowledge management means extra work, it will fail.

A single source. Knowledge transfer rarely fails because people don't care. More often, it fails because information is scattered across Slack, email, Google Drive, the ticketing tool, and three people's heads. Consolidation — one system instead of five — is probably the single most effective lever against corporate amnesia.

Fragmented knowledge costs organizations up to 60 percent of their organizational productivity.

The Choice

Knowledge management isn't an HR project or an IT project. It's the question of whether a company depends on people or on structures. Aviation chose structures — after enough planes had crashed. IT service companies have the luxury of making that choice earlier.

We built Leadtime because we saw firsthand how much knowledge lives in heads instead of systems. Project history, client context, and ticket patterns become visible — not because we're smarter than anyone else, but because the next Atlas resignation shouldn't cost us three months of detective work.