The Top 6 Problems People Have with Technical Communicators

Good technical communication provides many benefits, from writing that people can understand immediately to needed information that’s easy to find. However, there are a few challenges when it comes to handling technical communicators:

1. Many in the industry can’t handle technical content

In my experience, about half of the technical communicators out there can’t actually deal with technical content. It can be a challenge to sort the good from the bad. To do so, it usually requires some kind of testing of the technical communicator’s abilities before committing to a full-scale project with them.

2. Sometimes technical communicators can be antisocial

Good writing requires some amount of isolation. That’s something that all technical communicators have to be able to deal with. But a good technical communicator has to prioritize relationships as well, since most of their work usually involves interviews and other forms of information gathering.

3. Lack of ability to use technical communicators effectively

You may know that you need help writing stuff up, but how do you make sure that you use that help well, and get the most bang for your buck. There are a variety of best practices, many of which are covered on this website. One helpful policy is to make sure that the technical communicators themselves know industry best practices, and have company policies that are in line with those best practices. An informal survey on LinkedIn indicated that 48% of issues technical communicators experience involve management being unclear on how to work well with technical communicators.

4. Technical communication help costs money

This one is what it is. Some are willing to pay for highly qualified help, and some aren’t. To avoid spending money on bad help should be the goal, so strongly consider including metrics in your progress that realistically assess the impact that the technical communicator is making.

5. Believing that technical communicators don’t provide enough value

This may be related to #1. But some people just don’t believe in the value of technical communication generally, thinking that it’s just prettying up text. While some of these people may be lost causes as potential clients, others can be won over when they see examples of and research concerning effective technical communication. The same LinkedIn survey mentioned above indicated that fully 2/3 of issues that technical communicators experience are related to organizations undervaluing the contributions of their technical communicators.

6. Overemphasis on terminology

Some people place as their first requirement that a technical communicator has mastered a particular set of niche industry terminology. This can happen especially when erroneous beliefs about #1 and #5 have taken hold. However, since terminology can vary widely within a single project in a single company, this requirement has more to do with prestige than actual effectiveness.

Do you have any other categories to add to this list? Let us know!

How to Use Technical Communicators Effectively


The purpose of this article is to help you examine technical communicators you might want to work with to see if they know their stuff, and to help you use those technical communicators well once you find them. 

Test them up front

Maybe you’ve had a bad experience with a technical communicator/tech writer in the past. Or maybe you’re not sure if the person or company that wants to write your manual or other document can do the job. That’s a reasonable concern. So what do you do?

Linscomb & Williams, a top-25 money management company in Houston, was faced with that situation a few years ago. They wanted to rewrite some of their client documentation in Plain English. But they needed someone who could do that while keeping the information technically correct.

Linscomb & Williams solicited bids from several bids from potential vendors, whom they asked to submit a small section of text from their disclosure document, rewritten in Plain English. Rewriting the text didn’t take the potential vendors very long, and it was a small enough section that the bid proposals didn’t amount to Linscomb & Williams trying to get free work done. But it was enough for them to evaluate how clear the revised text would be to their customers. They tested the text on several audiences, which they asked to rate the text in several areas of clarity.

In that case, EDI got the project. But what if EDI’s tone or method of laying out information didn’t match what Linscomb & Williams was aiming for? Then they would have had the opportunity to select another vendor that fit their culture better. Taking the time to test out potential vendors up front helped Linscomb & Williams make a good decision. You wouldn’t install software without testing it, would you? The principles of software testing, as described in this Amy Vetter article in CPA Practice Advisor, transfer to the testing and selection of a technical communication vendor. 

Get them involved up front

A December 2006 Aberdeen Group report states that project documentation meets expectations 92% of the time when technical communicators are involved up front. When the writers are involved later, the success rate for the documentation falls off precipitously.

You want to involve the technical communicators early and often in the project discussions. This will help them to gain a clear understanding of where you’re trying to head with the project, and therefore, with the documentation. It will also give them a chance to guide decisions that will impact documentation, so that the end result is high-quality, usable content.

Have you struggled with a writer who is so introverted that all they want to do is sit in the dark and write? This is a way to help them be a connected part of the team.

Don’t try to make the technical communicator a subject matter expert

I run into business people all the time who are looking for a technical communicator who is well-versed in the lingo that they use in their business. I’ll admit, for the sake of prestige a technical communicator may need to know some terminology in order to get their foot in the door. It can be helpful for a technical communicator embedded for years in a single department to become as much of a subject matter expert in that department’s subject matter as possible. Of course, the benefits of this knowledge tail off if the technical communicator begins to lose their objectivity, as tends to happen with anyone who is too close to any subject material.

But subject matter expertise is generally less important, or even possible, for individual projects. You probably know way more about your business, your clients, and your terminology, in the context of your project, than any technical communicator ever will. A good technical communicator knows more about planning documentation, structuring documents, and producing clear writing than you do (assuming that’s not your profession).

So let them do their thing. The best documentation usually comes from a pairing of motivated subject matter experts and technical communicators who are very good at drawing out the correct information, and expressing it clearly in writing. 

Focus on the value of the writing, not the hourly rate

If you’re just looking at your writer as someone who produces content as a commodity, then you probably won’t get much bang for your buck. You’ll likely wind up wondering if it makes sense to pay a technical communicator to produce content.

There are several reasons why people have this attitude issue.

One is that technical communicators are often tasked with documenting features, not benefits. So your customers wind up seeing lots of information about your equipment. But they don’t have much insight into how your products or services can help them, uniquely. That kind of writing doesn’t produce the results you’re looking for.

Another is that people are used to asking technical communicators to merely carry out solutions, rather than asking them to solve problems. As with everyone who works for you, if you can get them focused on solving problems themselves, rather than just carrying out your detailed game plan, you will get more bang for your buck.

Also, if you don’t determine what the value of the work is supposed to be ahead of time, you may not see much value in the work at the end of the project. Be sure to carefully define what it means for the documentation for the project to be “successful”.

If you’re still not sure if your technical communicators are producing what they need to, look into using metrics to compare one technical communicator’s work with another’s. Just keep in mind, no metric is foolproof. You need to include both quality and speed, as well as other factors that are applicable to your business (see this article from idratherbewriting for more information).

Finally, show your technical communicator(s) that you value their work. If you are focused on seeing value in their work, they will be more inclined to do so, also.

Tell them when it’s due when you ask for their help

This is an obvious one. But we miss it all the time, don’t we? If your technical communicator doesn’t ask when something is due when you ask for their help with it, then tell them. All kinds of chaos ensue when technical communicators don’t know what their deadlines are.

Learn to use scribes

Were you not expecting this one? If you’re going to use technical communicators effectively, you need to learn to use them in new ways.

A scribe, also known as a technographer or a chart writer, can make you look like a genius in meetings that you lead.

A scribe’s task is to take things off of your plate during a meeting, so that you can focus your efforts on driving the discussion. These tasks may include:

·   Recording action items and key decisions

·   Taking minutes

·   Running the computer/projector

·   Manipulating documents during the meeting

In the fall 2014 issue of Pragmatic Marketing, instructor Dave Daniels says:

It’s not necessary to invite every member to every meeting, but be sure to indicate who is required to attend and who is optional. Include someone to track time and document action items, issues, and decisions. This frees the leader to focus on driving the meeting. When an action item is raised, document it, assign it and set a date for completion. When an issue is identified, document it and assign it. Likewise, when a decision is made, document it.

Of course, organizing your meeting well helps you get the most out of your scribe. Make sure that everyone knows the meeting’s goals ahead of time, and has been given enough information to prepare to contribute. Only invite the people who need to be there, and focus your efforts on getting key stakeholders to the meeting. Make it personal.

A scribe can be your right hand man or woman in a meeting. They are an almost invisible, valuable aid. Use one.

Did we miss any keys to using technical communicators effectively? Let us know! 

What is Technical Communication?

The problem

I’ve never been able to make what I do sound macho. I’ve never been able to make it sound cool.

If I tell you that “I capture and arrange technical content in ways that help businesses make good decisions,” does that make your head spin? If I say “I work on processes and procedures,” does that make me sound about as interesting as a rock?

People ask me what I do. What do I tell them?

What LinkedIn says

I recently asked the Technical Writer LinkedIn group how they explained what they did. 

By my rough calculation, 54% defined what they did in terms of deliverables (example: I write the manuals that no one reads.) Another 17% focused on how they make information clear, while another 15% focused on how they translate information from one group (say, engineers) to another (say, the general public). About 6% had some other response (yes, I know this doesn’t add up to 100%, but I’m rounding numbers here).

Three respondents said they introduce themselves as a tech writer, but that when they get the inevitable glazed stare, they explain what they do in some other way.

 So, most tech writers seem to define themselves in terms of the deliverables they produce. Is that healthy? It’s simple. But is it how I should define my own work?

The key

What first attracted me to technical communication was the challenge. When someone uses your document, do they get the information they need? Do they know how to complete the procedure? Do they understand how you do business? Do they get what your business can do for them?

Over the years, I’ve learned that there’s a lot more to good technical communication than just writing good documents. What good is your document if no one winds up reading it? A document can be well-written, but if it’s buried someplace where no one will see it, then you’ve wasted money. If you don’t begin with the end in mind, you will write junk.

Here’s the real question you have to answer: When clients, employees, or regulators need some specific information about your business, can they find it? If so, that’s good technical communication, whether that information is in a procedure, a brochure, or any other medium. How do I convey to people that what I really do is make that communication clear?

What it’s not

One of the most important things to realize is that technical communication isn’t a tech writer sitting off in a corner, writing stuff. And it’s not just fixing typos and formatting the words in a certain way. People who do that are important. But doing those things doesn’t make them a technical communicator.

A true technical communicator must be able to:

·   Understand the problem that the business is facing

·   Come up with the best ways to measure whether the documentation works

·   Extract the information they need

·   Communicate the right information to solve that problem

·   Be able to see the big picture, and decide whether or not the way they are handling the content will be effective down the line

Why I love it

Even if it’s hard to explain, and even if no one ever hands me a medal or retires my jersey, what I and other (good) technical communicators do is still amazing.

When we do what we do, a company’s clients understand what the company does for them. When we do what we do, the other CPAs suddenly get what the first CPA was talking about. When we do what we do, businesses that were spending too much time training and hunting down information can focus on growing their business.

That’s why we’ll keep doing this, helping more and more businesses be understood.


If you have any advice on making my profession sound cool, or if you need help solving a technical communication problem, contact us!