Writing is the output. This is the work

The label I've been using for five years, "technical writer," is accurate and fundamentally misleading at the same time.

Accurate, because I write. Misleading, because writing is the output, not the work.

The mismatch

Look at the things I'm actually proud of from the last five years. None of them are pages.

The research workflow I built compressed documentation research from 2–3 days to about 60 minutes, not by writing faster, but by building the system that made context-gathering automatic. The product rename I led delivered 695 files across four products in three days, zero 404s in production, not because I worked faster, but because I designed six AI-assisted tools and a Python redirect validator that made the whole operation possible. The troubleshooting redesign that addressed the largest support category for the product area started with analyzing 753 support escalations to find the pattern, not with opening a blank doc.

In each case, the writing came at the end. The real work was figuring out where the knowledge was failing and building the infrastructure to fix it.

"Technical writer" describes what I produce. It doesn't describe what I do.

What the work actually is

I find where complex products lose users to confusion, and I build the systems to close that gap at scale.

Writing is part of that; I enjoy it, and documentation is almost always the right tool for this problem. But what I find myself most drawn to is the diagnostic phase: figuring out what's broken, what pattern of confusion is driving the most support tickets, what users are failing to find that's already somewhere in the system. Once that's clear, the writing comes fast. The interesting part is the problem.

That also explains what I find most draining when the job goes wrong: pure execution mode: writing pages in response to requests, no connection to the underlying problem. That's when it feels like the wrong use of time.

Documentation as infrastructure

At Cloudflare, our docs team operated from the conviction that documentation is a product, not something you bolt onto a feature after shipping it, but something that directly shapes adoption, support volume, and whether users can do what they came to do. That means talking to support engineers, reading escalation data, looking at instrumentation. You design it, not just produce it.

Documentation has also shifted from reference material to infrastructure. It's increasingly the interface AI agents use to understand products: to generate implementations, answer customer questions, and reason about what's possible. Accurate and well-written isn't enough anymore. It needs to be architected: structured for retrieval, reliable under automated consumption, intentional about what it exposes and how.

I've been building for that for the past year (AI-native workflows, semantic content architecture, systems designed to be machine-readable as well as human-readable) without a clear name for it. "Knowledge infrastructure" is closer than "technical writing."

What's next

I'm not certain yet, and I'm trying to be honest about that rather than performing certainty I don't have.

The next interesting problem probably doesn't look like "write the docs for this product." It looks more like: here's a domain where users keep failing to self-serve and nobody knows why. Or: here's a knowledge system built for humans that AI agents are now consuming, and nobody designed it for that. Those problems exist in tech companies, but also in law firms, healthcare, financial services, and government: anywhere managing complex knowledge while AI is changing how that knowledge gets used.

I don't know which of those contexts I'll end up in. But I know where I want to spend my time: on the diagnostic part, not just the writing part.