If you tell someone you’re a Technical Writer, they roughly know what that means. If you say you’re a Docs Engineer, you’ll usually get a blank stare — or an assumption that it’s the same thing with a fancier title.
It isn’t. And the distinction matters — both for hiring managers building documentation teams and for the developers who end up relying on the output.
The short version
A Docs Engineer is someone who approaches documentation the way a software engineer approaches a codebase: with tooling, automation, architecture, and a strong opinion about what “done” means.
The writing is still there. But it sits on top of a layer of engineering work that most technical writers don’t do and most software engineers don’t want to.
What the day-to-day actually looks like
Here’s a non-exhaustive list of things I’ve done in the last month that fall squarely in “Docs Engineer” territory:
- Audited an OpenAPI spec and wrote a script to flag undocumented endpoints before they hit production
- Set up a docs site from scratch using Astro — configured routing, search, versioning, and a CI/CD pipeline that deploys on every merge to main
- Wrote an integration guide for a banking API that required me to actually build a test integration to verify every code sample was accurate
- Reviewed a product changelog and rewrote it from an engineering-internal format to something a developer integrating with the API would actually understand
- Updated 23 endpoints’ documentation in a single PR because the auth model changed and the existing docs were silently wrong
Some of that is writing. Some of it is engineering. Most of it is both at the same time.
Where it differs from traditional technical writing
Technical writers are often embedded in a content or marketing org, producing documentation alongside product managers and UX writers. The focus is on the written artifact — the guide, the reference page, the tutorial.
A Docs Engineer tends to sit closer to the engineering team. The focus shifts:
| Technical Writer | Docs Engineer |
|---|---|
| Writes the docs | Writes the docs and builds the platform they live on |
| Works from engineering specs | Reads the actual source code |
| Reviews with editors | Reviews with engineers |
| Ships a document | Ships a docs system |
| Manages content | Manages content and tooling |
Neither approach is better. They serve different product stages and different team structures. But when you’re building developer-facing products — APIs, SDKs, CLIs, platforms — you usually need someone who can do both.
Why the software development background matters
The biggest practical difference between a Docs Engineer and a Technical Writer is that a Docs Engineer can verify what they’re writing about.
When I document an API endpoint, I don’t just read the spec and transcribe it. I make the actual request. I look at the actual response. I handle the actual errors. If something in the spec is wrong — and it often is — I find it before a developer does.
This matters enormously for developer trust. There’s nothing that erodes confidence in documentation faster than a code sample that doesn’t run, or an error code table that’s missing three entries. Developers will stop trusting the docs — and then they’ll stop reading them.
Being able to write, test, and iterate on code examples is not a nice-to-have. For API documentation, it’s the job.
The meta-skill underneath all of it
Whether I’m writing prose, designing information architecture, or debugging a broken docs pipeline, there’s one underlying skill that makes everything else work: the ability to understand something deeply and then explain it as if you didn’t.
That’s not a writing skill. It’s not an engineering skill. It’s an empathy skill — the ability to model someone else’s mental state accurately enough to meet them where they are.
It’s also the hardest part of the job.
If any of this resonates, I write regularly about documentation, developer experience, and the craft of technical communication. Follow along on the blog or reach out directly — I’m always happy to compare notes.