OscoTribal knowledge is information that only a few people hold, learned through experience and passed along in conversation. It is valuable, and it is fragile.
Key takeaways
- Tribal knowledge slows onboarding and creates single points of failure.
- Capture it at the moment it is used, not in a big documentation project.
- Turn repeated answers into pages.
- Store it where the work happens so it stays current.
Why it matters
Every team has the person who knows why a strange config exists or which service to restart first. As long as they are around, everything works. When they are on holiday, busy or gone, the team discovers how much lived only in their head.
Tribal knowledge also taxes everyone else. New hires learn by interrupting, and the same questions are answered again and again.
Signs you have a lot of it
- People say "just ask Priya" about core systems.
- Incidents are fixed by whoever remembers the last time.
- Onboarding is mostly shadowing.
- The same question appears in chat every few weeks.
Low-effort ways to capture it
Answer once, in a doc
When someone asks a question, write the answer in a page and reply with the link. The next asker finds it, and the page improves each time.
Record decisions
A short note with the choice, the options and the reason takes minutes and saves months of re-arguing.
Write runbooks after incidents
The best time to document how something breaks is right after it broke. Capture the symptoms, the fix and the follow-ups.
Pair on the write-up
Ask the expert to talk through a system while someone else writes. It is faster for the expert and gives the writer a real reader's view.
Add it to the task
If a task depends on a quirk, put the quirk in the task or link a doc. It is captured exactly where it will be needed.
Keep it findable
Captured knowledge only helps if people can find it. Group it by system, give pages clear titles and link it from tasks and API references. In Osco, docs can be linked to the tasks, endpoints and features they explain, so the note shows up next to the work.
Conclusion
You do not need a giant documentation project. Capture knowledge when it is used, turn repeated answers into pages and keep them near the work. Over time, the team depends less on individuals and more on what it has written down.