Two strategies to succeed when AI seems to be eroding jobs around you
- Introduction
- Role changing from tech writer to content director
- Subject matter expertise
- Tools expertise
- An argument for future optimism
- Conclusion
Introduction
About a month ago, I had coffee with a friend who teaches technical writing at a university. After my latte was gone and we’d talked about so many topics, he asked if I would write a blog post offering advice for academics and students, given the current AI trends and context. I’d been explaining that most corporations are fully on board the AI train, and most employees need to be on it as well to thrive. This stands in sharp contrast to how AI is often treated in academic settings, where it’s banned or where academics often discourage it because it shortchanges the learning process. Although a month passed since our coffee chat, I’ve finally settled on what I want to say!
But first, a little more background about the current environment and AI context. Just last week at my work, we wrapped up an internal conference for tech writers, where there were nearly 20 talks on AI. Post conference, we had a 15+ person discussion reflecting on the conference’s AI themes and the larger takeaways. It was one of the most lively and well-attended group discussions we’ve had. To prepare for this discussion (which I facilitated), I ingested all the AI-themed talks through NotebookLMs (something I’ll expand on later) and then looked at salient themes.
The signs are everywhere, and there’s real anxiety about how this all plays out in five years. For example, this morning I opened the WSJ to see this article: Walmart CEO Issues Wake-Up Call: ‘AI Is Going to Change Literally Every Job’. The article doesn’t leave you feeling good about the future.
In this post, I’ll tackle this question: What strategy should we follow to land safely on the other side? More specifically, as our role changes from writer to director, what characteristics will be most helpful to thrive?
First, I should acknowledge, in the spirit of humility, that no one knows the future, and if the past provides any lessons, it’s that the future usually surprises us. I don’t pretend to have certainty about how to safely navigate job erosion amid growing AI. What works for one might not make sense for another, especially across different specializations and domains. But I have tried to sort and organize my thoughts on the topic, and would like to share them here, if only for myself.
Role changing from tech writer to content director
The most salient theme of our internal tech comm conference was that the role of the technical writer is changing to more of an editor and content director. Instead of writing docs, I now write prompts and steer the AI to write docs, do analyses, generate content, fix bugs, and more. Honestly, I rarely write tech docs from scratch anymore.
In our new role as content editors and directors, what skills will help us excel? There are probably many relevant ones, but rather than provide a laundry list, I’ll focus on the most important two: developing subject matter expertise and tool expertise.
Before jumping into these two areas, though, let me acknowledge and address some other skills. These might be considered foundational skills. They’re still important, but they aren’t going to be the killer skills.
Editorial judgment
Editorial judgment is a skill that many seasoned writers already possess, but they have probably forgotten they have it. Your editorial judgment allows you to evaluate when AI’s output is good or bad, and how to adjust content to fit into a larger landscape of information. This is basic writer awareness, which shouldn’t be minimized, but it’s something we often overlook when assessing our skillset.
Many of us already have writer’s instincts that help us evaluate content as an editor and publisher, so I won’t dwell on this here. I’d say, listen to your instincts about content. Not just about language, but about the overall quality, shape, and arrangement of information. Trust your instincts. I like to think of this editorial judgment as being similar to that of a New York publishing house editor working with a writer. I’m able to focus on areas that need improvement while recognizing other parts of writing that are working well.
Prompting and workflows
Another key skill is with prompting itself, knowing how to approach problems with the right methods and prompts, and understanding the scenarios where AI excels and where it will likely fail or produce errors. I mostly address the AI hallucination situation by finding a context of truth for content, such as adding the API reference, changelist, or other trustworthy information to ground my AI sessions. Most of my strategy around working with AI isn’t in crafting specific prompts but rather figuring out the right contextual info to add to the AI session.
Besides context, understanding the right workflow to approach problems is also important. This often involves breaking documentation projects down into a series of steps through a larger, more complex workflow.
Although AI is getting better at understanding one’s intent and generously handling even poorly articulated requests, there’s still a strong need to steer and direct AI tools. Especially when tackling complex problems, you need to think about how to navigate through them. In general, learn how to break down projects into smaller steps, how to write clear prompts, and how to provide the necessary context for the AI to have the right information.
I wanted to at least acknowledge these two skills, even if they aren’t the focus of my post here. While important, I don’t think they’re necessarily going to be all that salient in distinguishing our skillsets from others and keeping us employed. There are plenty of hacks who can do a good enough job in these areas that it’s not something to ground your core value in.
Now let’s move on to the two skills I want to emphasize: subject matter expertise and tools expertise. Developing expertise in these areas will help tech writers stand out in noticeable ways.
Subject matter expertise
Subject matter expertise gives you the ability to properly vet an AI output’s accuracy. Subject matter expertise, both for the products you document and the domain you’re operating in, allows you to better iterate with AI outputs, to know when the outputs are suspect and need more QA, and more. I wrote about this in my post Why attitudes and experiences differ so much with regards to AI among technical writers. In it, I noted that AI has a “jagged edge,” where those with subject matter expertise can achieve much more proficiency and output with AI. This is in contrast to someone who lacks that knowledge and can’t evaluate, iterate, and adjust the prompts or strategy on the fly based on the quality of the output they’re seeing.
How do you improve your subject matter expertise? There are many ways to learn, but recently I’ve been accelerating my learning through NotebookLM. I have a goal of watching 5 NotebookLM videos or podcasts a day about work-related subjects and tools. For example, a product manager might share a long conceptual document about a particular feature, often as context for features and focus on the product. I drop these kinds of docs into NotebookLM and choose the Studio’s video and podcast options. Then I watch or listen to them at different times of the day — maybe when I want a break, I’ll watch the video, or while driving or walking, I’ll listen to the podcast.
I don’t know how to say this with enough emphasis, but NotebookLM is phenomenal. The videos are truly game-changing, especially with a recent level-up on the visual side. I mentioned at the start of this post that I ingested nearly 20 AI-related presentations at an internal conference. I only watched a few live; the rest I consumed through NotebookLM explainer videos (usually about 6 minutes) at an accelerated pace.
I find I don’t often have the patience to sit through a lengthy presentation. I prefer a more compact, direct version of the information, and also like to consume it while I’m biking, walking, or doing something else. With the videos, I can simply sit there for 6-7 minutes due to the captivating visuals. Also, the NotebookLM videos often organize and present the information in a much better way than presenters do. These videos are kind of my secret that I’m leaning on as a way to succeed.
The videos and podcasts have another effect: they make my job a lot more interesting. The other day, I pasted a “partner updates” email from our partner engineers into NotebookLM, and I was captivated by the way the hosts presented the information. I both listened to the podcast and watched the video version of the info, thinking about how I’d somehow missed these updates before and wondering why, given how valuable they were. So I went back and actually read the email, only to see the info presented in such a dry and curt way — I could hardly believe it. The NotebookLM learning resources had brought the info to life in such a compelling way. It blew me away. This is why I say the videos are often better than the live presenter.
As I gain a deeper understanding and expertise in the subject, my job is scratching an intellectual itch that technical writing has often lacked. Even learning about regulations (for example, the General Safety Regulation’s Intelligent Speed Assist) that I thought were somewhat dull has suddenly become fascinating. The learning component makes my work interesting on a deeper level, which helps prevent burnout and boredom in the role. This is one reason I like the videos and audio so much — for the hosts, they make any subject seem important and interesting.
To give you a sense of these video overviews from NotebookLM, here’s a notebook generated for this post you’re reading. (Click the video link in the Studio section on the right.)
Tools expertise
The second skill to emphasize is tools expertise. At my workplace, there’s a Precambrian-like explosion of AI tools right now. I mean, it’s so intense that people are building tools that serve as oracles about which AI tools to use. In our AI tools subgroup, someone has compiled a sheet listing all AI tools available, and there are around 60+ rows of different tools.
The most frequent question we see from tech writers is for help about which AI tools they should be using in which situations, and so on. You’re probably familiar with the Gemini web app and Gemini integration with code editors. But there are also specialized AI tools integrated in every aspect of the workflow, from issue tracking systems to changelist reviews to project management tools to Google Docs, the command line, and more. In other words, you’re not just limited to the major tools; there are micro/specialized AI tools integrated everywhere.
In Deep Work: Rules for Focused Success in a Distracted World, Cal Newport says that highly capable people don’t just engage in deep work; they’re also proficient with powerful tools that allow them to amplify their abilities. He says Nate Silver, famous for his predictions, doesn’t just do deep work; he uses sophisticated database queries, algorithms, and other advanced techniques that allow him to get to the level he’s at.
The better we are with tools, the more capable we become because tools amplify our human-limited abilities. Because of this, I’ve started devoting more time to simply becoming more familiar with the many AI tools, features, capabilities, workflows, etc., available to me. In doing so, I realize how much there is to learn.
The more I learn, the more empowering it becomes with documentation scenarios. For example, in reading through updates and other documentation for Gemini integrated into our authoring tool (the same VS-Code Studio-based IDE that developers use to write code), I realized that Gemini could actually read images in my code editor. By default, if I drag a folder with images in it into AI’s context, Gemini will omit the images from its content ingestion (most likely due to token constraints). But if I explicitly add an image to its context, it will read the image.
This was super helpful because it means I can keep my IDE context for the AI workflows without resorting to using the external Gemini web app to read images. (Remember how I said context is everything? You want your API reference files as context, but you might also have whiteboard diagrams or other images you want to leverage, too.) Details like these help me become more proficient with tools and, in so doing, make my job easier.
Even understanding the different tools available with different AI modes is important. For example, in chat mode, certain tools are available to read bugs and threads, but not in other modes. This is helpful to know if you’re trying to collect a list of bug fixes for release notes, and so on.
I’m now experimenting with Gemini integration on the command line and trying to better understand the tools and capabilities available there that aren’t available elsewhere, such as MCP server access, larger token limits, command-line capabilities like running build commands, and more.
An argument for future optimism
While no one can predict the future, and despite clear signs that AI is eroding jobs (or keeping hiring flat), I’m optimistic about how it all plays out for technical writers. In this section, I’ll make the case for an optimistic future.
Because AI is so good at coding, we’ll see the Precambrian explosion of tools and technology that I mentioned earlier. Technology will beget more technology in a rabbit-like reproductive explosion. This is technology accelerating at a more exponential rather than linear scale, as Kurzweil argues.
And while yes, many of these tools will automate work and possibly remove some roles, many new tools, apps, and technologies are also being developed. Much of this new technology, which can be complex and overwhelming, needs documentation. People need training, information, and systems that explain how to use it all.
If there’s one trajectory to bet on, it’s this: the future will have more tech. Since the inception of technology, tech has only been growing and expanding and filling every nook and cranny of the earth at an accelerating pace. In What Technology Wants, Kevin Kelly describes the “technium” as a living organism that is expanding like a kind of bacteria or algae filling all the earth. What’s especially unique about AI tools is that they’re general purpose building tools (as both Kurzweil and Suleyman note), meaning they can be used to build technical solutions across many domains (not just in IT but in healthcare, environmental, science, education, and more) rather than advancing just a single domain.
We’re living in a technology-saturated world that is only on pace to be more and more technology-dense. In this future, it seems unlikely that technical writers will become obsolete. Even with all the AI tools being developed at my work, which might be like a microcosm of the future, there’s still a strong need for documentation. For example, as powerful as the Gemini command-line tool is, its documentation is among the worst, with many tech writers taking up the charge to fill in the gaps.
Sure, robots will do some of the technology work, but new tech work will sprout everywhere, in the form of new platforms, new apps, new analytic tools, and so on. The tech jobs that are automated will be offset by a growing number of non-automatable tech jobs, as companies compete at a faster and faster pace, cranking out so many tools and updates that the world will feel inundated and overwhelmed by the breathless pace.
We often hear that AI will free us up from mundane tasks to focus on more strategic work. When I hear this, in my mind I picture someone who has finished their work by early afternoon and is now reading or tinkering on some hobby project. This image couldn’t be further from reality. AI is accelerating everyone around us, so now, instead of 5 incoming bugs a day, you might be receiving 10. And next year, 15, and the year after, 20. Meanwhile, hiring stays flat. Because AI is accelerating everything, it’s making us busier, not enabling blocks of free time on our calendars.
Finally, competition is also contributing to the acceleration. Consider this example from the auto domain. China’s electric vehicles have more advanced technology than many American and European cars, including lane-aware technology. This puts pressure on American and European automakers to level up their tech platforms and navigation systems as well to compete. This, in turn, puts pressure on technology suppliers and map integrators providing this tech to the American and European automakers. This pressure and pace trickle down to engineering teams building more software. Which in turn means a role for technical writers to crank out release notes, API documentation, and other materials to support the many features engineers are building.
Note that I said I’m optimistic about the need for tech writers in the future, not about a utopian future itself. It’s good that technology is expanding and proliferating at an accelerated pace if you’re in the business of documenting said technology. But the future might be entirely dystopian. We could be mired in AI drone wars, massive cyberattacks, delusional chat spirals, manipulation and disinformation campaigns, social upheaval due to unemployment waves, and more. We might hate our technology-saturated future, but it’s likely that we may keep our tech writing jobs.
Another argument for the relevance of tech comm
Finally, I haven’t even pitched the strongest argument for why technical writers and documentation will continue to be relevant in the future: AI tools are terrible without good documentation. In the same way that you need valid, accurate context when using AI tools to create documentation, AI tools need an accurate body of documentation to produce useful, hallucination-free outputs. Informal tests by my colleagues show that AI outputs improve by orders of magnitude when trained on more abundant and accurate documentation.
Fabrizio Ferri Benedetti makes this argument in his post, AI must RTFM: Why technical writers are becoming context curators. He says developers are starting to write more documentation because “AI must RTFM now.” This new “docs-driven development” approach means technical writers should “seriously start thinking about becoming context writers and maintainers.”
Ferri Benedetti defines this role as follows:
A context curator, in this sense, is a technical writer who is able to orchestrate and execute a content strategy around both human and AI needs, or even focused on AI alone. Context is so much better than content (a much abused word that means little) because it’s tied to meaning. Context is situational, relevant, necessarily limited. AI needs context to shape its thoughts.
In other words, technical writers will create and package information specifically for AI consumption, ensuring the AI has the necessary context to produce accurate and relevant results.
There’s a sales motive for keeping technical writers around, too. Let’s say an external developer needs to create, say, a mapping application for their project, and they decide they need routing logic. Following a vibecoding approach, they integrate your company’s MCP server into their IDE and tell their AI tool to create an app that draws routes from one point to another. If the AI tool can successfully fulfill the developer’s needs, requiring only that they provide an API key (which then initiates billing), the company that has provided this solution will sell more API services. No one wants to fiddle and fuss with hard-to-configure technology that doesn’t work, and by hard-to-configure, I mean APIs that require manual configuration rather than APIs you can configure with natural language.
Conclusion
In conclusion, there are many strong signs that technical writers and documentation will continue to be relevant in the future. There’s no certainty about any course of action, and no single tool or method you can learn that will future-proof your career. My advice to focus on becoming (1) a subject matter expert in your domain and (2) a tools expert is really similar to the age-old advice that the most valuable takeaway from your education is to learn how to learn.
So that’s what I would encourage students and teachers to focus on: learn how to learn. Does it matter what particular tool or approaches you’re learning? Not so much, although one would hope it would be AI-related. But conditioning your brain to continually process new information and to be self-disciplined in a way that you’re hungry to keep feeding your brain new information will help you adapt to a constantly changing world where the landscape and dynamics change monthly.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.