I hear a lot of complaining these days about the quality of technical documentation being written offshore. I hear it mostly from the people who are responsible for making the decision to move tech docs offshore to begin with. Let me try to elucidate the problem from end to end.
As time has gone on, and technology has become more commonplace and less mysterious, the information that we create to explain how to install/use/administer technology products has become less important in the eyes of our upper management. Ease of use has morphed into “Do we have to provide instructions?” Technical writing as an art form has become commoditized. As with all commodities, the most important aspect from an upper management perspective is to get the docs created as cheaply as possible. I have actually heard upper-level managers say, “Good enough is good enough. I don’t care about quality. Just make it cost less money.” Scary, no?
Budgets for technical documentation have been slashed and much cheaper alternatives to the U.S. tech writing market have popped up. Offshore creation of technical manuals is so commonplace now that I cannot think of one large customer who isn’t using offshore writers for at least a portion of their documentation creation. And, from an upper management perspective, it is compelling. Last time I checked, you could hire 3 writers and a manager offshore for the same dollars as a single senior technical writer in the U.S.
However, almost across the board, I have heard complaints about the quality of the content that is being written offshore. Sure, there are exceptions. I know a few managers who, after searching for months and hiring/firing many offshore writers, are finally very happy. This is the exception rather than the rule. Most of the time, asking writers who have English as a second (or third or fourth) language to create technical instructions does not work out well for the documentation manager responsible for the project.
The same problems are described over and over again:
- The documentation is difficult to understand or it makes no sense grammatically.
- Managing the project is difficult. To have a phone conference with everyone on the project means someone is always in their pajamas; managers here in the US feel like (and do!) work around the clock.
- The culture clash between the offshore groups and the U.S.-based team presents work issues.
- The loyalty of offshore writers is almost non-existent. As soon as you have them trained and doing a good job, they leave for a better paying opportunity elsewhere.
Now, I am not saying that all offshore situations fail or that there is no such thing as a loyal, competent offshore writer who gets along famously with the U.S. team and is willing to work odd hours. These people do exist. And as time goes on, the quality of offshore content has risen and more managers who I talk to have found adequate offshore help. But, I am saying that, overall, I hear more complaints than compliments.
So, what’s a tech doc manager to do?
There is no magic bullet to solving the problems I’ve listed above. Usually, it takes a lot of patience and time to find an offshore writer (let alone an offshore team) that produces to the level most technical documentation managers would like.
Trying to explain to upper management that penny-wise is dollar-foolish only works to a point. If the economy has tanked and budgets are being slashed, getting upper-level managers to pay for quality documentation is a Herculean task at best. Sometimes, if customers complain loudly enough – usually to technical support departments – and if the costs of technical support skyrocket, you can get upper management to listen. Customer satisfaction scores (known as “CSAT” scores) can be very compelling. Unfortunately, I don’t know of many companies who measure CSAT scores for documentation. “Ease of installation” is often correlated to the product itself, rather than the instructions that ship with it. I also don’t know of many companies that have metrics for the correlation between poorly written documentation and number/cost of technical support incidents. We intuitively know that if the instructions are confusing, the customer is going to reach out for help. But we don’t have actual numbers to support it.
Now that many people are using social media communities and forums to voice their complaints, the possible brand damage from unhappy customers is more risky. In the past, I could complain to a manufacturer. Now, I can complain to a forum and have many people echo my dissatisfaction. Unhappy customers can do a lot more harm as a community. This argument might be compelling and upper management might listen, but if customers are already complaining in droves, you have a PR nightmare on your hands and it might be too late.
- Work with other groups, such as technical support and training, to gather metrics on customer satisfaction as it relates to technical documentation. Be careful that this tactic doesn’t backfire, making you or your department look worse for pointing out the problem. There is always a danger in pointing out weaknesses on your team.
- Consider onshoring your content. There are areas of the U.S. where salary requirements and hourly rates are much lower than in high-tech meccas. While I’ve never seen rates that are as low as offshore countries, you might be able to find qualified writers here who are willing to work for compelling wages.
- Examine your quality control/quality assurance processes to identify holes that you can plug. For example, see if you can implement QC/QA tools and processes to help catch and fix errors before the docs are released.
- Look for tools and processes that can help your offshore team perform better.
- Solicit help from the community. If customers are starting to complain, reach out to them and find a way to let them help make your content better. User generated content is a blessing and a curse. Think about what you can do to incorporate community content and ideas to help. It is amazing the goodwill you can garner by listening to your customer base.
And when your management finally wakes up and comes to you complaining about the quality of the documentation, do your best to stay calm and remind them that you always get what you pay for. Always.
- Delivering Personalized Experiences at Scale: The History of Personalization - November 18, 2020
- Delivering Personalized Experiences at Scale: The Three Kinds of Output Types - November 1, 2020
- First Things First: Workflow Before Content Goes to Translation - August 17, 2020