Purpose
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!
Elite Documentation Inc. 