Tribal Knowledge: Getting It Out of Heads Without a Documentation Project

Every team with a knowledge concentration problem eventually schedules a documentation effort. It runs for one or two sprints, produces a folder of pages, and then stops, and within six months the pages are stale enough that people go back to asking each other.

"We tried a documentation sprint. It lasted a sprint."

Why the documentation sprint lasts a sprint

Three structural reasons, none of which are about commitment.

The effort is front-loaded and the benefit is diffuse. Two weeks of writing now, for a payoff distributed across unknown future readers, which means nobody involved experiences the return.

The scope is unbounded. Asked to document an area, a competent engineer sees that the honest version is enormous, so they either write something shallow or stall on where to begin.

And the output decays. A document describing a system is accurate on the day it is written and drifts from then on, with no signal to the reader about how far it has drifted. Six months later it is a liability, because one wrong page teaches people not to trust the folder.

What tribal knowledge is made of

Break it into parts and the fix becomes clearer, because the parts have very different properties.

Type	How often asked about	Best captured
Current state of work	Constantly	Daily, in a line or two
Past decisions and reasons	Often	At the moment of deciding
Dead ends already tried	Often, usually too late	On the day they failed
System structure	Occasionally	Once, in a diagram, accepting decay

The bottom row is what documentation projects produce and the top three are what people actually ask about. All three of those are cheap to capture on the day and nearly impossible to reconstruct afterwards, which inverts the usual priority.

The alternative: capture as a by-product

Stop treating this as a project with a start and an end. Attach it to something that already happens every day: finishing work.

That is the shape of the brief. Ninety seconds at the end of the day, mostly pre-drafted from the work that already happened: current state, open questions, blockers, next actions, plus any decision made and why. No kickoff, no scope debate, no separate initiative. Over a year it accumulates into a record of the top three rows of that table, in the words of the person who did the work.

With StandIn, that record is also answerable. While someone is off, their StandIn answers questions from their brief in their words, with a source under every answer, and never guesses: if the answer is not there, it says so and names who to ask. The knowledge stops being tribal not because it has been written into a folder, but because there is a second route to it that does not require the person to be awake. See how StandIn works.

The reason this sustains where a sprint does not is the incentive. Ninety seconds tonight saves you an interruption tomorrow morning, so the person paying the cost is the person collecting the benefit, within a day.

Dead ends are the most valuable and least recorded

Worth its own section, because this is the highest-return item nobody captures. When an approach is tried and abandoned, the knowledge that it does not work is genuinely expensive to acquire and nearly free to write down. And it is almost never written down, because abandoning an approach feels like a non-event: nothing shipped, so there is nothing to report.

Six months later somebody tries the same approach and spends the same three days discovering the same thing. This is one of the most common and least visible forms of duplicated work in engineering.

One line is enough. "Tried batching the webhook retries at the queue level, abandoned because ordering guarantees break under partial failure." That sentence saves the next person three days, and it costs twenty seconds on the day the attempt died.

How to start without a project plan

Pick one team, not the company. Ask for four fields at the end of each day for two weeks, with the lead going first and visibly. Do not create a new destination for it; put it where the team already looks.

After two weeks, ask one question: how many times did someone get an answer from a brief instead of asking a person? If the answer is more than a handful, it will continue without any further encouragement. If it is zero, the briefs are in the wrong place or too vague, and both are quick to fix.

Common Questions

How do you capture tribal knowledge without a documentation project?

Attach the capture to the end of the working day in a form that takes about ninety seconds, and keep it to current state, open questions, blockers, next actions, and decisions. Projects fail on effort and decay; daily capture stays current because it is about today.

Is documentation ever worth doing as a project?

For genuinely stable structural things, yes: a system diagram, a runbook for a rare procedure, an onboarding path. Those change slowly and reward a one-off effort. Anything that changes weekly should never be a project.

How do we get people to record dead ends?

Add one prompt to the end-of-day habit: anything you tried that did not work. Naming it explicitly is most of the battle, because people do not think of a failed attempt as information worth passing on.

What if senior people refuse to do this?

Check how long it actually takes them. Resistance is almost always to a perceived forty-minute obligation. Ninety seconds, mostly pre-drafted, in exchange for fewer interruptions tomorrow is an easy trade for the person who is interrupted most.