Why engineering teams keep re-answering the same questions, and what finally fixed it for us.
A new engineer joined our team on a Tuesday. By Friday, she had asked four questions in Slack that already had answers in Slack. Not even old Slack — one of the answers was from the Monday before she joined.
This is the dirty secret of chat-first engineering: the documentation exists, and nobody can find it. The decisions are made in threads. The fixes are shared in DMs. The context lives in the one person who happened to be in the channel that afternoon. When that person leaves, or just goes on vacation, the whole knowledge graph collapses to a 404.
The three things we tried that didn't work
Over three years we tried, in order:
- A wiki. Nobody wrote in it. The three people who did got frustrated when nobody read what they wrote.
- An AI search over the Slack export. It was shockingly good at surfacing threads — and shockingly bad at telling you whether the thread's conclusion was still true.
- A "please write it down" cultural push. This works for a quarter, then dies.
What we noticed: every one of these solutions put the work on the wrong person. The person who knows the answer doesn't need to look it up. The person who needs the answer doesn't know it exists.
What actually fixed it
Three changes, in order of how much they mattered:
- Capture happens at the moment of decision, not after. When Hannah writes "ok let's go with 3 retries + manual review", that is the moment the knowledge exists in a usable form. Not the next morning when she might remember to write it down.
- A human confirms before anything becomes canonical. The hard part of knowledge isn't the writing, it's the ratification. The entry exists after a trusted person says "yes, that's what we agreed."
- When something changes, the old entry gets struck through — not deleted. New hires see what used to be true, which is often how they understand why we do what we do now.
That's it. That's the whole model. The product we built — Threadseam — is three screens around those three ideas. We spent most of our engineering budget on the consent flow for private channels, which deserves its own post. The core idea is boring: catch the decision as it happens, let a human sign it off, don't lose it when things change.
What we got wrong
We built draft-generation first. We thought the magic would be in writing the entry well. It turned out the magic was in asking the right person at the right time; the writing is almost a side effect. We threw away three months of work on sentence quality.
If you're trying to solve this inside your own team: start with the capture moment and the confirmation flow. The rest is implementation detail.