Docs Are DevRel. Most DevRel Teams Don't Own Them.

A talk reaches a room, once. A video reaches an audience, mostly for ten seconds. The documentation of your product is read by developers every single day, at the exact moment they are trying to get something done.

That makes docs the most powerful asset in developer relations (DevRel). And at most companies, DevRel does not own it.

I've written before that DevRel has one product, and it's trust. This post is about where that trust is won or lost more often than anywhere else. Not on a stage. On a page.

Where developers actually are

Early in my time in this field I heard the best advice I know: go where the developers are, and bring them in. I've spent years applying that to cities, conferences and communities.

But if you count hours, the place where developers spend the most time with your product is the documentation. They are there when they evaluate you, when they get started, and when something breaks at two in the morning. And that last moment matters most, because that's when a developer decides whether you are worth the effort.

Nobody forgets the first time a getting started guide (the quickstart) doesn't work. They don't write you a complaint. They close the tab and try the alternative. No talk, however good, repairs that.

The ownership problem

Here is the strange part. Ask who owns the docs at a typical company and you get a different answer every time. Engineering wrote them, as an afterthought to shipping. A technical writing team maintains them, often far from the developers. Product marketing owns the tone. And DevRel is asked to promote them.

DevRel sits in the worst possible position: we hear the pain first, from the room, the community, the questions after the talk. We are the earliest bug report a company gets. But we can't fix what we hear.

So what do we do? We make a video that explains what the docs should have said. We write a blog post, give a talk, answer the same question in the community for the fortieth time. It's the work of patching a leak while someone else owns the pipe.

I don't think DevRel needs to run the whole documentation organization. But a DevRel team with no say in the docs is a team carrying water for a bucket with a hole in it.

Now the docs have a second reader

There's a new reason to care, and it's the one I wrote about in my post on the audience that isn't human.

When I build something new, I don't open the documentation anymore. An agent reads it, writes the first version, and tells me what it found. When something breaks, I ask the agent to fix it. I'm not unusual, and I'm getting less unusual every month.

Think about what that means for your docs. A model doesn't read them from start to finish, like a person. It pulls out pieces and uses them to answer a question. And if those pieces are wrong, outdated or unclear, the model doesn't just fail once. It repeats the mistake to every developer who asks.

Your documentation is no longer only a place developers go. It's the source material for what the world's AI systems say about your product. That's a much bigger job than most docs were written for.

What good docs look like for both readers

The good news: what helps the model helps the human too.

Every page should make sense on its own. A model pulls out one page, one section. If it only makes sense after reading the three pages before it, it fails for the model and for the developer who arrived from a search.

Complete, working examples. Not fragments with "add your code here." A full example, tested, that runs. A model will copy it, and so will a tired developer.

Real error messages. Write down the exact error text and what to do about it. It's what people paste into a search box or an agent, and it's the fastest way to be the answer.

Clear names, used the same way everywhere. If the same thing has three names across your docs, humans get confused and models get confidently wrong.

Say what's current. Dates, versions, and what's been removed. Outdated docs are worse than no docs, because they are trusted.

Give agents a way to act, not just read. This is where an MCP server (Model Context Protocol, a standard way for AI agents to connect to a service) comes in. Docs tell an agent how your product works. An MCP server lets it try. The best setups have both.

What a DevRel team can do this month

You don't need a reorganization to start. Five things:

Run the quickstart test. Every release, follow your own getting started guide as a new developer would, and give it to an agent with no extra help. Wherever the agent gets stuck, a human gets stuck too. It's the cheapest usability test there is.

Treat every question as a docs bug. Keep a list of what people ask after talks and in the community. Each repeated question is a page that failed. Then don't only report it. Fix it. DevRel people who send a docs fix are respected by both engineers and writers, and it's the fastest trust-building move I know.

Ask the models. Take the top twenty questions about your product, ask the big AI systems, and see what comes back. Wrong or outdated answers are a to-do list, and the fix is usually in your docs.

Turn your demos into samples. Everything you build to show on stage is a tested, real example. Most of it ends up in a slide deck and a repository nobody finds. Put it in the docs.

Agree on one shared number. Time to first success: how long from landing on the docs to something working. It belongs to nobody and everybody, which is exactly why DevRel, engineering and writers can all rally around it.

If you lead DevRel

Ask one question this week: who owns our docs, and how often do we talk to them?

If the answer is "nobody, and rarely," that's the highest-leverage fix on your list. It's not glamorous. It doesn't fill a room or produce a photo. But a developer who gets to a working result in ten minutes, without ever speaking to anyone at your company, has just had the best developer relations experience you can offer.

Nobody applauds a good docs fix. The developer just quietly succeeds, and tells a colleague.

Go where the developers are. They are in your docs. And now, so are the models.