Tribal knowledge is killing your team. Here's how to fix it.

Every team has someone you have to ask. The senior engineer who knows why the deploy script has a sleep 30 in it. The ops manager who knows which Salesforce field is actually the source of truth for renewals. The customer success lead who knows that Acme Corp gets a discount even though there's no contract. When that person is on PTO, the team works around the gap. When they leave, the gap turns into a six-month dent in productivity.

That's tribal knowledge — the stuff people know but haven't written down. Every team has it. Every team loses some of it every year, mostly invisibly, and most teams “solve” it by scheduling a documentation sprint that produces a Confluence space nobody opens. The sprints don't work for predictable reasons. This post is about why, and what does work.

The cost is bigger than people think

Two numbers worth holding in your head.

First, employees spend roughly 21% of their work time searching for information they need to do their job, and another 14% recreating information they couldn't find, according to Bloomfire's Value of Enterprise Intelligence 2025 report. Add those together and a third of paid time goes to hunting and rebuilding things that already exist somewhere on the network.

Second, in manufacturing — where the brain-drain conversation is loudest — analyses cite that up to 70% of critical undocumented knowledge can leave with a retiring engineer, and ramp time for a replacement triples once the senior they were learning from is gone. The numbers in software and operations work are softer because nobody's tracking them as carefully, but the shape is the same: every departure is a lossy compression event, and the loss is biggest in the roles where the most institutional knowledge piled up.

The standard reaction is “we need better documentation.” The standard plan is a wiki cleanup sprint, a documentation week, an OKR about “knowledge capture.” Six months later the wiki is back to where it was. The reason is structural.

Why scheduled documentation loses

The schedule-time-to-document model treats writing as a separate activity from doing the work. The flow is: do the work for three months, then on Friday afternoon block off two hours, open Confluence, and try to write down what you did. The model is so universal it's almost invisible, and it fails for three reasons that don't go away.

Memory has already lossy-compressed the work. By the time you sit down to document, you don't remember the exact button you clicked, the specific URL, the value you typed in the third field, or the hotkey you used. You remember the gist. The gist is not enough for someone else to follow. So you describe at the gist level — “run the reconciliation” — and the doc fails the next reader who needs the steps.

The procedures you do automatically are invisible to you. The Tuesday-9am routine, the email you reply to twice a week, the keyboard shortcut you've internalized for three years — those are the ones most likely to be missing from the scheduled doc, because you don't notice yourself doing them. They are also the ones a cover person hits first and gets stuck on.

Writing is harder than working. Most people doing the work are not writers. The blank page in Confluence is intimidating. The doc someone produces in a two-hour block on Friday afternoon is the doc they had the energy to produce, not the doc the team needed. That's why scheduled-doc output is so variable in quality and so consistently low in detail.

The result is the wiki everyone has and nobody trusts. The phrase “Confluence is where information goes to die” is a meme for a reason: every engineer has watched a page they wrote in good faith become wrong, then become actively misleading, then get re-read by a new hire who follows it into a wall. The wiki isn't the problem. The model that produced its contents is.

What “capture-while-you-work” means

The alternative model is to flip the order: do the work and document at the same time, where “at the same time” is enabled by tooling rather than discipline. The doc is a side effect of the work, not a separate project.

In practice that means: before you start the recurring task — the reconciliation, the onboarding, the escalation triage — you hit record in a walkthrough tool. You do the task the way you always do it. Each click, navigation, form input, and hotkey-triggered region grab becomes a step in the recording. You stop recording. The doc exists.

The doc is not perfect at this point. You'll edit titles where the auto-fill was wrong, add a sentence of description on the steps where the screenshot alone isn't self-evident, and redact anything sensitive. The total editing time is usually 5 to 15 minutes for a procedure that took an hour to perform. Compared to the three-hour Confluence-from-memory session that produces a doc nobody trusts, the math is hard to argue with.

Three properties of capture-while-you-work that scheduled docs can't match.

It captures the procedures you do automatically. The hotkey, the right-click, the cell you double-click before pasting — those go into the recording the same way the conscious clicks do. The Tuesday-9am routine that a scheduled doc would skip ends up captured by accident.

It captures structure, not just pixels. Each step records the URL, the clicked element's visible text, the input value, the page title — not just the screenshot. That's the difference between “there's a picture of a button” and “here's the URL, the element label, the value to enter.” The reader gets a procedure, not a riddle.

The author isn't writing from memory. The author is correcting auto-filled titles and adding short sentences. That's a much easier task than blank-page Confluence, and it produces denser, more accurate output.

What to capture first

Most teams have more tribal knowledge than they can capture in one sprint. The sequence that pays back fastest:

1. The procedures one person owns

Start with the work that, if the owner went on PTO tomorrow, the team would feel a hole. The weekly billing reconciliation that only Sarah does. The quarterly board metrics export that only Diego knows. The customer health score recalculation that lives in someone's head and a Google Sheet.

These are the highest-yield captures because the recovery cost is the highest if the owner is unreachable. Hit record the next time the owner runs the procedure for real. Within the week you have a walkthrough that survives an unexpected absence.

2. The trigger-based work

The “when X happens, do Y” procedures. When a customer escalates, when a vendor invoice arrives, when the pipeline fails, when a contract expires. These don't fit a calendar but they fit a pattern.

Keep a recorder ready. The next time the trigger fires, hit record before responding. Do the work, stop recording. Within a quarter you'll have the top half of your trigger-based work covered. The long tail — the once-a-year escalation pattern — is best left as a written heuristic instead of a recording, because waiting for the next instance isn't a strategy.

3. The judgement calls

The hardest category. The decisions that look easy because the senior has made a thousand of them. Is this customer going to churn? Is this refund worth approving? Should we escalate this ticket? These don't fit a click-by-click walkthrough format.

The capture pattern: record the next decision the senior makes, and add a long-form description on the relevant step explaining the heuristic. “I approved this refund because the failure was on our side. If the failure is on the customer's side, we ask the questions in the ‘refund denial checklist’ before approving.” A handful of these — five to ten — usually covers the judgement work the team needs to delegate.

Where the recordings live

Three patterns work. None of them is the “put everything in Confluence” pattern.

A walkthrough hub linked from the wiki. Keep your wiki for free-form pages and policies. Put procedural recordings in a walkthrough tool, and link from the wiki. The wiki is searchable; the recordings do the actual instructional work. This is the lowest-friction upgrade for teams already running on Confluence or Notion.

Markdown export into the wiki. If your team prefers everything in one place, export each walkthrough to Markdown and paste it into the wiki page. Inline images. Recordings still get recorded by capture, but the artifact lives where the rest of the docs do.

Team-shared cloud workspace. If the procedures touch sensitive data, share the walkthroughs with your team only — authenticated through Google or Microsoft Entra ID — and link from one cover doc. Better for sensitive procedures than a public link, and the authentication path is the same one your team uses for everything else.

Capturing the senior before they leave

The high-stakes case for capture-while-you-work: the senior who's announced their resignation, or who's twelve months from retirement. Two-week handover plans don't work for someone with five years of accumulated context. Ninety days does, if it's structured right.

The shape that holds up:

Day -90 to -60: capture the recurring work. The senior records one walkthrough per week of the work they do on a schedule. Eight to twelve walkthroughs covers most of it. First-pass quality is fine.

Day -60 to -30: capture the trigger-based work. The senior keeps a recorder ready. Hits record the next time each trigger fires. Adds the heuristic as a step description while the reasoning is fresh.

Day -30 to -14: edit and dry-run. The senior fixes auto-filled titles, adds the one-sentence descriptions, redacts sensitive content. The successor runs one walkthrough end to end on a real instance, with the senior available for questions. Where the successor gets stuck, the walkthrough gets fixed.

Day -14 to 0: access and escalation. Confirm the successor has login on every system. Document who to escalate to for the things the walkthroughs don't cover. Set the senior's out-of-office.

The same shape works for routine handover: PTO cover, parental leave, sabbatical, internal transfer. The walkthroughs are the artifact. The calendar is the structure that gets them recorded.

Why this beats the “hire a technical writer” answer

Some teams answer the tribal knowledge problem by hiring a technical writer to interview the senior and produce documentation. This works better than scheduled docs. It also has limits.

The technical writer doesn't do the work, so they can't observe the procedures the senior does automatically. Interviews surface the gist; they don't surface the hotkey or the third-field value. The writer's output ends up at the same altitude as the senior's scheduled doc would, just in a different person's prose.

Capture-while-you-work doesn't replace a good technical writer. It changes the writer's job. Instead of interviewing the senior and reconstructing, the writer reviews the recordings the senior already made, reorganizes them into a hub, and writes the connective tissue between procedures. That takes a fraction of the time and produces denser output.

The team behavior change

Tooling helps, but the change that has to land is cultural: hitting record before a recurring task becomes the default, like hitting commit after a meaningful change. Three patterns help that land.

The first walkthrough is the senior's. If leadership is the first to capture, the practice becomes normal. If junior staff capture first while seniors keep working from memory, the implicit message is that recording is a junior-grade activity.

Captures get reviewed in the next one-on-one. Not for grammar — for completeness. “Is the redaction right?” “Did the auto-fill miss anything?” A 5-minute review per recording closes the loop and signals that the recording matters.

Onboarding includes following one walkthrough on day one. The new hire runs an existing recording end-to-end on a real (or staged) task. Where the recording fails, the recording gets fixed. The new hire's confusion is the most accurate signal of where tribal knowledge is still lurking.

What to do this week

One concrete experiment: pick the procedure that, if its owner went on PTO unexpectedly, would cause the most pain. Have the owner record it the next time they run it. Have one other person on the team try to follow the recording end to end. Where the follower gets stuck, fix the recording.

That's the smallest possible test of the model. If the recording survives a real dry-run, the capture-while-you-work approach works for your team. If it doesn't, the gap between the recording and reality is exactly the tribal knowledge you're trying to capture, and now you can see it.

Try UIHike on the procedure that scares you most to hand off. The walkthrough you record this week is the Slack ping you don't answer the day a senior is unreachable.

— The UIHike team