If writing is no longer a marketable skill, what is?

by Tom Johnson on Aug 9, 2018
categories: writing • podcasts • simplifying-complexity

• Site metrics gives insight about the skills people want
• The solution – supplement tech writing with a hyphenation

Site metrics gives insight about the skills people want

The other day I looked at site metrics for my two sub-projects: API documentation and Simplifying Complexity. The traffic on my Simplifying Complexity site is only about 1.73% of the overall traffic on my site — here the traffic for Simplifying Complexity for the past 3 months:

In contrast, the traffic on my API documentation site (for the past 3 months) is about 60% of my site’s overall traffic:

How do you interpret this disparity? It seems pretty clear that one type of content is sought after more than the other. Granted, the API doc site has more pages (96 instead of 11) and it’s been around longer, and I’ve given lots of API doc presentations referring to it. But I think it’s more than that. People seek to learn about skills they lack. API documentation is one of these sought-after skills; simplifying complexity isn’t a skill people search out.

Further, I’m guessing that most of the traffic to that API doc site involves developers looking for tips on how to document their API, not technical writers. This is because the traffic is outpacing the regular traffic on my blog.

Also, I get regular requests to teach workshops and even classes on API documentation, but almost nothing on simplifying complexity (though granted, I haven’t marketed it or even finished that site). But if I were to try to package up the content I have so far about simplifying complexity, I’m not sure how I would market it. Workshops seem geared towards teaching specific skills that can be packaged and sold. Is simplifying complexity a skill that fits into that category? Workshops tend to focus on more concrete tasks, whereas the topics in simplifying complexity align more with critical thinking and higher-level analysis.

To give you an idea of the skills focus in workshops, here are some titles from workshops at the recent STC Summit, Lavacon, and other conferences:

• Structured Authoring and DITA
• Usability and User Experience
• Content Strategy, Engineering, and Management
• CSS Like a Pro
• Content Experience Modeling
• Developing Web Apps
• WordPress for Technical Communicators
• Content engineering
• Technical Writing for Translation
• Context for Content? It Depends.
• Managing Content Development Teams: Inner Mastery
• Machine Learning 101: Get Started with Chatbots
• Design Thinking Workshop
• Experience-Focused Content Organization
• Unified Content Portals
• Learn how to Git
• Content Strategies

Skills are usually the focus of any workshop. Simplifying complexity is too much like the core task of technical writing. To make this into a workshop, I’d need to convert this capability into a marketable skill, to package it in a way that sells. Most likely that approach would be “Creating Documentation for Developers,” or something. Or maybe I would need to recast it into a specific methodology framework that has a catchy name, like “Reducing Developer Friction.”

Other recent events have suggested the devaluation of writing. At work, sometimes my role seems to be catering more to groups who write their own documentation. For these groups, I just edit and publish their content. I support a lot of different teams at my current work, and I only write docs from scratch for some. For many teams, I’m merely a conduit that helps them publish, because I simply don’t have the bandwidth to do any more than that.

Recently, an Amazon team posted a job for a full-time technical writer/editor whose job would be helping edit and publish content for product teams. This position will help teams who bring their own docs to the table, so to speak. The writer will help edit and publish the content, rather than write it for them. The writer is more of a facilitator. Here’s an excerpt from the job post:

As a technical writer/editor, you’ll work with the tech writers and the technical teams to create and drive quality standards and edit and produce the developer documentation in a cross-functional, distributed environment. You’ll drive editorial process to ensure a high-quality experience for developers. You’ll also serve as the writer and quality control on projects where partner teams are onboarded to publish to the developer portal.

Granted, the same team also posted a position for a Sr. Programming Writer. And the latter is a level higher than the former. But still, it’s interesting to see this distinction in jobs.

I hear discussions about the value of writing in podcasts too. The latest version of the Cherryleaf podcast, The evolution of the technical communicator’s career, discussed a dreary article called Software technical writing is a dying career (but here’s what writers can do to stay in the software game), by Jim Grey published in 2015.

Grey’s main argument is that “companies are leaning into good user-interface design and stepping away from online Help systems and printed/PDF documentation.” Grey explains that he had lunch with a business owner who said:

Technical writing is dying off…. It’s all about clean, engaging UX now. I have talked to more than a hundred startup and small software companies as I’ve built my business. Almost none of them have technical writers, and almost all of them have UX designers.

I’d agree (not necessarily based on any raw data) that tech writing jobs for UI products (that is, for end users) are probably shrinking, but I would argue that tech writer jobs for developer docs are growing. I mean, look at the tremendous growth in APIs over the past decade. Granted, I am based in the heart of Silicon Valley, where APIs abound and every third person is a technology worker, but it still seems like this is the era of developer docs, and the developer doc industry is thriving.

Grey transitioned into software testing instead, leveraging many of the skills he developed as a technical writer. In the Cherryleaf podcast, Ellis Pratt (the host of the Cherryleaf podcast) looks at job trends and concludes that no, technical writing jobs haven’t gone away. Ellis says:

Is this true? has the tech writing job disappeared since 2015? Clearly not, because there are still companies like Cherryleaf and I suspect that a good few people who listen to this podcast are technical writers and authors. But I think there is a truth in saying that the role of the technical author is changing, and the requirements and the skills that they need are changing as well. And it may be that the job title changes and the way in which the role is perceived. (Podcast 40: The evolution of the technical communicator’s career)

Continuing Ellis’s position, if you look at another source, the STC Salary Database, you can see that tech writer jobs have largely remained the same:

The Salary Database author explains:

During 2016, there were an estimated 49,780 technical writers employed in the United States. The profession was relatively flat, in terms of employment, increasing only 10 jobs versus 2015. However, the employment level in 2016 represents the highest employment level for the occupation since being individually tracked by the Bureau of Labor Statistics. In 2013 and 2014, there was an estimated increase of 1,140 and 910 technical writer positions, respectively. This represented a 2.5% increase in 2013 and a 1.9% increase in 2014. During 2015, the profession experienced an increase of employment of 1,560 technical writers, equating to growth of 3.2% versus 2014. The graph below shows the employment trends of technical writers versus other media and communication occupations. Of this group, “technical writers” is the only occupation which has seen employment growth in each year since 2011, with an average annual employment increase of 1.9%.

The STC Salary Survey pulls its data from the “Occupational Employment Statistics” wage survey conducted by the Bureau of Labor Statistics (BLS). If you look at the BLS Employment Projections, you can see similar information (though it puts the number of tech writers in 2016 at 52,400 instead of 49,780 — I’m not sure why there’s a slight difference there, other than maybe the STC excluded some small segment.)

The BLS says the job growth rate for software developers from 2016 to 2026 is projected at 24% (a rate that is “much faster than average”), while the average for all jobs is projected at just 7%. The job growth for technical writers is projected at 11% (which is still “faster than average.”)

It seems pretty clear that if software engineering jobs are growing 13% faster than technical writing jobs (24% minus 11% = 13%), then even though technical writer jobs aren’t actually shrinking, they are shrinking in comparison to engineering jobs.

If I understand the math correctly, if you support 5 engineering teams now, in 2026 you’ll support 13% more engineering teams — or about 6 engineering teams. This isn’t startling, but the trend would explain why more engineers are writing docs, and why tech writers are playing more of an editor/publisher role.

Despite the trend of more engineers writing, engineers still generally dislike writing. Matt Asay explains that the 2018 GitHub Survey found that contributions to documentation in open source projects are abysmal. Even when developers write, they are extremely reluctant to do so. Asay explains:

93% of respondents gnashed their teeth over shoddy documentation but also admitted to doing virtually nothing to improve the situation. … If you think this deeply felt need for documentation would motivate more developers to pitch in and help, you’d be wrong: 60% of developers can’t be bothered to contribute documentation. (Open source documentation is bad, but proprietary software is worse)

So even if engineers are writing, they are likely gnashing their teeth while doing it, and resenting it. As such, what they produce can’t be very exciting to read. Maybe we’ll see trends reverse course, similar to how many thought all tech writing jobs would be off-shored to India, but then that off-shoring trend seemed to fizzle (presumably because the output was … kind of poor, like an engineer’s writing?).

The solution – supplement tech writing with a hyphenation

All right, so enough of those dismal numbers. The profession is changing/evolving. Tech writer jobs may not be shrinking, but they’re not growing at the same rate as engineering jobs. How can we pivot our profession’s marketing so that we’re not selling our only skill as “writing,” which is a skill engineers and others already feel they have? What skill do technical writers bring to the table, and how can that skill be packaged and sold in an attractive way?

This pivot was my initial intention with the focus on simplifying complexity. We’re not just writing tech docs – we’re simplifying complex information. However, I think in the minds of most people, simplifying complexity is just a fancy way of saying technical writing.

Moreover, even if products are highly complex and technical, I’m not sure that tech writers can swoop in and save the day. I spent most of this week trying to explain a product that was just poorly designed — some aspects of it are a kluge designed entirely by engineers. Products that are designed so poorly as to be insanely complex can’t be bandaided with helpful documentation and fixed. The products will ultimately fail if they aren’t designed in a more usable way. So you don’t need a super-duper specialist to come in and save the day by making clear documentation for a virtually unusable product, because the market will ignore the product anyway.

So if we can’t market our writing ability, what sells? Earlier I said to consider what you could package into a workshop and market to people. Rather than reflect on workshop titles, let’s think about ways to hyphenate our roles, making our job titles a hybrid. This is something Jack Molisani recommended back in 2007 when I interviewed him at an STC conference.

After some brainstorming, here are a few hyphenated or hybrid roles for technical writers:

• Technical writer/programmer
• Technical writer/API docs specialist
• Technical writer/video producer
• Technical writer/digital marketer
• Technical writer/content strategist
• Technical writer/usability specialist
• Technical writer/UX copywriter
• Technical writer/publishing tools expert
• Technical writer/DITA specialist
• Technical writer/information architect
• Technical writer/illustrator
• Technical writer/localization manager
• Technical writer/web designer
• Technical writer/graphic designer
• Technical writer/content marketer
• Technical writer/editor
• Technical writer/project manager
• Technical writer/web developer
• Technical writer/customer experience professional
• Technical writer/digital storyteller
• Technical writer/corporate communications
• Technical writer/blogger
• Technical writer/communication designer
• Technical writer/plain language expert
• Technical writer/health communicator
• Technical writer/web analytics and SEO
• Technical writer/brand influencer
• Technical writer/information designer

Which of these hyphenations will be the best strategy and route for a technical writer? It depends on your interest and skill set. I made a little poll you can take if you’d like to see how your hybrid matches up with others. You can select multiple options.

You can see the poll results here.

Based on the fact that 60% of the traffic is going to my API docs site, I’m guessing that the first two (“Technical writer/programmer,” and “Technical writer/API docs specialist”) will be most in demand.

Note that sometimes the title for these jobs isn’t hyphenated but is more succinctly phrased as “Programming writer,” that title is somewhat confusing as well and suggests one is writing programs. You could also recast these titles as “Technical writer focusing on _______.” But I also kind of like “programming writer.” It’s a title that non-technical people won’t hijack (like the title “content strategist” was hijacked by low-level SEO marketers).

“Programming writers” (or tech writers focusing on developer docs) bring value to writing by combining their expertise in technology with their writing skills. Given that the technology field continues to grow (and become more specialized and diverse and complicated) at exponential rates, this sort of focus (programmer / API docs / developer docs, etc.) will probably be the safest and most in-demand hyphenation for writing roles.

Now, whether all technical writers want to develop their programming knowledge in order to play this dual role is another question for another blog post. But based on this, I might try to pivot my “Simplifying Complexity” series into a series on “Simplifying Developer Docs” or something. I think many of the same principles will apply. What do you think?

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.