# You already have docs, you just don't know it yet

> If your company's knowledge is scattered across multiple places and nobody owns it, sooner or later that knowledge debt will cost you money. Here's why you should hire a tech writer, and what a tech writer even is.

_Published September 14, 2026 · https://marcioflorindo.com/you-already-have-docs.html_

Every company has documentation, even the ones that think they don't. It's in the support threads where someone explained the same fix for the third time, or in the wiki page about the edge case only a handful of customers ever hit. It's in the sales deck, the onboarding email, and the corner of Jared's head he keeps meaning to write down and never does.

So the knowledge exists. The problem is that it's scattered, and nobody owns pulling it together. A lot of companies never realize that's a job, because they think documentation is just "writing": someone sitting down to produce a manual once the product is built. That's a much smaller part of the work than it sounds.

## What the job actually is

Writing is only part of what a technical writer does, and not even the main part. Most of the job happens before anyone types a word.

We're the people who own a company's knowledge. Making sure it's organized instead of scattered, that what lives in one person's head ends up somewhere you can search for it, and that a support ticket answered once becomes an answer the next customer finds on their own instead of opening a second one.

Most of that comes down to asking questions. Because we work across teams, we often see the whole picture before the product managers and engineers do. We're the ones who notice that the feature one team is building has to talk to the thing another team shipped last month, and that nobody checked. And a lot of us aren't engineers, which turns out to be useful: we can play the confused user, ask the "obvious" question, and watch an assumption nobody knew they were making fall out of the answer. Then we write it down so a stranger can act on it without us in the room.

That's the part people miss. Most folks could write a paragraph, but the real work is figuring out which paragraph needs to exist at all.

## What it costs to skip it

Here's the obvious objection: the engineer already built the thing, so surely they're the one who should document it.

Two problems with that. Engineering teams are usually underwater. There's always another feature to ship or a bug to chase, and the docs are the first thing to slide off the list. And even if you have an engineer who genuinely likes writing docs, they'll have blind spots because they're too close to it. They built the thing from the inside. They can't easily see what a first-time user won't understand.

Here's the cost in its smallest form. A customer can't figure out how to do something, files a ticket, support unblocks them, everyone moves on. A few days later a different customer hits the same wall and files the same ticket. If that answer had lived in the docs, the second ticket never happens. One ticket is nothing. But multiply it across every recurring question, and across every customer who didn't bother to file at all and just left, and you're paying for the same problem over and over, money that could have gone somewhere else.

Documentation earns its keep before the sale, too. A buyer still deciding between you and a competitor uses your docs to work out whether the product does what they need. They answer the question before it becomes a ticket, and sometimes before the customer is even a customer.

## So do you have this problem?

If nobody at your company owns the knowledge you're producing, you probably do. You just haven't named it yet.

You don't hire a technical writer because it looks good on the org chart. You hire one when the knowledge is piling up faster than anyone can organize it, when your engineers are the bottleneck on docs nobody has time to write, when it's already unclear which of four pages is the one people should actually follow.

That last one is knowledge debt, and it builds up quietly until nobody can tell which document is current and which is three product versions out of date. You're already paying for that knowledge to be managed, one way or another. The only real choice is whether you do it on purpose.