Why I became a Documentation Engineer (and what that even means)

A reader asked me how they’d become a Documentation Engineer, because they saw I got hired as one and felt curious about what it takes to get there. This inevitably got me thinking about job titles and the evolution of tech writing, two topics that are quite central to this blog. Let me begin with the short answer: As a tech writer you’ll have to wear many hats, but you’ll always be a technical writer. Depending on your preferences, some hats will be more comfortable than others. Docs Engineer is one of those.

What’s a Documentation Engineer?

As a Documentation Engineer, I’m expected to have a decent understanding of code in several of the programming languages we use at work, be able to use developer tools and developer environments, write code samples, automate the boring bits of my work, and support other developers in their writing quests as a devling. The other day, for example, I added a new feature to the docs site with the help of AI. This required understanding the stack where I added the feature. I wasn’t just praying to the AI gods.

Does this mean that I’ve stopped writing documentation? Not at all! I still document procedures, and I even support designers when they need UI text. I take care of rallying teams to fill out the changelog and I also look after tools that’d help foster contributions, such as templates and linters for our style guide, which I developed. The emphasis, though, is on being technically proficient enough so as not to require constant hand holding by engineers while at the same time asking them the right questions.

Wearing this hat requires a deep love for technology and engineering, as well as hands-on knowledge. I’ve been orbiting around programming for all my life, much like a sports journalist circles around players. And that’s actually fine, because the purpose of what I do is bridging the gap between people and tech in a way that developers alone can’t do, because they’re too deep into what they’re building. Docs are key infrastructure work and I feel happy to assist my colleagues with coordinating that effort.

But wait! My job title wasn’t Documentation Engineer before, even if I could do the same things I’m doing now. So why am I working as a Documentation Engineer instead of, say, Technical Writer or Programmer Writer? For two reasons: first, the company that hired me chose to frame my profession in a certain way that I immediately felt a connection to. Second, because software technical writing has been evolving and specializing alongside the craft of software engineering.

The Maker-Storyteller crossroad is becoming stronger

I’ve developed the impression that, as humanists in tech, technical writers are constantly subjected to the pull of two separate forces. One is eminently technological, embodied by the Developer-Maker; the other is communicational, represented by the Writer-Storyteller. I see you muttering “Woz & Jobs” in glee while reading about those profiles, and you wouldn’t be too far off, despite how trite those stereotypes have become over time. For the sake of the discussion, let’s assume that they’ve always been there.

If you represented both forces in a diagram, you’d get something like the following: the Developer strain diverging from the initial trunk towards more engineering-colored shades of writing, and the second strain, the Writer’s, moving towards meaning and connection and away from explaining buttons and menus. As UIs become more self-explanatory, and coding more accessible, writers pursue deeper specialization, and so the tech writer becomes an API writer and then a Docs Engineer, for example.

I think it’s still entirely possible to remain at the center as a full-stack writer, but it’s becoming harder due to the way job titles convey expectations and foster teamwork. It’s easier for tech writers to embed with engineers if they carry the engineer sobriquet, as it’s simpler to work with designers if you attach the UX patch to your business card. It’s all meant to say “I understand and respect your work, let’s collaborate”. And since technical writing is a landing pad, switching between those sides isn’t impossible.

Corporate cultures also have something to say about this trend. You can find Programmer Writers at Amazon and Microsoft, and Documentation Engineers at Meta and companies focusing on developer experience. Companies with strong product thinking often hire Product Writers, an umbrella term for someone who tends to words across the entire product surface, from docs to UI text to localization. Companies and teams also look for profiles which may best fit into their ecosystem.

Choose Your Own Adventure, Writer!

We writers have our own preferences, of course, and I think that is all that matters. In my case, I’ve found myself gravitating towards increasingly technical roles because I deeply enjoy the Maker side of technical writing and I like developing tools that facilitate and enhance documenting code. I doubt I’ll ever become a software engineer, though. (What will that mean in the LLM-augmented era anyway?) I think I’ll still feel, and be, a writer ten years from now. Or perhaps a technical therapist in 2049. Who knows.

The evolution of technical writing mirrors the broader evolution of technology itself - becoming both more specialized and more interconnected. Just as the venerable webmaster role fragmented into countless specialized positions, we’re seeing technical writing branch into roles that lean heavily into either engineering or storytelling. Yet the core mission remains unchanged: we’re here to make technology more accessible, understandable, and human.

If you can and want to become a Documentation Engineer to help accomplish that mission, then go ahead! Whether you gravitate toward building docs tooling or crafting user narratives, you’re still part of a profession that bridges the gap between humans and machines. And in an era where AI is reshaping every aspect of our work, that bridging role becomes more crucial than ever. The title on your business card might change, but the essence of what we do - making the complex clear - endures.