The real cost of tribal knowledge in a support team

Tribal knowledge feels free. It never shows up as a line item, never sends an invoice, never asks for budget. The team just knows things - who to ask about webhooks, what that error actually means, why you never touch that setting on legacy accounts.

But it bills you constantly. The charges are just spread thin enough across the year that no single one triggers an alarm. Here's the invoice, itemised.

Start with the holiday test

Pick a routine-but-technical ticket type - the kind that comes in weekly. Check how long it takes to resolve when your most experienced person is in the office. Now check the week they were on holiday.

If the answer is "twenty-five minutes, except that one week it took two days," then the knowledge required to resolve that ticket doesn't belong to your team. It belongs to a person.

If one person's holiday changes your resolution time, you don't have a team that knows things. You have a person who knows things, with colleagues.

The four line items

Ramp time. New agents take months to become useful on hard tickets - not because the product takes months to learn, but because most of what they need to know was never written down. There's no curriculum, so onboarding is apprenticeship by osmosis: shadow someone, absorb what you can, rediscover the rest one embarrassing ticket at a time. Every unwritten answer is a week added to every future hire's ramp.

The interrupt tax. The people who hold the knowledge become human search engines. Their day fills with "quick questions" - each one cheap, the stream of them ruinous. Your most valuable people end up doing their real work in the gaps between being an index for everyone else's. This is also how they burn out, which brings us to the next item.

The leaving write-off. When a knowledge-holder resigns, years of accumulated answers walk out with them - and there's no handover document long enough to capture what they knew, because they don't know what they know until a ticket asks for it. The organisation then re-purchases that knowledge the slow way: one re-derived answer at a time, at the queue's expense.

Inconsistency. The same question gets different answers depending on who picks it up. One customer gets the senior person's precise workaround; another gets a plausible guess. Customers compare notes in ways you'd rather they didn't, and every wrong guess is a future ticket with interest.

Why the wiki sprint doesn't fix it

Every team that notices this problem runs the same play: a documentation drive. Everyone writes down what they know; the wiki blooms; the initiative is declared a success. Six months later the wiki is a museum.

The reason it fails is structural, not motivational. Support knowledge is produced continuously - at resolution time - but documentation drives are batch jobs. They capture a snapshot of a moving target, written from memory rather than at the moment of solving, by exactly the people who have the least time to write. The product ships past the snapshot within a quarter. And the docs that do get written describe how the product is supposed to behave - while the expensive knowledge is the other kind, the "that happens when the webhook retries and they're on the legacy plan" kind, which only surfaces when a real ticket drags it out of someone.

Capture where the knowledge is made

The problem was never that people know things. It's that the knowing happens in a place with no capture: every resolved ticket contains a small, verified lesson - real problem, real cause, the fix that actually worked - and the standard workflow discards it the moment someone clicks "resolve."

Move the capture to that moment and the economics invert: knowledge accumulates as a side effect of doing the work, instead of depending on heroics after it. That's what Brocklore's memory does - it distils every resolved ticket into a lesson your whole team can reuse, automatically, and surfaces it the next time a similar ticket arrives. We've written about it in No answer should be learned twice.

The knowledge already exists - you're paying people to produce it daily. Stop discarding it at "resolve".