Marcus starts on a Monday. By Wednesday he has three tabs open just to answer one question: is the onboarding-flow spec he's building against the current one? One tab is a wiki page last edited four months ago. Another is a doc his manager linked in a Slack message that's since scrolled off the channel. A third is a PDF someone attached to an email titled "final-FINAL-v3." None of the three agree with each other, and none of them are linked to the actual task he's supposed to be working from.
The problem isn't that nobody wrote it down
Most teams don't lack documentation, they lack a settled place documentation is supposed to live. A wiki tool, a shared drive and a chat app each hold a piece of the truth, and each one drifts at its own pace because updating one doesn't update the others. "Single source of truth" gets used as a slogan, but it's really just a location problem: if there's more than one place a fact could be, someone will eventually read the wrong one.
What actually fixes it
The fix isn't a stricter policy about which tool to use, it's removing the second tool. Docs that live directly inside a space, nested next to the folders and lists they describe, don't have a separate URL to lose track of and don't need a "which one is current" conversation, because there's only one. A spec doc sits one click from the sprint list it governs. A client onboarding doc sits inside the client's space, not in a wiki three other departments could also be editing.
A worked example
Picture the same onboarding-flow spec, but written as a nested doc inside the space Marcus is actually working in. The task he was assigned links straight to it. When his manager revises a requirement, she edits that doc, and the next time Marcus opens the task, the doc he sees is the current one, because it's the only one. There's no second copy sitting in a drive folder to accidentally reference, and no "let me check if that Slack message is still accurate" step standing between him and starting work.
It scales without turning into its own project
The instinct once a company has more than a handful of docs is to reach for a dedicated wiki product, which solves the drift problem by creating a new one: now there are two systems, the tracker and the wiki, and keeping them pointed at each other becomes its own maintenance job. Nested docs sidestep that by not existing anywhere else to point at. A doc can carry rich text, get exported to PDF when someone outside the team needs a copy, and get a public link when a client needs to see it without an account, all without leaving the space the work happens in.
What it's worth
The payoff isn't abstract. It's every future new hire who doesn't spend their first week reconciling three versions of the same document, every manager who doesn't get pinged to confirm which draft is real, and every client who gets one working link instead of a "sorry, use this one instead" follow-up email. A single source of truth isn't a discipline a team has to maintain, it's what happens automatically once there's nowhere else for the truth to be.