What technical writing trends will we see in 2018?
What technical writing trends stood out in 2017?
The highest viewed post on my site in 2017 and the most listened to WTD podcast were both on the topic of trends (see my 2017 trends post and the 2017 WTD trends podcast). This suggests tech writers are interested in keeping up with what they perceive as a constantly changing landscape for their jobs. So, what technical writing trends stood out in 2017?
Chatbots and voice interactions emerged as themes in 2017, with an entire conference (Information Development World conference) focusing on this topic. Write the Docs continued to grow, with meetups in more than 30 cities, conferences on 3 continents, and thousands of Slack channel members. I attended my first WTD conference in Portland this year (and reflected on it).
We saw Stack Overflow give up on their Documentation feature. A specification for Lightweight DITA was formally proposed, with promising integration of Markdown and HTML formats. OpenAPI became the dominant specification for describing REST APIs, and Swagger-related tutorials continued to dominate my search metrics. Because of this, I also wrote a detailed tutorial for the recently released OpenAPI 3.0 specification.
Numerous podcasts emerged, namely Cherryleaf, Scriptorium, and Write the Docs (Ed Marsh’s Content Content podcast continued as well). I also started narrating some of my own posts, which had surprisingly high numbers of listens.
Docs-as-code tooling continued to proliferate as a trend; Anne Gentle published Docs Like Code and invited others to share their experiences. My Jekyll doc theme now has 395 forks, 541 stars (and about 72,000 page views since I started tracking page views from July). We rolled out a docs-as-code publishing system (based on Jekyll) at my work, and I wrote about lessons learned.
The divide between tech comm academics and practitioners continued to grow and become a serious issue — almost the entire issues of Technical Communication (volume 63.4 / Nov 2016) and Intercom (volume 63 Issue 10 / Nov/Dec 2017) have been dedicated to this academic-practitioner rift and potential solutions.
Agile continues to be a challenge for tech writers, as this agile podcast received the most listens of any of my 2017 podcasts. And there’s a continued trend toward cross-functional, interdisciplinary roles that tech writers can play as content influencers and strategists, which an idea I’ll expand on later in this essay.
Technical Writing Trends for 2018
Before jumping into predictions for 2018, let’s do a quick review of previous trends posts. In 2015, I predicted the increased use of Markdown, more focus on API docs, more specialized skillsets, and a few other developer doc trends. In 2016, I focused on the ripple effects of API docs on the tech comm industry, and said that because of the increased focus on APIs, there would be more attention on Swagger, GitHub, and Write the Docs. In 2017, I said that GitHub would continue to grow as a trending platform for documentation.
Although I don’t have quantitative numbers, I think the trends I’ve highlighted in the past are still on target, at least in Silicon Valley. If we’re looking only one year out, the changes tend to be gradual. I rarely highlight anything that’s not already somewhat trending. For example, I’m not going to predict that a totally new, unfamiliar topic will suddenly surface and dominate, transform, and disrupt the tech comm industry within a one-year time period. I also recognize that my predictions are often rooted in my own role, experience, and location (and that my role as an influencer and blogger might actually shape some trends).
What will 2018 bring for the field of tech comm? Here’s what I think. In 2018, tech writers will play more cross-functional, interdisciplinary roles in order to establish value as generalists.
Let me explain. We all know that for the past few decades, technology has been getting more and more specialized. Knowledge is becoming more extensive, detailed, and deep. The idea of a Renaissance person, one who can adeptly navigate across history, science, philosophy, literature, and mathematics, etc., is lost. Today, scholars and professionals study one specific field, going in depth in a particular detail in the field. A 2011 article in the Harvard Business Review noted the trend toward “Hyperspecialization,” explaining:
Just as people in the early days of industrialization saw single jobs (such as a pin maker’s) transformed into many jobs (Adam Smith observed 18 separate steps in a pin factory), we will now see knowledge-worker jobs—salesperson, secretary, engineer—atomize into complex networks of people all over the world performing highly specialized tasks. (The Big Idea: The Age of Hyperspecialization)
The author even notes how different paragraphs within the same encyclopedia articles are written by different specialists. The paragraphs fit together into a larger article shown to be on par with other encyclopedia articles. Hyperspecialization within IT has also become more pronounced. One is no longer a “software developer,” but a specialist in a particular language and role — a JavaScript developer for web apps, an Oracle database specialist, a release management configuration engineer, and so on.
Hyperspecialization has become only more acute with each passing year. Because of this specialization, I think more engineers and other specialists will be writing docs — because the information is so technical and specialized, tech writers will have a hard time developing the content. Instead, technical writers might play more general roles with content and more specialized roles in editing, publishing, and curating content. Besides providing value in publishing, how exactly will generalists provide value in a world of increasing specialization?
Our backseat role to content development will surface value questions around our technical writer role. Will our editorial role of specialized content reduce our value such that others see us as secretaries who “make the documentation look pretty” — a stereotype Emily January Petersen described in her article, Articulating Value Amid Persistent Misconceptions.
In order to provide value as content generalists, I think tech writers will start to play more cross-functional, interdisciplinary roles. We’ve already seen this shift with the focus on content strategy and content experience. I believe tech writers of all stripes (who don’t consider themselves content strategists or content experience influencers) will start to cross more boundaries and functional groups in order to drive up their value to the organization.
Michael Baer, a strategic marketing innovator, explains that generalists have value through their cross-domain functions:
… specialists tend to focus on what their domain does. But in a hyper-specialized world, you need people to pull it all together to make sense of things. The generalist sees the whole playing field — what the business context is, where you want to get to, and what all the relevant marketing levers are. Again, this helps a team see the totality of a program, how it all works together, and how to course-correct as it plays out. (6 Reasons Generalists are More Important Than Specialists)
In Time magazine, Nike Lovegrave explains that we over-value specialists, noting that their predictions or strategies haven’t proven better than those of generalists. He says the idea of specialization has been made popular through Gladwell’s 10,000-hour rule and through Peter Thiel’s Zero to One, in which he recommends focusing your entire career on a single objective. Lovegrave explains that the new successful generalist is a polymath or “flexpert” who has some depth in a variety of domains:
[polymaths] are people who, after a decade or so of specialization, begin to explore other domains while maintaining their established skills and knowledge. Another study by the academic Beatrice Van der Heijden coins the expression “flexperts” to describe people who are both flexible and in possession of expertise. (The Danger of Having Too Many Experts)
In 2018, we’ll begin to increase our value by becoming flexperts in domains such as Support, Marketing, Sales Engineering, UX Design, Product Evangelism, and more. In a recent tweet, I shared a graphic showing how all these groups use documentation in their roles:
I made a graphic showing all the different groups in an organization that typically use documentation as a tool in their jobs. #techcomm pic.twitter.com/qCQyp3gBZz
— Tom Johnson (@tomjohnson) December 18, 2017
This coming year, we’ll begin to understand these other domains and develop a level of depth and expertise across these domains that will make our content objectives more valuable. After all, you can’t create content without understanding the context, the user journey, and other needs of the group or domain. Developing this understanding will enrich us somewhat as polymaths or flexperts more than just generalists.
Academics will explore content strategy with more depth in the future as well. A call for proposals with the Technical Communication journal (for the February 2019 issue) actually focuses on content strategy:
The aim of the issue is to place content strategy within the larger grid of professions that collaborate and sometimes overlap. In content strategy, the common denominator is the systematization of content. The specialties may range from marketing to product to social to entertainment content; creating a plan to ensure that the right content gets to the right audiences in the right context is what separates a content strategist from a technical communicator, content designer, copywriter, UX writer, and so on. (Call for Proposals: Special Issue of Technical Communication on Content Strategy)
In addition to playing more cross-domain, cross-functional roles with content, I think we must deliver more on the core value proposition of our profession: we simplify complexity; we make complexity easier to consume. I’m not talking about just removing jargon, arranging information as task-based steps, or adding screenshots for confusing selections (all good techniques). We’ll need to figure out how to simplify complexity on another level entirely, perhaps with embedded navigation maps, more abstraction of technical detail, context-sensitive help delivered via APIs, some artificial intelligence, and more.
I was recently listening to Overcomplicated: Technology at the Limits of Comprehension. The author argues that we’re increasingly interacting with technology we don’t understand. Accretion, legacy systems, edge cases, specialization, interoperability, code that interacts recursively within itself, and other factors contribute to the growing complexity around us. These complex systems (built by many specialists each contributing their own part) interact with each other in unpredictable ways. When systems break down, often no one knows how to fix them. More importantly, how each of these independent, specialized systems interact with each other is often an unknown.
Yet, here’s what I don’t understand. If the world is becoming more complex due to increased specialization, why don’t we see an increased demand for people who can simplify this complexity? Why aren’t technical writers the hottest and most sought-after role in the technology industry?
Sure, to some extent, users are also getting more tech-savvy, and products are becoming more user-friendly. But maybe we aren’t delivering on our promise of simplifying complexity. We’re okay at it, but we’re not doing it in an impressive way. And why not? In part, because we don’t understand the right way to go about it. We could use more knowledge and training on how to simplify complexity in deeper, more thorough ways. I want to explore this theme in 2018. The topic of simplifying complexity fascinates me like no other, and I tried to convey this in Part VI: Deepening documentation’s value by simplifying complexity.
We would be fools to undertake this alone, just spinning the wheels of our own thoughts and experiments. Fortunately, we happen to have a whole body of research-driven, high-level analytical thinkers who are eager to assist. I’m talking about the many university professors in tech comm who are facing an unprecedented value crisis of their own. Not many practitioners read academic articles, not just because academic language tends to be dry, longwinded, and sometimes “inaccessible.” But also because the articles don’t seem to connect with issues practitioners are facing. If you want to read analyses of DITA or API documentation, you probably won’t find much in academic articles.
If vocationally minded TC practitioners don’t see the value of TC academic research, and the TC academic’s purpose is to provide more value to TC practitioners, how will TC academics survive in the long term?
I think that in 2018, we will see practitioners and academics starting to collaborate and interact more regularly. Sure, academic wheels are slow to turn, but we will start to bridge this gap as a way to add value. I’ll be writing more on collaborative opportunities between practitioners and academics in the future, but I think that working together, we can better tackle the larger question of how to simplify complexity and in doing so, establish more value to our generalist roles in a world of increasing specialization.
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.