---
title: "Guest post: Generative AI, technical writing, and evolving thoughts on future horizons, by Jeremy Rosselot-Merritt"
date: 2025-11-06
description: "Where is this conversation now? What are technical writing’s vulnerabilities in this context?  Technical writing is a “text-heavy” field <a href="
canonical_url: https://idratherbewriting.com/blog/gen-ai-techcomm-evolving-future
---
# Guest post: Generative AI, technical writing, and evolving thoughts on future horizons, by Jeremy Rosselot-Merritt
Generative artificial intelligence is a relatively new technology that can “think” through questions and problems that we give it and often produce convincing (or at least convincing-sounding) answers based upon that process. The programs doing that thinking produce answers, known in AI vernacular as “inferences,” resulting from a complex series of calculations based on probability and human tweaking of supervised training on massive amounts of data and text. The systems that result are known as “language models” or “large language models” (LLMs) when built at scale.

As it relates to technical writing, I’m going to give some perspective on these questions: *What is the relationship between GAI and technical writing today? How can and do these technologies—particularly large language models (LLMs) like ChatGPT and Claude—affect technical writing as a field, and what might the future look like?*

Check out this [NotebookLM video](https://notebooklm.google.com/notebook/7ccc04f7-ed06-48e6-b9c8-978e73757133) if you’d like an interactive summary of this post.

## Where is this conversation now?

The conversation now really depends on how you look at it. For a technical writer, there’s an undeniable existential question: *How is ChatGPT [or another LLM] going to affect my job?*

For someone in middle management or executive leadership, the question is often about quality—*How can we use these tools to improve our documentation and communications?*—and efficiency—*Can these tools make us leaner (implying, of course, cost savings) and nimbler?*

Then there’s the perspective of academics, who will periodically investigate the questions of practitioners and managers yet also have to consider their own career needs around research and curriculum development. Those latter considerations can lead to “zoomed in” questions such as, *How can I study GAI as a potential “stand-in” for human agents in usability testing?* or, even more granularly, *What are particular linguistic qualities of LLM-generated feedback on emails at the word, phrase, and sentence level?* These questions, to be fair, may not address system-level issues of workplace application; but they are interesting and important in other ways.

Since I’m a technical writer by training, and since more of the existential questions about GAI affect practitioners the most, I’m going to answer the first question I presented above: *How is GAI going to affect my job?*

First, we—those of us in the field of technical writing—don’t really know the full answer to this question. Not yet. And it could take years for the “full answer” to become apparent. At the same time, it is the question that I hear from students most often, and it’s one of the most common questions that I hear when I talk to people in the industry.

I’m going to flesh out some ideas relevant to this question in the sections to follow, but if I’m giving a tl;dr version of my current response, here’s what it would be:

*Most of the evidence today, anecdotally and in practice, suggests that technical writing as a field will remain viable. At the same time, it is clear that GAI will directly impact the work of technical writers. It is also clear that trying to ignore or downplay the presence of GAI (even with the best of intentions) will not change that fact. The best, most evidence-informed suggestion I can make for technical writers is to learn more about GAI, how you can incorporate it into a work process that is still distinctly human, how you can effectively advocate for those adjustments with influencers and decision makers, and how you can center yourself as someone who has a unique knowledge-based skillset and a highly evolved understanding of context.*

Let’s unpack this a bit more in terms of the field’s vulnerabilities, strengths, and future possibilities—and as we do that unpacking, let’s give that tl;dr version of my answer some nuance that will be helpful as we look toward the future of our field.

## What are technical writing’s vulnerabilities in this context?

Our field has many strengths (which I’ll discuss shortly), but it also has some vulnerabilities. Those vulnerabilities create some baseline challenges that we’ve reckoned with for years, long before GAI came onto the scene. It’s important to name them.

### Technical writing is a “text-heavy” field

One of the most obvious vulnerabilities is that we are working in a field that involves a lot of text. Regardless of the deliverables you work with, you’re probably writing, editing, formatting, or posting it. And as it turns out, language models like ChatGPT are designed to generate text—lots of it, sometimes—from a single prompt. In many ways, it’s humanly impossible to keep up simply on the level of text production. Text, however, is only part of the story of technical writing—something I’ll return to when I discuss technical writing’s strengths.

### Technical writing is not always well understood outside the field

This is a problem that predates GAI, and it’s been a challenge for decades. A lot of people outside technical writing—even the engineers, programmers, accountants, QA specialists, and managers we work with—don’t fully understand what it is that we do. That’s true with the deliverables (“Don’t you all mainly just write manuals?”), the tools we use (“I don’t think I’ve heard of [InDesign, MadCap Flare, Doxygen, etc.], but even if I had, I couldn’t tell you what they really did”), or processes (“You actually interview subject matter experts to generate content to refine? And *then* you test that content with actual users?”). This compounds the challenge that GAI creates.

### Models of technical writing vary significantly among companies and organizations

Here we have a real “blessing and a curse” scenario that ties into another aspect of technical communication I’ll address later in this column: technical communication’s presence across many different economic categories—for-profit, non-profit, public sector, and cross-sector subcontractor/agency work. This multi-categorical nature of technical writing means that one person in our field may write documentation for cloud software developers, while another person may interview community members as part of a report on citizen use cases for a public park. Just as technical writing spans multiple sectors, the *models* of technical writing (how it is implemented in different organizations) vary widely, too, in terms of:

 - *Departmental placements.* Technical writers may work in a number of differently named (and, just as important, differently focused) departments. For example, in my own career, I’ve worked in departments ranging from Technical Publications in a pneumatic tools manufacturer to Research and Development in a metallurgical processing software and equipment supplier, from Communications in a health benefits company to Corporate Marketing, Project Services, and the Regulated Industries business group at a boutique engineering services firm. At the lattermost company, I had no fewer than six supervisors and shifted among three different departments over a four-year tenure.

 - *Reporting structures.* Starting out, early career technical writers often think they’ll work alongside other technical writers and be supervised by people with skill sets related to technical writing. As it turns out, both scenarios are possible, but neither is “standardized.” Thinking back again on my own career, I started working for a technical publications manager; she had a background in professional writing. At my next job, I worked for the compliance manager of a health benefits firm; at the next one, I worked for the business development manager, then one of the company’s owners (it was a small firm at the time), the project services manager, and finally the manager of regulated industries. In my last industry job before going back for my PhD, I reported to the vice president of research and development. These folks had degrees in fields ranging from English to electrical engineering and paralegal studies. A few had no college degree at all, had moved through a number of different roles themselves, and were excellent supervisors by and large. But the reporting structures in each company were vastly different in many cases, and the types of roles I reported to were quite variable. This is not unusual, but the implications for a technical writer’s experience are real.

 - *Distribution of technical communication labor.* How technical writers work together—*if* they work together at all—really varies. Some technical writers work together, side by side, in the same department for the same company. That’s common, and that may be how people relatively new to the field may envision things sometimes. It’s also common, however, that technical writers work apart in the same organization. For example, much like other knowledge workers (like data analysts) and creatives (like graphic designers), a technical writer is often dedicated to a specific workgroup or department—the B2B software team, for example. Another technical writer in the same company might work with a different workgroup—the B2C software team, perhaps. In practice, there are benefits and drawbacks to both centralized and decentralized models; but for the technical writer, the workplace dynamics can be quite different.

 - *The “lone technical writer” challenge.* This brings up another significant point, particularly in smaller companies or companies where documentation is sort of a newer or niche offering. There are plenty of organizations where the technical writer on staff is the only technical writer that organization has. Such scenarios often compound the challenges I discussed in this section. For instance, in companies where technical writing is not well understood or valued, there’s a possibility of shared, mutual understanding when more than one writer is employed, even if they’re in different workgroups. If such a company employed only a single technical writer, that mutuality goes away.

## What are technical writing’s strengths?

At the same time, even with those vulnerabilities, there are still significant strengths that we have as a field. In my view, those of us in technical writing don’t always account for at least one of them, making it even more important to reflect upon.

Technical writing is **not** “just” about text. This is probably one of the most important ironies of technical writing: what we do in this field is way more diversified than simply “wordsmithing” and “cleaning up paragraphs.” Though it flies in the face of some pop culture portrayals (think [Tina the Tech Writer](https://dilbert.fandom.com/wiki/Tina) from *Dilbert*), this is something I point out to a variety of different stakeholder groups: industry professionals outside our field, students in courses I teach in the major, academic colleagues who teach and research in the field. This is one assertion where academic research and workplace realities actually intersect, as technical writers frequently:

 - Create rich, often elaborate graphics for a variety of different purposes

 - Design complete training courses for HR and functional departments like sales, engineering, R&D, and so on

 - Manage projects

 - Learn more about particular nuances of a product or service they’re documenting than some of the subject matter experts know

 - Know as much about a company’s customers or external stakeholders (such as vendors) as anyone else within the company

 - Apply (knowingly or not) principles of organizational culture across different departments and stakeholder groups, serving as a knowledge linchpin within an organization

 - Possess a unique set of skills across domains that is notably difficult to duplicate, particularly for the amount of money that technical writers are often paid (decently, but not always at the rate of engineers, programmers, and some other roles).

Simply put, very few fields can claim this kind of breadth *and* depth.