Four Less Common Types of Technical Writers Companies Are Looking For

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.

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.

I haven’t commented much on the other trends — brevity for mobile devices, and community. But I’m sure I’ll explore those trends with more depth in upcoming posts. In the meantime, if you have leads on companies or contracts where you think I’d be a great fit, let me know.

Currently I work on a video tutorial project for my company. I wrote the help documentation for the same software.

While composing the videos, sometimes, I find instances where I can change content in the help documentation to a more simple and short style. In another words, letting the technical writer do the videos helps him/her identify his/her own mistakes and correct him/herself before anyone does.

Besides all that, learning the art of video creation is very interesting

Good luck, Tom. The uncertainty about what’s next must be unsettling. Hope the opportunity turns into something fabulous for you. The rest of us have a lot to learn by following you wherever you go next.

I didn’t know I was less common until now. I guess that’s the Silicon Valley bubble for you. I think video is ok for basic getting started information, but the last thing I want to do is sit through a video to find specific information. As the article points out, rapid changes are the norm, and re-doing a video is much more involved than simply updating an article.

Great post. Yes, it’s interesting to see how the accelerating pace of product change is driving change in the way we need to work, in order to fulfil the tech comms goal of useful, usable information. It’s happening so fast at the moment. Good luck with the job search, it seems sparse at the moment but you must have a better chance than most.

So sorry to hear about the lay-off. I totally empathize – my husband and I (collectively) have been laid off in our tech field about 6 times in the past ten years. In the tech field, the wiser we get, the more expensive we get. Not many companies in my location want to pay for that.

However, you have made quite a name for yourself through your blog and presentations. I have no doubt some stellar company out there would like to have a star on their team. If you can relocate, I’ll bet you find some terrific opportunities.

Best luck in the coming weeks to advance your career to the next level. You are a valuable voice in Technical Communication – keep it going loud and clear.

Tom, this is a great post, and very timely. I read your “moving to California” announcement post before this one, so I’ve just now found out the reasons behind your move. Best wishes for you and your family!

I’m looking to move away from teaching, so it’s great to read up on special skills I can hone for my job search. As I read, I thought, “Hey, I can already do some of this…that’s a start.” You’re so right about Lynda.com. It’s been invaluable to me in my return to tech comm graduate study.

Video is not designed to replace, but to augment and support, other documentation types. And, the videos can be (and are being) recorded in modules (think individual chunks of content — single sourcing) and being recombined on the fly to create larger video collections.