Technical writers come from a variety of backgrounds and can have a diverse skill set. In this post, I’ll look at some of the skills you should look for in a technical writer. (It may also help if you are a different kind of writer and are wondering if you could make the cross-over into tech writing).
Technical but not ‘technical’?
Unlike many jobs with ‘technical’ in the title. technical writers do not always have a technical background. Some do, but there are many others, myself included, who come from a communications background. (You can find out more about the pros and cons of both in my post on technical backgrounds).
So if we’re not technical in the traditional sense, how are we able to work in highly technical industries? What are the skills we possess?
A good technical writer needs to be curious and willing to challenge the status quo.
Good technical communication doesn’t just tell you how to do something. It tells you when, where, and why you need to do it too. This extra context gives people a better understanding of how your product works and how features relate to each other and the reader’s goals.
To make this sort of content, the technical writer has to understand not only the product, but also how the audience will use it (and how they may misuse it).
Importantly, the technical writer needs to challenge any existing ideas that weaken the documentation. The most common problem I run into is where previous writers have described a feature without giving it any context. This is usually where there is ‘how to’ information, but no mention of why or when you would follow the instructions, or what the results should be.
When people struggle with complex information, it’s usually because there is too much information to take in at once. This can also be made worse by the introduction of a lot of jargon terms.
A technical writer should be able to identify the learning curve of the reader and break the information down into more manageable chunks. These chunks are then presented in an order that makes sense to the reader and lets them learn each part of the puzzle in sequence.
When it comes to structuring the content, there are two different areas the tech writer needs to cover.
Let’s look at taking care of the audience first. We need to know how to order the content for the reader, so that they can find what they need quickly and easily. It also needs to be presented in a logical order.
But we also need to think about other writers and collaborators. Some of the more advanced technical writing tools allow us to create topics and reusable bits of content, and we need to structure these. Other writers need to be able to find the reusable content easily, otherwise they may end up duplicating content that already exists.
Technical writing isn’t copywriting or prose. Its purpose is to provide the reader with clear information as quickly and easily as possible. Your technical documentation isn’t the place for flowery language or elaborate word play.
That being said, there’s an increasing need to match the tone of product documentation to the tone of your marketing. This gives a more consistent user experience of your company. So today’s technical writer needs to be able to write concisely, in plain English, but should also have a good feel for your company’s tone of voice in marketing.
Note that there are exceptions to this rule – in some industries, such as aerospace, there are strict standards for the use of vocabulary. It’s still plain English, but there are more limitations about the way things can be phrased or what words can be used (often with good reason).
Technical writers can’t afford to be precious about their work. Because at some point, there’s a strong chance that they will:
- Catch a subject matter expert on an off day and be scoffed at
- Struggle to understand a technical concept. Sometimes the way a subject matter expert explains a concept will fail to connect with the technical writer, just like it would fail to connect with the audience. It’s the technical writer’s job to try to unravel the information or try to coax the SME into explaining it a different way.
- Have another technical writer or stakeholder criticise the actual writing. This can sometimes happen when people have a misguided notion of what makes the company look good, and they expect a more academic style.
- Be faced with people who are resistant to change and want to follow bad practices simply because ‘this is the way we have always done it’.
I’ve experienced all of these during my career, and it’s important not to take it all to heart. A lot of the problems come from not understanding what the documentation needs to achieve. Good communication and a bit of patience is often all that’s needed.
Many technical writers need to work closely with subject matter experts to get information. Now, if you’re going to ask SMEs for help, you need to establish a rapport with them, and to do that, you need social skills.
That doesn’t mean you need to be an extrovert (a lot of technical writers aren’t), but it does mean that you have to:
- Be polite
- Be respectful of the SMEs time and don’t ask the same questions over and over
- Show an interest in the subject (or at least fake an interest!). In my experience, SMEs are much more helpful when you take an interest in what they do and what challenges they face.
It can also help to take an interest in the personal life of the SME too. Most people usually have something that you can use to make a connection, whether its a favourite TV show, a sports team, a pet, or a hobby. (If you’d like to read more on this, I wrote a post about interviewing SMEs way back in 2013).
Modern technical writing tools go way beyond simple word processors. They are feature-rich, with options for reusing text, publishing different formats from the same source content, and using different markup and metadata. So it’s not just a case of knowing how to write well these days, the technical writer may also need to know how different authoring tools work.
Often the skills needed are similar for multiple products. For example, the basic concepts of RoboHelp are similar to the basic concepts of MadCap Flare. And if you know about DITA, it’s easier to get to grips with other structured text tools like Paligo.
Technical writers also need to know best practices. In certain industries, there are strict rules about how things need to be phrased, so there can be a lack of flexibility. There are also widely used style guides and principles for structuring content.
Technical writers should be user advocates. Like UX designers and content designers, they should put the needs of the user at the heart of their work. To do that, they need to have empathy, so that they can understand how the customer interacts with your product and what problems they will face.
It also helps if your tech writer has knowledge of UX principles, so that when they encounter a usability issue, they can suggest improvements. This could be simple changes to microcopy, such as the name of options, or it could be more design-orientated, such as changing the location of a port or changing the workflow.
Over to You
If you’re a writer who is thinking of making the transition to technical writing, I hope this post has given you an insight into what skills you need. But bear in mind that some technical writing roles may require an element of technical knowledge too, for example, jobs in API documentation often require the writer to know how to code.
Craig Wright is an experienced technical writer based in Chesterfield, UK. He hates writing about himself in the third person, so I shall stop now.
Always interested in new content writing opportunities. Remote working preferred.