Podcast 164: Trends in technical writing careers for 2026 and beyond

In this episode, we explore how AI is reshaping the technical writing profession and what skills will matter most in the coming years. While AI dominates the conversation about the future, we dig deeper into what this means for technical writers, documentation strategy, and career development.

Summary:

The role of technical communicator is evolving from document creator to strategic orchestrator of complex information ecosystems. Success requires:

• Proactivity: Identify problems and initiate solutions rather than waiting for direction
• Strategic thinking: Design information experiences, not just documents
• Technical depth: Level varies by organization and documentation type
• Data literacy: Evaluate success through analytics
• Persuasion: Influence stakeholders and gain buy-in for your vision

The person filling this role might come from technical writing, UX/UI, content strategy, or training backgrounds, whoever can demonstrate the necessary skills first.

Transcript

Hello again. Every year, we do a podcast on the trends for the next year and beyond. And we were in two minds about doing that type of episode this year because in many ways, the answer will be AI.

However, we were asked at the TCUK conference by a number of people if we were doing a trends episode. And there have been a number of articles around the future of the career of the technical writer, or technical author, as it’s called in the UK.

So this episode is going to be about trends for 2026 and beyond, with a focus on whether the job and the career of being a technical writer, being a technical author will change. We might not have the answers today. Sometimes it’s important to be asking the right questions so that the correct answers emerge over time.

So let’s start not by talking about technical writing, but talking about UX and UI, user experience and user interfaces.

In November 2025, Jakob Nielsen, who’s seen as one of the gurus of usability and user experience, wrote an article where he said that Google’s Nano Banana Pro was the ChatGPT moment for visual communication. Nana Banana Pro is a AI tool where you write a prompt, and it can create a visual for you. He wrote;

This advancement will transform how we explain complex information and flood digital media platforms with millions of images every day. Traditional handcrafted UX methods are becoming irrelevant as AI takes over low-level tasks. Mid-sized UX agencies will vanish, replaced by small high end guru boutiques and low-end automated providers.

So, the question is, will something similar happen in technical writing?

As the tools develop, will it be possible for pretty much anyone to create professional documentation just by using a prompt automatically. And will that lead to a need for high end consultants who can advise and direct and organisations that can provide, as it were, sausage machines that can automate and process content automatically. So what will that mean for the need for freelancers who often come in to deal with a backlog that’s built up, and for interns and junior technical authors who are often given low-level, time-consuming tasks when those types of activities could be done potentially by an AI system?

What Jakob Nielsen proposes for the future is a future where the user interface is adapted to each user. What will that mean for documentation? When every user gets their own distinct personalised application, customised tailored to them. Nielsen suggests that in the future, UX professionals and UI professionals will need skills in agency, judgement, and persuasion.

Agency refers to the initiative to act and tell the AI what to do. Humans with agency, he says, will be the ones who identify problems, add opportunities, and direct AI to work on them. People who wait to be told what to do will struggle, while those who exercise initiative will be the most valuable employees.

And by judgement, he says AI can generate a multitude of options. For example, ten different screen designs or countless ideas very quickly, making the creation of ideas essentially free. The uniquely human skill of judgement is required to evaluate these options, decide which ones align with the overall goals and human values, and determine what good looks like in a given context.

And persuasion. He says the modern workplace is still a human ecosystem, and even the best ideas and judgments will fail if others do not buy into them. Persuasion is necessary to convince stakeholders, colleagues, and management to support ideas and recommendations, ensuring that the work guided by agency and judgment actually gets implemented. So he’s saying while AI excels at traditional hard skills, like visual design and he says writing and data analysis These human centric soft skills are what will define a successful career in the future.

And we’ll provide a link to Nielsen’s articles in the show notes. And in the show notes, you’ll also find a link to a post on the Google Research website about generative UI. It starts: we introduce a novel implementation of generative UI, enabling AA models to create immersive experiences and interactive tools and simulations, all generated completely on the fly for any prompt.

Someone else who has been posting is Anandi Knuppel, PhD. She was until recently at Amazon. She’s written a post. She says it’s about her thoughts about the new technical writer, how things are shifting for this role, and some questions to get us going in new directions as a field. Her post or article is called the engineering of the technical writer.

Let me quote from that.

Many positions that I’ve seen listed and interviewed for are quite keen to have someone who can work with AI, either for products or for boosting productivity and accuracy in workflows and pipelines.

What concerns me more is not necessarily the AI tooling pickup. Often, there’s a change in basic tech requirements that people need to learn, but it’s the engineering ask that I’m seeing more of right now. Many positions, whether explicitly or not, really want an engineer that can write or learn the writing on the job. Either way, using generative content in one way or another, not a writer who can tool up to be an engineer. AI tools are moving the floor up. There’s more being expected of writers, and I worry that junior roles, just like they are in engineering, are going away. And this was posted on LinkedIn and led to a number of comments from various people along the lines of discussions about how do you get hundreds of engineers to do documentation the way the organisation wants, willingly? Who is going to be thinking about the next new in documentation if it’s being done by AI and engineers?

And related to that, who will be the architects of understanding, setting the strategy, the vision for the future? Will everything revert to the mean, to the mediocre?

There were some other comments on the thread. I think these were from Fabrizio Ferri Benedetti.

Let me read them out.

There will be a rehiring in the next year along these lines and for a few other reasons as well. There are only so many domains one can be an effective expert in, and while engineers with great AI tools can do a lot, there needs to be a writer with that domain knowledge and expertise to steer the content. Otherwise, customer experience and LLM experience will suffer along with product satisfaction and adoption.

The basis of the craft is changing. Being a good writer, whatever the field, takes time and training. It’s a field of instruction. Pedagogy, information stewardship is part marketing, education, support, and engineering. By definition, it is different from being an engineer. But now that market is demanding both roles in one, this is a new demanding environment and market. But there is a huge opportunity for us as technical writers to think bigger about this role and at the top level. What does a full stack docs strategy look like? What information architectures do different docs portals need? And how can we implement front ends to maximise that structure for best in class user experience.

One comment I would say is at the moment, particularly in America, the jobs market isn’t in a good state. And if you’re hunting for jobs and you look at the vacancies that there are, the ones that tend to hang around, that tend to be available, the ones that you see often are the ones that are the hardest to fill. The ones that are easy to fill get filled very quickly because there’s lots of candidates at the moment on the market. So you look at these jobs, and often these jobs are looking for what you might call the unicorn, somebody with all kinds of different levels of skills and experience.

And it can be easy to fall into the trap of thinking that’s what every role needs nowadays. Everybody needs to be super at everything. And that can, I would suggest, be misleading? It doesn’t necessarily mean that we have to have a huge amount of skills in all these different roles. Sometimes it’s just that you’re seeing these very hard to fill roles with perhaps unrealistic expectations.

And the Write the Docs newsletter for December included a link to a post on the Cherryleaf blog that I must admit I’d forgotten we’d written from back in October. We’d written a post called Documentation product management: does the AI era demand a new discipline? Let me read you some or all from that blog post. It’s not too long.

In a recent thread on the Write the Docs forum, Ian Cowley suggested the growth of AI might lead to a new role, product managers for docs. He wasn’t alone. Stefan Delbos, presenting on activating product knowledge at the Write the Docs Berlin conference, Shahari Shastri has written an article arguing documentation needs its own product manager, and even Shopify’s engineering culture explicitly treats documentation as a product.

But isn’t this just content strategy under a different name? Not quite. While modern content strategy has evolved to include strategic planning, user research, and cross functional coordination, the AI era is introducing challenges that require a fundamentally different approach, one that borrows from product management in ways that content strategy traditionally hasn’t.

Three forces are converging to make documentation product management a distinct discipline.

One, documentation is run time, not reference. Documentation is no longer just a reference artifact created after development. With AI systems, documentation now affects systems directly during run time. Today, technical writers communicate their value by describing how they’re a critical part of the LLM supply chain. You need good comprehensive documents for users to use and understand a product when they’re getting their information through an AI system, such as a chatbot. When an LLM consumes your API documentation user documentation to generate code or when an MCP server exposes your knowledge base as executable tools, your documentation becomes part of the product interface. The distinction between docs and product collapses. This means documentation quality doesn’t just affect user satisfaction, it affects system behaviour and reliability. Which leads to point two, the dual audience problem. Documentation now serves two fundamentally different consumers simultaneously human consumers and machine consumers. Machine consumers are LLMs that may need different language, additional metadata, or structured formats that humans wouldn’t want. The words you use to describe a tool to a human might not match what an LLM needs for accurate interpretation, and that’s an interface design problem that requires product level thinking about user machine needs.

And third factor is multi-interface information experience. Users no longer consume documentation through a single portal. They’re now accessing it through web documentation, chat interfaces, i.e., chatbots, IDE integrations, voice assistance, embedded UI help, and support chatbots. And each interface has different constraints, context, and user experience. This means somebody needs to design the end to end information experience across all these touch points, just that a product manager designs user journeys across web, mobile, and API.

The blog post continues. I’ll leave you to read that if you want. We’ll provide a link to it.

I’ll skip to another aspect which follows on from the three posts we’ve talked about so far, and that is who should do this work? Should it be a dedicated role?

For small organisations it’s probably going to be a senior technical author, senior technical writer, or a content strategist who expands their skills. For medium to large organisations, it might be this role of documentation product manager, because they tend to have multiple products, complex platform offerings, documentation that spans multiple teams. And for enterprises, it might be that there are multiple documentation product managers.

And related to that, what background will this person have? It might be somebody from a technical writing background, somebody who has been a technical writer. But it might also be somebody with a UI or UX background. It might be where content strategists go.

Which leads us back to the need for you as a technical writer to acquire the skills and to promote that to the organisation, to take agency, to be proactive, to let them know that you can do this, you want to do this, there’s a need to do this. And if I can subtly put in an advert for Cherryleaf’s mastering and managing documentation with AI training course, it’s designed to help give you those types of skills or some of those skills at least.

Something else we’re likely to see is what Fabrizio Ferri Benedetti has wonderfully called documentation theatre. We’re starting to see AI tools come out that say they can create a knowledge base, documentation portal, developer portal from just looking at the code that commits in a GitHub repository and generate a site for you. There’s one called CodeWiki. There’s one called DeepWiki. One of the problems with these types of sites is they don’t answer, they can’t answer, without hallucinating the why. Why would a user do this? Or that they generate content which is primarily reference information rather than task based information, conceptually explaining information. And where it is filling in the gaps, whereas the content doesn’t exist in the repository, there’s a greater risk of it hallucinating.

So you may see people suggesting that AI can create the documentation without the need for a human in the loop. And the best response in that situation is to test it. Test it by posing certain questions and seeing if it can provide the answers to those questions.

Thinking more positively, we now have this need to fulfill this new audience, the machine audience. That’s likely to affect things we’re seeing anecdotally already, organisations overhauling their error codes to make them easier for AI agents to understand. And now we have the ability to go to senior management and say, we need this change to happen because the AI systems require it. And if companies want to be motivated to get leads, suggestions to be promoted by chatbots when users ask questions to the chatbot of which vendor can do this or that, then they need to pay attention and create content that is optimised for large language models to consume. They need to consider creating MCP servers that guide the chatbots to the most relevant, most recent, most appropriate information.

I think that’s probably a suitable stopping point, and it might be worth me recapping and summarising some of the different thoughts from different people. We’re seeing some consistency in thoughts from different people.

In some ways, the document isn’t the end goal anymore that we are likely to see it becoming more about a seamless user experience, resolving problems successfully, and that the value of the technical writing role is in that. That the technical communicator for the future’s going to be a strategic thinker, someone who designs and orchestrates complex ecosystems, not just documents, but with the proviso that it might be potentially somebody from a UX or UI background or even a training background if they put their hand up first, if they can convince the organisation they have the skills. Which means, as Jacob Nielsen said, for UX, which I believe is also true for technical writing you need to be in charge of things, not wait to be told, to be proactive, identify problems, suggest solutions, initiate action.

Because AI will always need a human to give it a goal. You’ll need judgment. You’ll need that wisdom to be able to decide from all the different options that an AI system can create which is the right one. And you’re going to need some persuasion skills to influence others, to get people to buy in to this vision. In some situations, you may need additional skills. You might need more technical skills. It will depend on the company, the type of documentation that you’re doing. You might need data literate skills because one of the ways of assessing whether a new system is successful or not is looking at any analytics that can be gathered and reviewing it and evaluating it.

If you need help, we have a training course on managing documentation with AI, which you might find interesting. And if you’re looking for a company to help you, a technical writing services company with expertise and experience in AI, then again, you could consider Cherryleaf.

So that’s it. I wish you a happy Christmas if you’re celebrating Christmas, and a productive and successful New Year and onwards. If you have any thoughts, if you think we’ve missed something out, if you think we’re right, if you think we’re wrong, you can let us know. Info at Cherryleaf dot com. Thank you for listening.