At one point in my independent technical writing practice, I held every role simultaneously. Subject matter expert. Writer. Reviewer. Maintainer. Owner. I was the only one in the room, which meant I was also the only one reading the room.
Documentation moved slower than it should have. Not because the writing was poor. Not because the process was unclear. But because one person moving through every stage of a workflow designed for multiple people creates a bottleneck at every turn.
And then something worse happened. Conceptual blind spots, assumptions I’d made about what a reader already knew, steps I’d considered obvious because I was the one who knew the product, baked into the canonical document. Because I owned the source of truth, the error became the truth. Nobody caught it. There was nobody to catch it.
The ownership problem nobody names
Here’s what I’ve come to believe about how documentation actually fails inside product teams. It doesn’t break at the writing stage. Most technical writers care about accuracy and work hard to get it right. It doesn’t break at the review stage, at least not always. It doesn’t break at the handoff between engineering and documentation. That’s a friction point, but a visible one.
Documentation breaks when no one clearly owns what happens next.
The product ships. The docs go live. The sprint closes. Three months later the product changes: a parameter is renamed, a step is deprecated, a new prerequisite is added. The documentation doesn’t change with it. Not because no one noticed. Because no one was assigned to notice. Ownership was assumed, which means ownership belonged to no one.
The SME relationship is where ownership actually lives
I talked about this once with Lucia, a technical writer with seven years of experience. I have been building a working relationship with her over the course of several conversations. She said something that stayed with me: depending on the company, some instantly make the SME available to you. In others, you have to make that move yourself.
SMEs are humans with emotions, and tightly scheduled ones. They’re not waiting for your questions. Getting accurate answers out of them isn’t just a process problem. It’s a relationship problem. The formal channel (a scheduled meeting, a Jira ticket, a Slack introduction from a manager) gets you access. But access is not the same as answers. The personal relationship is what gets you answers.
Because documentation is never a one-time conversation. As the product evolves, the questions multiply. A writer who has cultivated a real relationship with their SME gets those answers quickly. A writer who hasn’t waits. While they wait, the documentation drifts. Ownership lives in that relationship. When it breaks down, documentation breaks down with it.
How it compounds quietly, and why teams only notice too late
The insidious thing about the ownership problem is that it is invisible until it is not. Nobody notices because the system is designed to route around it: support engineers answer the question, Slack fills the gap, a senior developer onboards the new hire personally. The documentation problem is solved without the documentation being fixed. On launch day, the documentation is accurate. Six months later, the product has moved. The documentation hasn’t. But nobody filed a ticket. The support requests that referenced the outdated page were answered directly by engineers, which meant the documentation problem was solved without the documentation being fixed.
This is Documentation Entropy in its quietest form. Not a catastrophic failure. A slow drift. Pages that are ninety percent accurate. Procedures that mostly work. Instructions that were right once and are now slightly wrong in ways that cost users thirty minutes, an hour of confusion. Each instance is small. Accumulated across a documentation system with no clear ownership, it’s a liability that compounds every sprint.
The question every product team needs to answer, and almost none of them do, is not “who wrote this?” It’s “who owns this next?”
The ownership audit: Pick any page in your current documentation. Ask one question: if this page becomes inaccurate tomorrow, who is responsible for fixing it? If you can’t answer that with a name, not a team, not a role, a name, you don’t have a documentation system. You have a documentation snapshot.
The SME question that builds instant respect: Stop asking SMEs “How does this work?” Start asking “What’s the one thing users always get wrong about this?” That question shows the SME you’re thinking about their support load, not just your writing task. It builds trust faster than any formal introduction.
What’s next
In Part 4 we get into one of the most practically useful distinctions in technical writing: writing for developers versus writing for everyone else. Same information, completely different approach. Getting it wrong costs more than you’d think.
The Git & GitHub for Technical Writers series is the tooling foundation this series builds on. If you’re thinking about how ownership, version control, and CI/CD pipelines connect to what I’ve described here, that’s where to start.
Discussion