There is a question that circulates through engineering teams with near-clockwork regularity. It arrives in Slack, usually from someone who joined in the last six months. It concerns something that has been answered before - sometimes many times. Within the hour, three senior engineers have each shared a different document, none of which fully answers the question. By end of day, someone has written a partial synthesis in a thread that will never be searchable again.
This is not a failure of intelligence or effort. It is a structural problem that every team building on accumulated institutional knowledge eventually encounters, and it tends to get worse, not better, as the team grows.
Why the Pattern Is So Persistent
The re-derivation cycle has a few consistent root causes worth naming precisely.
First, most teams treat knowledge capture as a write-once activity. An engineer makes a decision, documents it in a Confluence page or a Jira ticket comment, and considers the task complete. But the decision is connected to a broader context - what alternatives were considered, why certain tradeoffs were made, what subsequent changes rendered parts of the original thinking obsolete - and that context almost never makes it into a permanent, findable record.
Second, the tools that teams use for knowledge storage are organized around documents, not questions. Confluence stores pages. Jira stores tickets. Slack stores threads. None of these are indexed in a way that maps naturally to the question a new engineer is actually trying to answer. When that engineer types "how do we handle authentication token expiry?" into Confluence search, they get a list of pages that contain those words. They do not get a synthesized answer that draws from the Jira ticket where the expiry window was debated, the engineering discussion thread where an edge case was resolved, and the RFC document where the final decision was recorded.
Third, and perhaps most importantly, the cost of asking a question that could be answered from existing documentation is borne by the wrong person. The person who already knows the answer - typically a senior engineer who has been on the team for years - pays the cost of being interrupted. The person asking pays the cost of waiting. The organization pays both costs repeatedly, for every variation of the same question, indefinitely.
What the Research Actually Shows
Studies of developer productivity consistently find that context-switching and interruption are among the most expensive activities a development organization can incur. McKinsey's work on developer velocity has estimated that top-quartile development organizations are four to five times more productive than bottom-quartile ones, and a significant portion of that gap comes down to how efficiently institutional knowledge flows to the people who need it.
A simpler way to frame it: the engineering team that can answer its own questions without routing them through its most senior members has a structural productivity advantage that compounds over time. The team that cannot loses senior engineer time to answering the same questions on rotation, regardless of how many processes it implements to try to reduce that load.
The Onboarding Multiplier
The re-derivation problem is most acute during onboarding, but it does not stop there. A new engineer joining a team encounters the most acute version of the knowledge-access problem because they have no prior context at all. But the same structural issue affects engineers who have been on the team for a year when they move to a new part of the codebase, or when the team inherits responsibility for a system that was built by people who have since left.
The tribal knowledge problem is not just an onboarding problem. It is a knowledge-access problem that becomes most visible during onboarding because that is when the gap between what someone knows and what they need to know is largest. But the gap exists continuously, for everyone, as the organization and codebase evolve faster than any individual can track.
Why Documentation Alone Does Not Solve It
The natural response to the re-derivation problem is to invest in documentation. Write better docs. Enforce documentation standards. Create templates. Assign documentation tickets as part of every sprint. These are all reasonable practices, and teams that do them well are better positioned than teams that do not.
But documentation investment runs into a set of fundamental constraints that limit how much it can accomplish on its own.
Documentation is a synchronous, effortful activity that competes with shipping. Every engineer knows that the time spent writing documentation is time not spent on the next feature. This is not laziness - it is a real tradeoff, and in most organizations, documentation consistently loses to delivery pressure.
Even when documentation is written, it decays. The accurate RFC from eighteen months ago describes a system that has since been modified three times. The Confluence page that explains the authentication flow was accurate when it was written, but two significant refactors later, it contains a mix of still-accurate information and outdated assumptions. There is no mechanism that keeps it synchronized with the current state of the system.
And even when documentation exists and is reasonably current, finding the right piece of it to answer a specific question requires knowing where to look and what search terms to use. Engineers who are new to a domain or a codebase often do not know what they do not know - and that epistemological gap is precisely what makes the Slack question pattern so persistent.
A Different Frame: Synthesis Infrastructure
What teams actually need is not better documentation discipline. What they need is synthesis infrastructure - a way to route questions to answers that already exist somewhere in the organization's knowledge base, regardless of which tool that knowledge happens to live in.
This reframe matters because it changes what success looks like. A documentation-focused approach succeeds when engineers write more and better docs. A synthesis-focused approach succeeds when engineers can get answers without asking colleagues - regardless of whether those answers come from well-maintained documentation, ticket history, or archived Slack threads.
The question "why does this service have a 30-second timeout?" might be answerable from a Jira ticket comment from two years ago, even if nobody ever wrote that fact into a Confluence page. A synthesis-first system surfaces that answer. A search-first system requires that someone either wrote a Confluence page containing the words "30-second timeout" or that the engineer searching knows to look in Jira and knows which ticket to look in.
The Cost Is Higher Than It Looks
Teams that have lived with the re-derivation cycle for long enough often stop noticing it. It becomes part of the background overhead of getting work done. Senior engineers expect to be interrupted. New engineers expect to wait for answers. The cost of the pattern gets absorbed into planning estimates and general expectations about velocity.
The hidden cost is harder to see: the senior engineer who does not write the design document because she knows she will just explain it in Slack when someone asks. The new hire who does not ask the question because he has already asked three this week and senses the social friction of asking a fourth. The decision that gets re-litigated in three separate Slack threads over six months because nobody synthesized and stored the reasoning from the first discussion.
These are not dramatic failures. They are accumulating frictions that slow the team down gradually, compound as headcount grows, and are nearly invisible until someone tries to measure them directly.
The Slack question is not the problem. It is a symptom of an organization that has accumulated more knowledge than its retrieval infrastructure can make accessible. Solving it requires thinking about knowledge access as an engineering challenge, not a documentation discipline challenge - and building the systems that treat it accordingly.