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 that was designed for multiple people creates a bottleneck at every turn.
And then something worse happened.
Unwounded errors merged into the source of truth — blind spots that survived because no one attacked them during review.
Not typos. Not formatting issues. 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. And 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. Many teams have review processes, even informal ones.
It doesn't break at the handoff between engineering and documentation. That's a friction point, but it's a visible one. Teams know it exists and work around it.
Documentation breaks when no one clearly owns what happens next.
The product ships. The docs go live. The sprint closes. And then three months later the product changes — a parameter is renamed, a step is deprecated, a new prerequisite is added — and 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've been building a relationship with. 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. They're in sprint planning, in code review, in three other meetings before lunch. Getting accurate answers out of them isn't just a process problem. It's a relationship problem.
The best technical writers understand this instinctively. The formal channel — the email, the scheduled sync, the Slack message — gets you access. But access isn't the same as answers. The personal relationship is what gets you answers. And in professional settings, that personal relationship is built slowly, deliberately, through consistent contact and genuine curiosity about what the SME actually builds.
Because here's what most teams don't account for: 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 cultivated that relationship waits. And while they wait, the documentation drifts.
Ownership lives in that relationship. When it breaks down — or was never built — documentation breaks down with it.
How it compounds — and why nobody notices
The insidious thing about the ownership problem is that it's invisible until it isn't.
On launch day, the documentation is accurate. Six months later, the product has moved. The documentation hasn't. But nobody filed a ticket about it. 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 ten minutes, 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.
Infrastructure has owners. Infrastructure has maintenance schedules. Infrastructure has someone who gets paged when it breaks.
Documentation should have the same. Not because it's as critical as a production database — but because the cost of unowned pages compounds quietly, invisibly, until it surfaces as a support ticket, a confused onboarding call, or a developer asking a colleague instead of checking the docs.
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 changes the dynamic immediately. It 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. And why 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