by Saul Carliner | STC Fellow

My very first management consulting experience in technical communication involved advising a technical communication group in a large telecommunications firm about quality. The director of the group of about eight departments and 100 people had been told by his vice president that it would be a good idea to “measure” quality. But when the director asked the vice president what to measure, the vice president responded, “I don’t know. You figure that out.”

To prepare for the assignment, I interviewed the eight managers reporting to the director about their work to get ideas about what could be measured. I learned that this group primarily produced documentation to support telephone switching equipment for landlines. Most of the documentation provided guidance for troubleshooting problems with these lines.

I also learned that the company built extremely reliable products, so the documentation was not used much. Land lines have significantly higher reliability than mobile lines—surpassing 99% up time.

Perhaps most importantly, I learned that the biggest problems did not arise from difficulty that users had with the documentation but from internal skirmishes over the documentation with the software and hardware development teams. To this outsider, that seemed to be the focus for the group’s measurement “issue.” The documentation was just-in-case documentation, used “just in case” something failed and the highly trained service representative needed to check something. The real reason this group would need to measure anything was to track relations with the internal teams: The vice president of research and development, the software and hardware development groups, and the quality assurance group.

I suggested that my client focus on tracking the technical communication group’s relationship with its internal sponsor. This was in keeping with the advice of a then-popular book in my second field of training, Training for Impact by Dana and James Robinson, in which they emphasize the importance of managing the relationship with the sponsor’s organization—the sponsor being the person who can authorize or stop payment for services.

This advice was also consistent with advice I had received in courses on marketing research and training evaluation, both of which recommended checking with the client about what’s most important to them. Based on the interviews with the technical communication managers, that relationship with the client was the most important.

The managers agreed.

The director didn’t.

To say he didn’t like the advice, well, let’s just say that I am thankful he paid the bill. (According to Judge Judy, he had to; the law says that if someone provides the promised service, the client is obligated to pay.)

The director wanted to track reader responses to the documentation. I received this assignment as PCs were gaining widespread use in the workplace and the majority of technical communicators worked on end-user documentation. The messages at the time encouraged technical communicators to write for their end users, many of whom were fully dependent on the documentation to use hardware and software that played a central role in their daily work.

The director did not grasp that the needs of untrained users of commercial products, who had a strong dependency on the product information substantially differed from the needs of highly trained users, who only used documentation occasionally and on which they were only moderately dependent. He could not see what was staring him in the face: His vice president was starting to question the value of the technical communication group and she wanted the director to figure out how to please her.

Although end users are important to the effectiveness of technical communication products, they often don’t play the central role in our employment that we think they do.

Yes, I know that’s counter to technical communication orthodoxy.

Consider this: In many cases, end users don’t even play a role in choosing the software or hardware that they use; someone else inside the organization does. Even when they do choose the software and hardware, end users rarely interact with technical communicators. Although end users are central to the act of communicating, they don’t play a role in the employment of technical communicators. They’re often invisible from the daily work of technical communicators.

More significantly, end users do not hire technical communicators, fire us, fund us, or conduct performance evaluations of our work. End users do not outsource our work or determine that programmers, engineers, and other technical professionals are just as capable of producing documentation as professional technical communicators are.

Our “customers” do perform those tasks and make those decisions.

That seems obvious to the 20% to 25% of technical communicators who work for service firms or as independent contractors.

But even those technical communicators working internally have “customers.” These customers include:

• The executive of the group that funds the technical communication group, known as the sponsor, who not only authorizes the budget for technical communication but can also authorize cuts and outsource the function.
• An ombudsperson (if one exists), a person in the sponsor’s organization who acts as the liaison between the technical communicators and the subject matter experts who review the materials, as well as management and the executive of the group.
• Subject matter experts, including engineers, programmers, scientists, business analysts, product managers, legal specialists, quality assurance engineers, and others who have technical expertise and assist technical communicators in preparing their work

Despite the centrality of this executive “customer” and the people who work for them, technical communicators rarely explore their perceptions of us. Although our literature has case studies of particular projects and studies of what employers seek when hiring technical communicators, it is light on general perceptions of technical communicators held by these “customers” across geography, organizations, and industries.

This special issue of Intercom is intended to fill that gap. It reports the results of a survey of “customers” of technical communication. Specifically, it includes the following articles.

• “About this Study” describes how the study was conducted and who participated in it.
• “About Participants’ Working Experiences with Technical Communicators” characterizes the ways in which participants work with technical communicators and their feelings about the experience.
• “Best and Worst Experiences of Working with Technical Communicators” describes, as its title suggests, the best and worst experiences that “customers” have had working with technical communicators, as well as whether these “customers” would continue working with technical communicators if given the choice.
• “Expectations of Technical Communicators” describes the job skills, characteristics, and attitudes that “customers” hold of technical communicators, as well as the extent to which technical communicators meet these expectations.
• “What Drives Perceptions of Technical Communicators” identifies a number of issues that drive perceptions of technical communicators, awareness of which you can use to manage your relationships with your own “customers.”

This focus on “customers” perceptions also aligns with two emerging areas of interest in fields related to technical communication. Within the field of User Experience Design is an emerging discipline of service design, which focuses on the design and implementation of a service like ours, including managing the perceptions of the people who purchase that service (“customers”). The other is an emerging area of interest in the field of training and development called Partnering with Clients, which identifies five core competencies needed to manage relationships with clients.

Before closing, I would like to thank several people for their assistance with this issue. First, I would like to thank STC Chief Executive Officer, Liz Pohland, and Intercom Executive Editor, Andrea Ames, for supporting this project. I would also like to thank the two of them, along with the STC Board, for their help in promoting the survey. Last, I would like to thank Yuan Chen, my co-author, who handled all of the logistics of the online survey.