This post describes a hypothetical scenario based on common patterns we observe in distributed engineering teams. It is not a specific customer. Details have been generalized, and the outcomes are framed in directional terms rather than as precise measurements.
The company in this composite is a 60-person remote-first startup, of which roughly 40 are engineers, distributed across nine countries. At the start of the scenario, the company had a Notion workspace with about 4,000 pages accumulated over four years. The workspace was the official "source of truth" — and by the team's own honest assessment, perhaps 15 percent of the pages were current, 50 percent were stale, and the rest were either duplicates, half-written drafts, or orphaned. New hires were told to "check the wiki" and quickly learned that the wiki was a hostile information environment.
The structural problem
Wikis have a structural problem that gets worse with company age. Each page is written by someone who has the context to write it accurately at the moment of writing. The page captures that context. Then the underlying reality changes — the architecture evolves, the team reorganizes, the conventions shift — and nobody owns updating the page because there is no forcing function. After two years, the wiki is a confident, organized, navigable record of how the company used to operate. New hires read it. Old hires know better than to. The gap between what the wiki says and what the company does is a constant source of low-grade confusion.
The team had tried twice to "fix the wiki" with quarterly cleanup sprints. Both times the wiki was briefly clean, then drifted within a month. The leadership team eventually concluded that the wiki format itself was the problem — that any documentation system that decouples writing from working state will rot.
The intervention
The team did not delete the wiki. They reframed it. The wiki kept the truly evergreen content — company values, employment policies, brand guidelines — that does not change weekly. Everything that was operational — current architecture, team decisions, ongoing projects, conventions — moved to the wrap layer. Each team published wraps that captured the current state of their work and decisions. The Representative answered questions against the wraps, with citations, and refused when the answer was not in the record.
Governance, not a status channel
StandIn is async governance infrastructure. Engineers declare working state before they go offline. Representatives answer from the record, cite the source, and refuse when the answer is not there.
Request access →The directional results
Eight months after the transition, the team reported three directional outcomes. The number of "I checked the wiki and got the wrong answer" incidents dropped sharply, because the operational content was now in a layer that was being maintained as part of the working rhythm. New-hire ramp time fell, because the new-hire question "what is the current state of X?" now got a current answer with a citation rather than a stale page. The wiki became smaller, which the team treated as a feature rather than a regression — the evergreen content was easier to find when it was not buried under operational debris.
The friction the team did not anticipate was emotional. Several long-tenured employees had written significant chunks of the wiki and experienced its de-prioritization as a loss of contribution. The leadership team had to handle that explicitly — the wiki was not being deleted, the work was not being thrown away; the system was being adjusted to put each kind of content in the layer where it could be maintained.
What the team would do differently
The retrospective surfaced three lessons. First, do not try to migrate the wiki — let it shrink by attrition as new operational content goes to the wrap layer. Second, name the new layer explicitly to teams; "moved to wraps" is a clearer instruction than "stop using the wiki." Third, the truly evergreen content does belong in a wiki — do not over-correct and try to put everything into wraps.
Frequently asked questions
Is this a real company?
No. This is a composite based on common patterns we observe in remote-first companies whose wikis have decayed. The structural pattern — wikis rot because they decouple writing from working state — is what we see consistently.
Are wikis really useless?
No. Wikis are excellent for evergreen content — values, policies, brand guidelines, things that genuinely do not change month to month. The failure is using wikis for operational content, which always changes. Operational content needs a system tied to the working rhythm; evergreen content does not.
What about searchability? Does the wrap layer have search?
Yes. The Representative is the search interface — engineers ask questions in natural language and get cited answers. The full-text search of a wiki is also still available for the evergreen layer that remains there.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.