Every small team has a number it doesn’t like to say out loud: how many people can get hit by a bus before the project dies. For a lot of five-person teams, the honest answer is one.
Not because the other four are replaceable. Because the knowledge isn’t shared — it’s stored, in one person’s head, in the muscle memory of how the deploy actually goes, which alarm to ignore, why the staging database has that one weird table.
The wiki isn’t the answer
The standard fix is documentation, and the standard failure is the wiki. We know how this goes: a burst of enthusiasm, a tidy folder structure, forty pages written in a sprint — and then silence. Eighteen months later the docs describe a system that no longer exists, and reading them is worse than guessing.
Wikis fail because they’re a separate artifact with a separate upkeep cost. Every change to the real system creates a debt in the fake one, and nobody’s performance review mentions doc debt. So the debt compounds until the wiki is a museum.
The teams that actually survive a departure do something different: they keep knowledge next to the work, where it updates as a side effect of working.
Knowledge that maintains itself
Three habits beat any wiki:
1. Decisions get logged where they’re made. When you choose Postgres over DynamoDB in a PR discussion, that reasoning already exists — it’s in the thread. The failure is letting it stay buried. A one-line note on the task, linking the thread, captures it forever. Thirty seconds, done in the moment, no upkeep.
2. The board shows the work, not claims about the work. If status comes from commits, PRs, and CI rather than typed updates, then a new person can reconstruct “what’s going on” without interviewing anyone. The knowledge was never in someone’s head to lose.
3. The weird stuff gets written down at the moment of pain. The staging database’s weird table gets documented the day it bites someone, in the ticket where it bit them. Pain is a great editor: it knows exactly what’s worth recording.
What this costs
Less than you’d think, because it’s not a process — it’s a location. Move the note from someone’s head to the ticket, the decision from the hallway to the thread, the status from the standup to the board. Same information, durable address.
The bus factor isn’t really about buses. It’s about vacations, resignations, and the ordinary Tuesday when the one person who knows the thing is on a plane. Teams that keep knowledge next to the work don’t need heroics. They need the work to leave a trail.
That’s a big part of why Kahoona puts live repo activity, tasks, and a whiteboard in one place: the trail forms on its own, and the next person inherits a system that explains itself.
👉 Give your project a memory — free to start
Related: Why commits belong next to tasks · Jira shows tickets, not truth