Deck: Research across engineering organizations points to the same pattern: the real answer is never in the wiki.
What this article solves: Engineering teams store critical knowledge in at least three places at once, and those places routinely disagree. This post maps where tribal knowledge actually lives, based on survey data and team research, so frontline and cross-functional teams can stop guessing which source to trust.
Who this is for: Customer support leads, CS engineers, and anyone who escalates to engineering because internal answers conflict.
It was 2:47 PM on a Tuesday when Maya, a senior CS engineer at a mid-size SaaS company, opened ticket CS-4112 for the third time that week. The customer was hitting a rate-limit error that Maya had seen before. She was sure of it.
She checked Confluence first. The rate-limiting article said 1,000 requests per hour, last edited eight months ago. She opened the Jira epic linked in the ticket. A comment from a backend engineer, added four months back, mentioned the limit had been "adjusted." She searched Slack. In #api-questions, someone had posted the actual number two months ago: 500 requests per hour. Three tools. Three versions of the same fact.
Maya escalated to engineering. The engineer who replied had answered the exact same question last quarter, in a different thread, to a different CS rep.
The disagreement is not an accident
The three-tool problem Maya hit is not a failure of discipline. It is the natural output of how engineering work actually happens.
Survey data from the State of Software Quality report (Testim, 2022) found that 57% of engineering teams say they spend more than an hour per week searching for information they believe already exists somewhere. A separate Stack Overflow Developer Survey found that documentation is consistently ranked among the top three things developers say slow them down, year after year. The problem is not that teams refuse to document. It is that documentation gets written in the wrong place, at the wrong time, and then left there.
Knowledge does not sit still. A decision made in a Jira ticket gets implemented in a PR, discussed in Slack, and then referenced in a Confluence page that nobody updates when the implementation changes. Each artifact is a partial truth. None of them is the whole story.
Where the knowledge actually lives (and why it moves)
Research from the Nielsen Norman Group on organizational knowledge management identifies three categories of knowledge in technical teams: explicit (written down), implicit (understood but not recorded), and tacit (known only to individuals). In most engineering orgs, the split is roughly inverted from what teams want. The most important knowledge, the decisions behind the code, tends to be tacit or implicit.
Surveys of engineering teams consistently show the same distribution of where people look first when they need an answer:
| Source | % who check first | Freshness reliability |
|---|---|---|
| Slack / team chat | 41% | High (recent), low (historical) |
| Confluence / wiki | 28% | Low (stale within weeks) |
| GitHub PRs / commits | 19% | High (source of truth) |
| Jira / Linear tickets | 9% | Medium (depends on team discipline) |
| Other (docs site, Notion) | 3% | Variable |
Source: Adapted from DX (Developer Experience) Index survey data, 2023.
The pattern holds across company sizes. Slack is where people look first because it is where conversations happen. But Slack has no memory. A thread from three months ago is effectively gone unless someone knows exactly what to search for. The wiki is where people look second, but wikis go stale within weeks of a system change. GitHub holds the most accurate record of what the code actually does, but fewer than one in five people check it first for answers to operational questions.
The result is that the most reliable source gets checked last, if at all.
The escalation tax
When internal sources disagree, the cost lands on whoever is closest to the customer.
A 2023 report from Atlassian on team collaboration found that knowledge workers lose an average of 5.3 hours per week to inefficient information sharing. For CS teams, the loss is more specific: it shows up as escalations. An escalation is not just a time cost. It is a trust cost. The engineer who gets pinged for the fourth time about the same rate-limit question starts to lose confidence in the documentation system. The CS rep who gives a customer the wrong answer from Confluence loses credibility with that customer.
The Atlassian research also found that 56% of workers say they frequently receive conflicting information from different tools. Maya's three-tool problem is not unusual. It is the median experience.
In practice: one ticket, four artifacts, no agreement
Take a real scenario. A CS team is handling a spike in errors tied to a recent deployment. They open the runbook in Confluence. It references a service that was renamed six months ago. They search Slack and find a message in #deployments from the engineer who did the rename, explaining the new service name, but the message is buried in a thread with 47 replies. They open the Linear ticket for the deployment. The ticket is marked done. There are no notes on the rename.
The PR that actually made the change, PR #2241, has a detailed description explaining why the service was renamed and what downstream systems were affected. Nobody on the CS team has access to GitHub, or knows to look there.
This is where the ScopeDocs model addresses the gap directly: it reads the decisions where they actually form (GitHub PRs, Slack threads, Linear tickets) and generates source-linked documentation that stays connected to the code that produced it.
The runbook should have updated itself when PR #2241 merged. It did not, because nobody wrote that step into the process.
What surveys say about fixing it
The research points to three conditions that predict whether knowledge gets captured or lost.
First, proximity to the workflow. Knowledge captured at the moment of decision, inside the tool where the decision happened, is more likely to stay accurate. Knowledge written after the fact, in a separate tool, decays faster.
Second, ownership clarity. Teams where a specific person owns a doc see better maintenance. Teams where "everyone" owns it see faster decay. A 2022 survey by Document360 found that 68% of technical writers say their biggest challenge is getting subject-matter experts to review and update content.
Third, traceability. Docs that link back to their source, the PR, the ticket, the thread, are easier to verify and easier to update. Docs that exist as standalone pages with no lineage are the ones that quietly become wrong.
None of these conditions requires a new process. They require the documentation to be closer to where the work happens.
Checklist: auditing where your tribal knowledge lives
- Map the three most common escalation topics from CS to engineering in the last 90 days
- For each topic, identify which tool holds the "official" answer and when it was last updated
- Check whether the GitHub PR or commit that changed that behavior has a description that matches the wiki
- Identify which Slack channels hold recurring answers to questions that should be documented
- Audit your runbooks for references to renamed, deprecated, or removed services
- Assign a named owner (not a team) to each critical operational doc
- Set a review trigger tied to merged PRs, not a calendar date
The research is consistent: tribal knowledge does not live in the wiki. It lives in the PR description, the Slack thread, and the ticket comment that nobody exported. The teams that close the gap are the ones that stop treating documentation as a separate task and start capturing knowledge at the source.
ScopeDocs connects GitHub, Slack, and Linear to build docs that stay linked to the code that produced them, so the next time CS-4112 lands in the queue, the answer is already written.