Four Less Common Types of Technical Writers Companies Are Looking For

by Tom Johnson on Jan 24, 2013
categories: technical-writing

This week I had an interesting conversation with Scott Abel, The Content Wrangler. He mentioned that he recently surveyed around 500 companies (many in Silicon Valley), evaluating their needs and the kinds of technical writers they're looking for.

In addition to skill sets that you might expect, such as needs for writers who know structured authoring, XML, and DITA, companies are also looking for the following less common roles:

• Technical writers who can write documentation for APIs and SDKs.
• Technical writers who can write with brevity for mobile devices.
• Technical writers who can create instructional video content.
• Technical writers who can interact with the community about products.

These less common roles are interesting, in my opinion. Although I don't write API or SDK documentation for developers, I have created quick reference guides for users who want brief documentation. I've created video tutorials (for both browser-based and mobile applications) to provide a more visual mode for learning. And I've interacted extensively with our community of users to gather feedback and relay it to project teams.

What aren't companies looking for? Scott said,

Companies are much more concerned about profit and getting products to market than spending months on style guide development. While clarity is important, writers are expected to be business professionals who understand that their role is creating content (in the most efficient and effective ways possible) that help them achieve their business goals.

In other words, focus on the goal of the content, not on insignificant details that very few care about.

When I First Started This Post ...

When I first started this post, life was just as normal as it had been for the past five years. Then the topic of this post suddenly became much more relevant, as my organization laid off our entire tech writing team. They decided to outsource the work through contractors instead.

It was surprising to see the team let go. But while I'll miss working for the LDS Church, I had been thinking about looking for new opportunities for the past six months anyway. After five years, I felt I'd learned as much as I could in the environment and was ready for new challenges and opportunities.

As I've been looking at the job market, I definitely see a trend toward API/SDK writing jobs, especially in the Silicon Valley area. I've come to see a greater divide between end-user documentation jobs and developer documentation jobs. By far, the latter has more opportunities at higher pay.

Although there's still a need for end-user technical writers, I think the demand is decreasing. Scott says,

More and more products are actually being designed using familiar interface functionality — in other words, not everything needs to be explained. Technical writers have been accustomed to documenting an exhaustive list of things when in reality only the things that aren't obvious to the target audience need documentation.

If you provide a "comment" field in your app, for instance, you don't need to write a diatribe on that functionality. You might not document it at all, or say something simple like, "It works just like comment fields on blogs or on Facebook."

In other words, products designed for end-users are becoming increasingly more intuitive. Products have to be intuitive to say competitive in the marketplace. This means end-user documentation may not be as critical as in times past. Of course there are probably a million exceptions to this trend, but for mainstream products, if end-users need to rely heavily on help, the product may be short-lived.

In contrast, the technology behind these products continues to get more and more specialized. There's a growing need for documentation to address the advanced technical frameworks, languages, platforms, and devices that developer use to create these interfaces.

Prior to my most recent job, I did write documentation for network system engineers, creating a reference manual and Visio diagrams for a storage area network (SAN). Although it was challenging, I also found it highly rewarding because I was learning so many new concepts.

Today there are plenty of resources online to learn more advanced technical concepts and tools. For example, I'm currently watching some video tutorials about Javascript on Lynda.com. I'm finding that there's a lot of similarity with the way WordPress handles PHP — a scripting language I am more familiar with.

My immediate turn to Lynda.com — a video-based learning site — as a way to learn technical concepts leads me to another point that Scott raises: the need for technical writers who can develop video content.

About Video Content

Scott explained that while companies can hire third-party video experts to create videos for them, the third-party companies have high production costs because they usually start at ground zero with their knowledge of the product.

In contrast, technical writers already know the company product, having written documentation for it. It's sometimes easier to teach a tech writer video skills than to teach a third-party video developer all the necessary product knowledge.

I've created a lot of video tutorials because it's often easier for me to do it myself. On projects where we involved an outside department unfamiliar with the product to create the video, I had to hold the hand of the media specialist — helping write and edit the script, explaining what we want to communicate, helping set up test data, reviewing the videos, and so on. Helping sometimes takes more time than it would to just create the video myself.

Whenever I'm asked to help out another group like this, I always wonder what the advantage is. Expensive, slick, time-consuming videos created by multiple specialists (voiceover pros, script writers, AV producers, Flash animators, and others) may lead to some attention-getting visual effects and a sense of corporate professionalism, but these videos cost a lot, take a long time to produce, and ultimately don't do any better job in helping the user learn the software than simple videos.

Most problematic, expensive videos as a form of software instruction don't fit in with agile environments. In agile environments, software teams push out releases every few weeks. With each interface change, your video tutorial becomes more and more out of date. The speed of change forces us to re-evaluate traditional methods for creating content.

In a recent webinar on web trends, Sarah O'Keefe mentioned "velocity" as a growing trend. She says, "The requirement for faster authoring, formatting, publishing, delivery, and updates is forcing tech comm into significant changes." (See 2013 predictions in technical communication.)

Agile environments have a high degree of velocity. As agile environments become more common, the need to develop video more cheaply and quickly becomes a priority. Hence, we might see more tech writers getting involved in video in the future. Scott says the videos may not have a high quality, since for many tech writers, videos require a new skill set that they are still developing.

But unless the videos are doubling as marcom material, like some of Mailchimp's videos, the video tutorials can be simple, straightforward, human, and focused on a specific task or concept — and they will still be just as effective. If you know a few basic techniques, you can get semi-professional quality videos without expending a huge amount of time and effort.