The short version
- Most knowledge sharing programmes fail because they ask people to write things down in advance. Nobody knows in advance what will be needed.
- The cheap version works backwards: when you answer a question, spend thirty extra seconds making the answer findable by the next person.
- Answer in the channel, not the direct message. That one habit does more than any documentation initiative.
- Current state cannot be shared this way, because it changes weekly. That needs a different mechanism.
Every remote team eventually runs a knowledge sharing initiative. A wiki gets set up, templates are agreed, a Friday hour is reserved for documentation. Six months later the wiki has forty pages, eleven of them accurate, and people still ask each other in chat.
Why sharing programmes fail
They ask for prediction. Writing documentation in advance means guessing what a colleague will need in four months, and people are poor at that guess, especially about their own expertise. The things you know best have stopped feeling like knowledge, so they do not make the page.
They also run against the grain of the work. Documentation time is a separate activity competing with delivery, and it loses every quarter that is busy, which is every quarter.
The alternative is to stop predicting. Someone has already asked a real question, you have already answered it, and the answer is already written. The only missing step is making it findable.
The thirty second routine
When you answer a question that took you more than a minute to answer, do three things before you move on.
- Answer where it can be seen. The channel, not the direct message. This alone makes the answer searchable by everyone else who will hit it.
- Restate the question in your answer. "On whether archived records go into the export: no, and here is why." Now it matches the words the next person will search for, which will be their words rather than yours.
- Say when it stops being true. "This holds until we move reporting off the primary." Without that line, the answer will be quoted back to someone in a year when it is wrong.
Thirty seconds, no new tool, no initiative. The compounding is what makes it work: every answered question makes the next identical question cheaper for everyone.
The direct message problem
Direct messages are where team knowledge goes to die. The answer exists, is correct, and is visible to exactly two people, one of whom will forget it.
The reason people use them is social rather than technical. Asking in public feels like admitting you do not know something, and answering in public feels like showing off. Both feelings are real and both are expensive.
The fix is a norm stated once by whoever is most senior, and then demonstrated. When a lead moves their own answers into the channel with a light "putting this here so it is findable", the team follows within about a month. Asking people to stop using direct messages without modelling it does not work. See the team chat norms template.
Three kinds of knowledge, three fates
| Kind | Example | Where it should live |
|---|---|---|
| Stable facts | The refund policy, the deploy process | Written once, where the question occurs |
| Reasoning | Why exports are nightly | A decision entry, next to the work |
| Current state | Where the migration got to this week | Nowhere, in most teams. See below. |
Teams that treat all three the same end up with a knowledge base where the stable facts are buried under stale state, which is how a wiki becomes untrustworthy. See why knowledge bases die in month four.
The kind that cannot be written in advance
Current state defeats every documentation approach, because the effort to keep it accurate is continuous and the payoff is unpredictable. So nobody does it, and it stays in people's heads, and it is the largest category of what gets asked.
This is what StandIn is built for. At the end of the day a person spends about ninety seconds on a brief: what moved, what is open, what is blocked, what is next, mostly drafted from the work that already happened. It is attached to the work rather than being a separate documentation task, which is why it survives a busy quarter. When a colleague asks where something stands, the answer comes from that brief in the person's words, with a source under it. It never guesses, and when the answer is not in the record it says so and names who to ask. The stable facts and the reasoning still belong in writing, and this handles the third kind. See how teams use it.
Common Questions
Should we appoint a documentation owner?
An owner for structure and pruning, yes. An owner who writes the content, no. Knowledge written by someone who does not do the work reads correct and is subtly wrong in the ways that matter.
How do we deal with the wiki we already have?
Delete aggressively. A small accurate wiki is used, a large partly wrong one is not, and pages nobody has opened in a year are costing you trust. Archive rather than agonise.
What about recorded sessions and brown bags?
Good for context and culture, poor for retrieval. Nobody watches a recording to answer a specific question. If a session contains five reusable answers, write the five answers down as well.
Does an AI assistant over our documents solve this?
It helps with what is written and cannot help with what is not, which is the larger part. The thing to check is whether it tells you when it does not know, or produces something plausible instead. See when the internal AI tool guesses.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.