Products and Processes: Transition from “Product Documentation to … Integrated Technical Content”

James M. Dubinsky

Abstract

Purpose: To examine the attitudes and perspectives of individuals in successful companies who manage technical communicators with a specific focus on the products and processes that make up the bulk of their work.

Method: This study used a modified Delphi method. To gather data, we used two sets of survey questions and two structured interviews.

Results: This research helped to further explain the relationship between what technical communicators produce and how these products function in situating or framing their producers in relation to other subfields/related disciplines, such as UX design, information design, knowledge management, usability, and information architecture.

Conclusion: While there is general agreement among the managers that the role of the technical communicator has to expand, there is no one clear agreed-upon strategy. Some companies are obtaining success using Agile methodology, while others are finding that this methodology, while stressing adaptability, is not easy to introduce. Corporate cultures do not change overnight. Still, integrated teams, a key component of Agile, are taking hold in most cultures. Equally important, the shift away from writing documents to directing content is well underway. The key now, as it has been for decades, is for technical communicators to highlight their value and make their contributions more visible.

Keywords: content management, content experience, products, processes, how-to videos, user advocates, Agile, design, productivity.

Practitioner’s Takeaway

• Technical communication managers believe that the roles for technical communicators need to expand.
• They argue that technical communicators need to focus on the “content experience” more than on simply writing and editing.
• They observe that technical communicators need to become much more attentive to customer satisfaction by managing content and keeping it “lean.”
• Certain skills need more emphasis, such as learning to interview, to develop effective videos, and to use social media to help orchestrate or facilitate the “content experience.”
• They encourage technical communicators to become stronger advocates for the value they add to the company.

Introduction

In 2000, George Hayhoe, then the editor of this journal, outlined the foundational skills technical communicators should possess: “writing, editing, visual communication, multimedia, document design, audience and task analysis, usability testing of products and documents, and interpersonal communication” (p. 152). Our field was in the midst of “an exciting time for technical communicators” (Redish, 2002, p. vii), which was evident from the growth of membership in the Society for Technical Communication from “13,778 members” in 1991 to “21,789 members” in 2001 (Redish, 2002, p. vii).

By 2005, however, the tone had changed. In his introduction to a special issue of this journal on the future of the field, Hayhoe (2005) was less enthusiastic: “Our profession has certainly had its share of misfortune in the early years of this decade. I’m optimistic about the future, but it will require us to respond to challenges more daunting than any we’ve confronted before” (p. 265).

These challenges were, at least in part, marked “by the growth of technologies that promote an increase in the publication and distribution of content online, as well as interactive capabilities of computer and communication networks” (Carliner, 2010, p. 42). Confronting these challenges head on, a group of technical communicators at The Boeing Company (2008), wrote about how they had developed a “Future Skills team” which had its roots in “2003, [when] the Writing and Editing (W&E) organization rewrote their job descriptions” and expanded in scope in 2005 when “the Technical Communications group’s manager decided to form a small volunteer team.”

This evolution has led to shifting responsibilities, a wider range of tasks, and an increasingly complex set of strategies or processes. Our profession is quickly becoming one in which technical communicators need to be, in the words of the Future Skills team (2008), “versatilists,” who should be “full-time usability professional[s]” or “content-strategist[s]” (Redish, 2010, p. 195). A consequence of this shift is “the era of document-based information development (ID) … is coming to an end” (Anderson, 2014, p. 10). Other practitioners have seen the shifts and attempted to describe them. Giordano (2011) explains it this way,

Twenty years ago the tech writer’s job resembled a game of hopscotch. It was very straightforward and predictable. We were the makers and keepers of procedural documentation. Technical writers around the world would get an assignment (hop), create an outline (hop), ask some people who know some things some questions (land), write a procedure or a manual … and wait for the next revision… . These days our jobs are far more complex, and we typically travel well beyond creating traditional procedural documentation… . Today our game has evolved … to playing with a Rubik’s cube.

Equally important are a number of other trends, which have resulted in “more technical communicators … now working in project teams” (Hart & Conklin, 2006; Spilka, 2011, p. 5), and, as evidenced above, many members see the field changing names to “reflect [a] broader focus” (Spyridakis, 2009, qtd. in Spilka, 2011, p. 5). This broader focus includes areas such as information architecture, information design, management, and human factors and requires technical communicators to plan strategically to adapt and integrate (Albers, 2005).

However, even with the long-term visioning and the willingness to adapt, one of the critical questions, whenever these future trends are discussed, concerns the long-term viability of the field itself. Clearly this viability concern is real. One need only examine the membership of the STC to see a significant downtrend since the beginning of Web 2.0. Now holding steady at approximately 6000 members (STC, 2014), STC’s membership has been impacted by the global recession as well as the issues mentioned previously. An additional explanation for this downtrend is outsourcing, which seems to be the result of economics but perhaps equally important is the field of “technical communication is as yet either not visible or not valued” (Courant Rife, 2007, p. 228–229). This issue of visibility and value comes up over and over again, particularly during discussions about products and processes, which is one of the driving reasons for this research.

On the Society for Technical Communication’s Web page, technical communication is defined as “a broad field and includes any form of communication that exhibits one or more of the following characteristics:

• Communicating about technical or specialized topics, such as computer applications, medical procedures, or environmental regulations.
• Communicating by using technology, such as web pages, help files, or social media sites.
• Providing instructions about how to do something, regardless of how technical the task is or even if technology is used to create or distribute that communication.

According to the STC, the value that technical communicators deliver is twofold: They make information more useable and accessible to those who need that information, and in doing so, they advance the goals of the companies or organizations that employ them” (https://www.stc.org/about-stc/the-profession-all-about-technical-communication/defining-tc).

This definition (as many of its prior versions over the years) focuses on the products (vehicles or means) of technical communication and the processes technical communicators use to envision and create those products. Early in the introduction to Digital Literacy for Technical Communication: 21st Century Theory and Practice, Spilka (2011) responds to concerns raised by Myers (2009) in her article “Adapt or Die: Technical Communicator of the Twenty-First Century” by saying “technical communicators need to take stock, now, of what recent changes in work contexts mean for their work, and then make a decision” (p.3). One of the goals of this special issue is to examine what some of the technical communication managers in this digital age think about those work contexts. One way toward understanding technical communicators in the 21st-century is to examine companies’ understanding of what technical communicators produce and the processes involved in that production.

Accordingly, this article assesses the attitudes of technical communication managers at several prominent companies toward the products and processes they oversee. It is part of a special issue of Technical Communication that includes companion articles addressing this group of managers thoughts regarding technical communicators’ Identities and Relationships (Baehr, 2015) and their Education and Training (Kimball, 2015b).

I begin the article by summarizing the study’s methodology. Then, to give a baseline of comparison, I outline how technical communication products and processes have been defined and described in the field’s literature over the past decade, with a specific focus on key tensions or questions that have emerged.

This groundwork having been established, I examine how our participants responded to the following basic questions posed in the two rounds of surveys:

• What do you see as the primary products of technical communication in your organization—specifically, what kinds of documentation or information products, and more broadly, what kind of value to the organization?
• What processes do you follow to provide these products?
• Where does or should technical communication happen in product development cycles?

I then examine the clarifications and expansions that emerged from our panel of experts during the interview portions of our study. A final section summarizes, contextualizes, and represents what impact the data gathered might have for the future of the field.

Summary of Methods

For a full description of the methodology for the entire study, please refer to the special issue introduction (Kimball, 2015a). But in short, we conducted a modified Delphi study, which is a methodology intended to assess the ideas and opinions of a group of experts by asking them to address similar questions through several rounds of surveys, interviews, and focus groups. Specifically, we conducted four rounds of data collection:

• Round 1: survey
• Round 2: survey
• Round 3: face-to-face focus group
• Round 4: synchronous online focus group

The population for the study was small, defined by the membership of the STC’s Advisory Council. Nonetheless, the iterative framework provided by a Delphi study generated a large amount of data for analysis and comparison, including survey data, written comments, textual transcripts, and observational notes.

Given the large and multivariate nature of the data, we employed text mining and visualization techniques extensively to code and identify patterns and contradictions in the attitudes expressed by the participants. Statistical information graphics including bubble graphs, sparkline graphs, and radar charts were created using content analysis themes, categories, and relationships. These graphics provided us with a more objective perspective than simple subjective interpretation would allow, and arguably greater reliability than manual content analysis, which relies on subjectively derived codes to begin with. This analysis revealed interesting, though inevitably provisional and exploratory findings.

Survey Responses: Rounds 1 and 2

As discussed earlier, recent scholarship in technical communication has often turned to the next big thing, such as the shift from document to content management. But do companies see technical communicators in these innovative terms, or in some more traditional role? To answer this question, we asked our group of managers and team leaders simply to indicate all of the kinds of products their companies’ technical communicators created.

Products

The list of products (see Figure 1) was adapted from the list on TechWhirl’s Web site (http://techwhirl.com/what-is-technical-communications/). According to our participants, their organizations still see technical writers as focusing primarily on traditional procedural documentation, with the top five products all falling into that general category. Products such as Web sites, training simulations, and even training materials were less common. However, other products associated with the tasks aligned with the definition of what technical communicators do (those who “research and create information about technical processes or products directed to a targeted audience through various forms of media”), such as “how-to videos,” have begun to gain ground as critical products.

How-to Videos. Four of our five participants cited how-to-videos as a common product for their companies’ technical communicators. We were excited to see this high ranking, recognizing the growing ubiquity of the how-to video and the possibilities for technical communicators contributing their expertise in this new medium. Including video as part of the technical communicator’s job is not new; Dicks (2011) noted that this task has been one of several gaining significance as the nature of work changes. However, its prominence among our participants suggested that we should follow up on this result. We did so in Round 2, asking the following open questions:

1. While “how-to” videos clearly fall under the larger category of instructional products, the medium is not often one used by technical communicators. If your technical communicators are producing “how-to” videos or you think they might be doing so in the near future, would you discuss who else in your organization, if anyone, works on these products?
2. Have you hired technical communicators with video production skills in mind?
3. If not, have you offered additional training or sent your technical communicators to workshops/classes?

The responses suggested that while companies are at least beginning to shift from print to video instructions as an essential task for delivering information to customers, this product is not always tasked to technical communicators. In fact, participants were split 50/50 on the question: two said their companies do not task technical communicators to handle this task, and two said their companies are moving that direction. The first two suggested that their companies tasked “other departments” such as human resources, “product evangelist,” “sales/marketing,” or training specialists to create videos, rather than technical communicators. The responses of the two whose companies did use technical communicators to create videos suggested that the shift to video was just beginning:

“Some of our TCers create video material, and that community is growing, because we focus on expanding the skills and capabilities of our TCers with in-house education, etc. We don’t hire for those specific skills, nor do we send our TCers outside for workshops/class at this time.”

“Given the new training media (online videos), the world is definitely moving towards video training. We have not hired Technical Writers with video production skillset in mind. However, we have provided basic training to them to produce photo/ video products.”

Yet even one of these participants seemed to see video instructions as something all groups would do, rather than something technical communicators could specialize in:

“Outside of TC deliverables, video is a very popular format, so nearly anyone creating content—including our technical community, our sales enablement community, etc.,— is creating video content. We have a corporate level standards, guidelines, best practices, and enablement for creating video.”

These results highlight several important issues. First, we are at a place where practice may be leading research. As Poe Alexander recently pointed out, “we are only beginning to theorize about usable design practices for videos, including the nature of the task performed” (2013, p. 238–239).

Second, the assignment of this important task to “sales/marketing” or HR departments may be a lost opportunity for companies and for technical communicators, who ideally have valuable expertise in usability—a value perhaps less prominent in these other fields. If this task is not seen as one that belongs to technical communicators, we may be losing an important role in the company, one very much linked to several of the key tasks included in our self-definition, but most explicitly linked to “Providing instructions about how to do something, regardless of how technical the task is or even if technology is used to create or distribute that communication” (STC definition).

White Papers and Policy Documents. We also found the relative prominence of white papers and policy documents as important products interesting, having the same prominence as knowledge based articles. This result led us to ask a follow-up question in Round 2: “Are policy documents and white papers genres that most technical communicators you hire feel comfortable writing? If not, do you hire technical communicators with a specific skill set for these products? If so, what would that skill set include?” We received the following responses:

“Our TCers feel comfortable writing any of kind of technical documentation—including policies and white papers.”

“Most tech writers still see P&P as a specialty field. Structurally, it is very similar to traditional forms of TC, so this shouldn’t be an issue.”

“We have a small hand in policy documentation. Content is written by legal and published by us.”

“Policy documents written from scratch is where the Techncial [sic] Writers add most value; then regular upkeep can be done by document subject matter experts. White papers are typically written by Engineering Subject matter experts with a final edit by technical writers.”

In the four companies that responded, policy documents and white papers seem to have become a part of the role technical communicators play. More to the point, clearly in one company, by writing these documents, technical communicators are “add[ing] value.” In other companies, these genres are seen as within the comfort zone of technical communicators or similar in nature to what is considered “traditional forms.” These responses support claims by Giordano (2011, para. 6 ) and others who say that “more often than not we’re [technical communicators] asked to create policies, troubleshoots FAQs, … white papers … and a host of other ‘information products” as a way of dealing with a more complex workplace.” In essence, to add value, the technical communicators need to become “versatilists,” as described by Allen et al. (2008, p. 3). In so doing, technical communicators can “function as proactive partners who are skilled in leveraging information” (Allen et al. 2008, p. 3).

Importance of the Products

In addition to asking what products these companies saw as important outputs for technical communicators, we asked participants to rank the importance of those products, from “mission critical” to “not something we do” (see Figure 2). We weighted the most critical as “1” and least critical (not something we do) as “5.”

As the sparklines in figure 2 suggest, traditional products like user manuals, planning documents, instructions, requirements/specifications, and reference materials (knowledge base articles and FAQs) rise to the top of the list as “important” or “mission critical” products. Again, we see videos also recognized as “important” or “mission critical” products, which is especially interesting even as we learn that they are not always the purview of technical communicators.

One response that did not come from these questions, but from the set concerning identity is critical to raise here. In answering a question about the relationship between usability testing and technical communication, one participant said, “Content is a product like the software, hardware, etc. that our companies create.” Considering “content” as a product helps to explain some of the transformations that are occurring. In its most elemental form, what Shank (2008) called “microcontent,” writers are no longer producing any of the products listed above, at least not in their final form from start to finish. Rather, they are producing parts of those products that later will be aggregated in various ways to create a number of larger products.

Processes

Another important question in our field concerns the role of technical communicators in the workflow of their companies. Focusing on a primary work product for technical communicators—documentation—most researchers and theorists have argued for technical communicators to be involved actively in all stages of the process with a primary role as a “user advocate” (Carroll & Meij, 1998; Redish, 2010, p. 196; Spinuzzi, 2000). Yet, there is evidence that, even with decades of research to support this role, many companies do not fully integrate their technical communicators or permit them to exercise this role as user advocate by having contact with users (Virtaluoto, 2014). Thus it was critical that we not only learned about the products being produced but also about the processes involving technical communicators to produce them. As a result, we began Round 1 with some questions about those processes. By focusing on two of their most important products, we asked our participants to

1. Describe the processes involved. Discuss how an information product would be created from start to finish—Who would initiate the task?
2. How would that task be communicated to the individual(s) or teams involved? Who would be on those teams?

Four participants provided insight about these processes, and while considerable differences exist among the companies, each company involves technical communicators actively in product development. Each seems to imply that there is, at the most basic level, a team concept, validating the importance of teams (see Redish, 2010; Spilka, 2011). And, in at least one company, management seems to play a direct role:

“Our key deliverables are user manuals and embedded and online help. At the start of each release, the writers and managers evaluate the requirements and new features and determine the impact on the documentation. To gain buy-in from the cross-functional team, we create a Documentation Plan for review and approval. We then start testing and documenting the features as they are developed. Docs go through one or two technical reviews. We recently started doing iterative development where ID is part of each scrum team and documenting features for each iteration.”

“Engineering initiates a change to process or product. They will involve a technical writer to help create change documentation as well as create content mark-ups. The change docket and content mark-ups are reviewed, approved and implemented.”

“We use an Agile Scrum methodology for product development which includes the development and delivery of all customer content. The Information Engineers are part of the core product team. They work with the Information Architect to develop both the high-level content roadmap and the specific content plan for each release. Information Engineers engage with their scrum teams during all sprints, attend daily stand-up meetings, End of Sprint and Scrum of Scrum meetings. The information Architect and the Information Engineers work together to develop the epics, stories, and tasks for each sprint. Content is developed, reviewed, and delivered according to the sprint schedule.”

“The writers learn about upcoming features along with everyone else on the product teams. They start with a PRD –> learn about the business logic from product management –> begin writing fairly early in the dev cycle –> firm up writing as feature hardens –> edit writing against feature in test environment –> send out for review by eng and product management –> edit –> send out for localization –> publish with feature release –> publish in rest of languages. The task is usually initiated by the writer, but product management sometimes has special requests. The request is usually made face to face followed by a formal request via our bug tool.”

Besides the ubiquity of teams in all companies, however described (“core product, cross-functional, product), another interesting dimension of the responses was the description of the tasks. The specific language of Agile/Scrum notwithstanding (for example, epics, stories, sprints), a number of the participants indicated that editing remains important, highlighting “reviews, mark-ups, editing.” The role of editor makes much sense as we shift from writer to director, from document producer to content experience provider.

Analytical Approaches

The next question dealt with analytical approaches used by technical communicators. We were interested to learn how technical communicators gathered the data necessary to create usable products (see Table 1).

The results are not surprising, particularly the use of focus groups and user surveys. Recent studies have shown that a primary means of gathering information on usability and accuracy of content comes from involving users through such vehicles as comment forms (Carliner et al., 2014). But two-thirds of the participants said that technical communicators used “interviews with users and customers.” This finding is significant, particularly the specific focus on creating or valuing of a direct line of communication between the actual user and the technical communicator whose role is supposed to be a “user advocate.”

The use of interviews is also significant to the educational side of the field. We asked whether or not the technical communicators were trained to conduct interviews:

In the question “Of the following analytical approaches, which ones do technical communicators in your organization use?” the range of analytical approaches to data gathering was broad, with every category selected (see the graph below). However, interviews seemed most valued. What special training, if do you provide, support, or expect of technical communicators using these interview methods?

The answers ranged broadly, in that until being asked the question, at least one company assumed that all technical communicators, perhaps everyone, would have solid interviewing skills.

“We use all of these methods in our organization, some more than others, depending on the product team. We provide in-house skill and capability development, as well as enablement assets, to ensure our technical communicators can perform these methods and do so consistently and with high-quality results.”

“We have many internal surveys that provide a good model. I am not aware of any training for how to do interviews. Field testing is handled separately by Engineering/QA: it should be part of TC.”

“We don’t provide any specialized training in these areas.”

“We lack any formal/ informal training. It is assumed the everyone can interview (basic flaw in our assumption).”

For those companies that recognized the need for special training, some in-house training occurred, but in others, technical communicators had to rely on “internal surveys.” Only one indicated that they “provide in-house skill and capability development, as well as enablement assets, to ensure [their] technical communicators can perform these methods and do so consistently and with high-quality results.”

We were also interested to learn about the roles that “customers” play, particularly given a number of concerns about how technical communicators may begin to play less and less a role as the role of customer and direct feedback increases. We asked about the role of user-generated content in their company’s documentation cycle. While the majority of our participants indicated that user-generated content was not important, two (or one-third) indicated it is, and one even went so far as to say that “customer-generated content is playing a larger and larger role in our content cycles.” Given that a number of our participants represented large constituencies, this response seems in line with the data gathered by Carliner et al., who suggest “that technical communication groups with 26 to 50 staff are more likely to use Reader’s Comment Forms than groups of other sizes” (2014, p. 159). At least some of these same groups, once they gather that user-generated feedback, use it more directly and/or seek further input via interviews or other forms of direct contact.

Stakeholders

These responses about customers point to a perennial problem: Whom do we serve? How? Schriver argued that “consumers and citizens” are “the largest of the potential stakeholder groups” (2002, p. 124). Given the responses from the communication managers about working in teams, which would indicate an inherent belief in collaboration (Redish, 2010), the focus on identifying and articulating a direct line of inquiry between technical communicators and users, and individuals’ increasing expectation to have some input in the tools and apps they use, the fact that only one participant indicated involving customers in the content cycles is odd. This response, along with the next question, which focused on the role of social media in the development cycle, indicates that perhaps changes, that Ames and Jenson (2003) indicated were necessary by developing a value continuum, are still to come (see Figure 3).

These key tools, particularly wikis and blogs, along with other interactive tools for customer/user feedback have yet to gain full use, and few of the participants indicated a deep integration of these tools into the technical communicator’s work. In a recent article, Longo asked “how can technical communicators use these new devices and the social media they support to open lines of communication for both cross-community knowledge-making and collaborative design?” (2014, p. 23). Clearly we are not yet at a place where we have the answers, but there are some who argue that we can build on our “soft” skills and understanding of both content and usability to work as either “community managers” or online help forum manager (Firth, 2014; Gentle, 2009). In these roles, even though there are some who argue that they work to undermine the profession (Carliner, 2012), technical communicators can help shape input so that it adds the most value, taking what may be offered as guidelines and transforming or translating this information to clearer, more usable instructions in what Swarts claims “takes advantage of the forum as a theater of proof” (2015, p. 176). While we did not see nearly as much evidence of this kind of work being taken on, there is evidence that these tools are finding their way into day-to-day practices of at least 50 percent of the participants and that one company is working to fully integrate “customers [as] … partners and key contributors in the content development process” indicates movement in this direction.

Technical Communicators and the Design Process

Perhaps the most significant question we asked in Round 2 focused on what seemed to be a contradiction between the emphasis on traditional products (such as FAQs and instructions) and a greater involvement of technical communicators in the overall design process:

In a number of places, participants commented that Technical Communication is moving toward a greater involvement in design—interface design, product design, etc. Yet most of the top-ranked products (planning docs, FAQs, instructions) are pretty traditional. Is this a contradiction? If so, what is its significance? If not, how is design playing a larger role in these traditional products?

This set of responses set up perhaps the largest contrast in overall perspectives. Half of the participants indicated that it was a contradiction: “it is the same difference as it is between what the heart wants and what the mind needs.” One way to parse this comment is to take “mind” as referring to management, which makes sense given another response indicating that “management still grades or evaluates TC writers based on the number of words written.” Changing that metric is critical. When management sees technical communicators as integrated members of teams with a diversity of skills (as “versatilists”), as capable of contributing in ways other than “the number of words written,” then technical communicators have a much more viable future as the other two participants indicated, focusing on the shift to a “more design-oriented approach,” with “writer[s] who [are] part of the development cycle from Day 1.”

“We are definitely focused on moving content from a more development-oriented practice within our company to a more design-oriented discipline. We do not believe that “traditional deliverables” are necessarily a contradiction to that move. Rather, the client and user understanding that comes from a more design-oriented approach, and the better user experience that should result, drives the determination of the content deliverables necessary to support user goals. Sometimes, these are “more traditional” deliverables.”

“Yes, it is a contradiction. In many instances, management still grades or evaluates TC writers based on the number of words written, rather than hours saved through new efficiencies. Many of the benefits of UI and product design experience are “soft” and difficult to measure with computer metrics. Human analysis from management (often is short supply) is an on-going problem.”

“I don’t think that writers will ever play a huge role in design. What is changing, however, is that they are becoming more deeply integrated in the development teams. The model of the passive writer waiting for information is being discarded in favor of a writer who is part of the development cycle from Day 1. That inevitably means they will have some, but probably not a lot, of input on the product. (Usually, that is in the form of UI terminology and workflow, but the overall design of a feature or product.)”

“Yes, this is a contradiction. IT is the same difference as it is between what the heart wants and what the mind needs. While in theory we would like technical [sic] writers to be involved in design; most likely we are bound to utilizing them in traditional means due to the real world constraints (hand-off inefficiency from subject matter experts to technical writers, budgets, there is no one else to do traditional technical writing).”

This question, perhaps more than any other, points out an issue that is at the core of our field’s dilemma. We believe and argue that technical communicators are truly usability focused and design oriented. But, in the end, many companies do not “see” technical communicators as designers because of “real world constraints.” Others feel constrained by their assessment vehicles such as evaluation based on the number of words produced. The positive side is the fact that some companies are more fully integrating technical communicators into the design teams, and most others, at least, understand, in theory, that they ought to do so.

Interview Responses: Rounds 3 and 4

To further supplement the data we gathered in the online surveys and to address the issues or questions still remaining, we met with the participants once in person (Round 3) and also spoke with them in a Web conference format (Round 4). During those conversations, many of the points that had already been discussed were reinforced or further clarified. However, a few points emerged that had only been hinted at or discussed tangentially: (1) how to re-think the development cycle to offer more opportunity to technical communicators and/or to take better advantage of their skill set; (2) how to re-think a position that has heretofore almost always been linked to the act of writing or creating documents to one that is more focused on creating content that is considered an “actor, a player in the story.” This kind of shift does not do away with writing, but it places the act of writing in a subordinate role to what one might call the act of directing.

The Development Cycle

Another important point, which emerged during Round 4, concerns several forces at work leading to a compression of the development cycle. Several of our participants focused on the impact of the shortened development cycle (emphasis mine):

“One of the things that I say in our community is, get on the boat or be irrelevant. And I really think that the way we are creating content today, the way that we’re thinking about content and how it fits into the overall product management, design, development, delivery, process, is changing by the minute, and as you just said, it’s smaller, shorter development cycles and so on. And if we stay where we are, we are going to be irrelevant. That will be bad. Our customers would suffer. So we’re definitely feeling the force of that idea of change. Some of us are embracing it, and some of us not so much.”

“Two to three years back, we would be in the same boat that [name omitted] had described, where we were being marginalized to the last step in the process, and then we had to really work our way upstream and show the benefits. And it was, the whole point of getting to market faster is what helped us get upstream. Currently, though, we are struggling. So we’ve swung the pendulum on the other end, and so now there’s inefficiencies based in us being in every single meeting, because that’s not efficient either… . I think as we squeeze in more and more productivity in this particular millennium, I’ve seen there’s a lot of emphasis on doing more with less.”

As is often the case when change occurs rapidly, people are often asked to “do more with less,” and sometimes the pendulum swings too far in one direction, building in “inefficiencies,” such as mentioned with technical communicators having to be “in every single meeting.” Our technical communication managers are trying different options to address these inefficiencies.

One way that companies are addressing the compressed development cycle is to use a variety of team-oriented strategies, such as Agile Scrum. One of the participants talked at length about this strategy:

“We use an Agile Scrum methodology for product development which includes the development and delivery of all customer content. The Information Engineers are part of the core product team. They work with the Information Architect to develop both the high-level content roadmap and the specific content plan for each release. Information Engineers engage with their scrum teams during all sprints, attend daily stand-up meetings, End of Sprint and Scrum of Scrum meetings. The information Architect and the Information Engineers work together to develop the epics, stories, and tasks for each sprint. Content is developed, reviewed, and delivered according to the sprint schedule.”

The shift in nomenclature for TC positions from technical communicators to “information engineers” and “information architects” is not new (see, for example, Redish, 2002; Spilka, 2002, p. 4), but for a long while these changes have been growing at the fringes of our field. Still, such naming is not fully taking hold. Perhaps it is because, as Baehr points out in his discussion of our field’s identities, “many technical communicators are considered to be hybrids of sorts” (2015 p. 105).

However, whether or not the names change, our managers have made efforts to adapt through such strategies as Agile. While only one of the other participants explains that their company has successfully adopted it, at least one other company had attempted it: “Our company has tried Agile/Scrum with limited success.” Clearly these new strategies can add value in terms of creating more effective teams and helping to compress the development cycle, but it also seems as if its implementation is linked to the culture of the organization, and some cultures tend to support Agile better than others. Part of the issue is that this strategy seems to flatten the structure and blur boundaries between roles: “We are starting to adopt the Agile/Scrum approach. It is tough to establish the roles and responsibilities as the lines between engineering and technical writers are getting blurred by the day.”

Shifting from Writing to Directing

The lack of visibility, the shrinking development cycle, and the problem with management who focus almost exclusively on a quantitative measure (for example, counting the number of words produced or reduced) that is virtually unrelated to the value of the product or the product’s value to the customer have all plagued technical communicators and, along with the perceived advantages of such managerial decisions as “outsourcing” have led resulted in a shrinking of our field and a lowering of morale. That said, many of the participants we spoke to have not thrown in the towel. Instead they are working to revision the field by finding new ways to perceive and describe the work technical communicators do and the value technical communicators add.

“This is more about, ‘How do I solve this business problem?’ So the business use case has become really the thing that we’re trying to identify as technical communicators. And I know at [company name] we look a lot at trends in customer support issues. We want to see where people are having difficulty with our product, and those then will bubble up and become the high-priority use cases that we tackle with the content. Those are the things, the problems we want to solve for our customers so they don’t have to call support.”

“They’re very, they have twenty, thirty years of writing about the product, and this isn’t about the product. It’s about the customer’s business, and the product is an actor, is a player in the overall story, and so it’s how to apply that product in the context of the customer actually getting some business value. And often the documentation, if you will, is not about the product, it’s about ‘How do I think about my business in a different way?’”

Technical communication managers are focusing more on the notion of “business problem[s],” and, as a result, are looking more closely at “customer support issues.” They are also thinking more broadly about the notion of what is being produced, thinking not so much about the actual “product” qua “product,” but about the product as “actor.” If the product is an actor, then the person composing, moving, adapting that product is now more of a “director” than a writer. The role of technical communicator as “director” fits more readily with the way the field is moving, especially as we increase the amount of time spent on creating videos. As one of the participants said when asked about barriers, contributions and opportunities for technical communicators: “Tech communicators have created ‘word pictures’ for centuries. All we have to do is transmute ‘text only’ word pictures into actual graphics and videos.” Such work is the responsibility of directors who, in the words of another participant, “bring information to its useful life.” Such work is in line with two responses we received when we asked “In the past five years, how has the role of technical communicators in your organization changed?” One participant said technical communicators have moved “from a passive role to an active role” while another said they have moved “from solely focusing on product documentation to leading a coordinated approach to integrated content.” Finally, such a role accounts for the following comment: “I mean, it’s very much less ‘Type your name in the name field’ and much more ‘How do I determine the perception of customers, the perception of my brand by my customers’.” Such roles fit well with shifting the primary focus from writing to directing, where technical communicators can more fully achieve the goal of creating a content experience for users.

Creating a Content Experience

Over the past decade, one shift in the discussion of product and process that continues to gain prominence is the emphasis on content as experience. In the introduction to one of the first books focusing on this notion of content, Schriver (2003) outlines a key theme: “information designers need to be more critical about the nature of the content they present… . Without detailed information about their stakeholders’ expectations and needs for content, organizations can produce artifacts that fail, even though they look nice and read well” (pp. x–xi). Such is the work of our technical communicators.

In some ways, Schriver’s point is similar to the one being made by Firth (2014) and others who believe technical communicators have a strong role as community managers who serve as “advocates” who create “experiences” based on content, as described below.

Because content is the experience [italics mine]. Especially in the last five years, functionality in my view is totally taking a backseat to the communication that has to happen. And that’s not just the text communication, that’s a video communication, that’s an interaction communication that’s a visual communication. Right? And it’s all 5,000,000% communication. So that is so critical to the client experience and when we look at something even more content oriented like marketing and we start thinking wow, marketing is responsible for discover, evaluate, buy in our little process, excellent, but they want advocates, which is like on another hand. Well after you buy, you never go back to marketing content. What’s the gap between buy and advocate? I keep telling our marketing people, the gap between buy and advocate is technical content and product experience. That is the gap. What is turning your buyers into advocates for our product? Me.

There are a number of ways to create advocates and bridge the “gap between buy and advocate. One of our participants was pushing vigorously for the line to the users to be bridged by “moving [their] content from [their] old CMS to a wiki.” In doing so, they focus on ridding the “experience” of “redundant content” and making it “lean.”

“There’s a lot of obsolete content. So as part of this transformation of the content we’re applying lean content best practices to make it much more useful and usable for our customers.”

Thus, the focus returns to the user and the customer.

Process and Product: A Visual Perspective

As Kimball (2015a) describes in the introduction to this special issue (p.94), one of the tools we used was Leximancer, which “automatically analyses … text documents to identify the high level concepts …, delivering the key ideas and actionable insights …with powerful interactive visualisations” (Leximancer). One such exploratory visualization contains the text from the questions in rounds 3 and 4 (see Figure 4). As described in the introduction to the special issue, Leximancer processes natural language texts to identify significant concepts, then groups the concepts into more- or less-coherent themes, which are heat-mapped to correspond to a connectivity rating. Please note that the size of the circle for each theme carries no significance—the software simply sizes the theme circles big enough to make room for the concepts they contain. However, the distance between concepts is significant, as is the number and length of paths necessary to get from one concept to another. Closely related concepts are visualized as close to one another on direct paths, while distantly related concepts are visualized as far apart, linked by multiple steps. The theme bubbles are also heat mapped for their relative coherence or connectivity, in this order:

• Content
• Process
• Customers
• Development

As this diagram shows, the four speakers all had different “centers of gravity.” But two of them (speakers one and two) seemed to be focusing directly on connecting content, design, development, and the role of technical communicators. However, “Technical” and “Writing” are on the fringes of the content theme; it may be a way that managers evaluate technical communicators, but it is not the primary task for technical communicators any longer. Yes, technical communicators must write to create new content, but in many cases, the majority of their time will be spent directing—managing and editing content to create a better, more satisfying customer experience.

Clearly, adding value by tackling key tasks related to policies and adding participation in composing white papers will keep a focus on the value of traditional “writing.” But the skills necessary to direct newer media —whether in learning or enhancing interview skills and working to polish or develop the skills necessary to create tutorial, how-to videos—will play an increasing role in technical communication. As Mette Nyberg stated recently, “In theory, the Writer’s Toolbox should not have any reference to ‘the product’… . No matter the nature of the product, the technical communicator can rely on the skill set to complete the task of developing contents for the ‘product’” (2013, p. 66, emphasis mine).

Conclusion

This research has helped to further explain the relationship between what technical communicators produce and how these products function in situating or framing their producers in relation to other subfields/related disciplines, such as UX design, information design, knowledge management, usability, and information architecture.

As has been evident for well over a decade and, more realistically, since the mid-1990s when the age of computers started to create more rapid change in our discipline along with the rest of the world, technical communicators have been facing an identity crisis—trying to decide what defines them. Is it products (what they create)? Processes (what they do)? Where they fit in the overall scheme of the development cycle—the process of bringing products to market? In the last few years, economic forces have led to a shortening of the development cycle. That kind of compression has consequences for everyone in the cycle, but at stake for technical communicators is whether or not they are able to remain relevant. One participant’s point struck home:

“the folks who do have those skills are somewhat, what’s the word I want, marginalized, because they belong to, quote unquote, IT or the technical writing group. And design in our organization today has taken a much bigger role, has a lot more power, authority, and so on, and so there’s a lot of marginalization of content because it’s not considered a design discipline.”

Or as another participant put it,

“You cannot be the long pole in the tent, and if you don’t want to be the long pole in the tent, you have to be walking along with them so that you’re not the last person out.”

If content is supposed to be king, and even more to the point, given the fact the participants are beginning to rename themselves and those who work for them as “content experience strategist[s],” then a “marginalization of content” becomes a point that must be addressed. Most of the participants recognized this issue as valid, and what was refreshing was rather than deny a problem existed, they were working to reframe the discussion. Rather than acquiesce to a marginalization of content, they argued the importance of working within their companies to “ensure that content has high visibility … which means that it needs to be a focus of design as well, and since those skills are not there, we need to get content people into the design role in a more conscious way.”

To assist in this process, several managers argued along the lines of creating a special category of content, which they call “high-value content,” which is “content that’s really focused on helping customers achieve a business goal or helping users achieve a technical goal that is really driving their business and giving them business results.” This discussion of value and its separation from physical products is not new. In 2002, Faber and Johnson-Eilola said, “We must find ways to leverage our knowledge and build new knowledge to create and add value in a business culture that is increasingly agnostic to physical products” (p. 141).

A third response focused on a slightly different role—that of being “another pair of eyes” focused on the content, and then, as part of the team, they are present to provide a “sanity check.” As one participant said,

“We have a much wider role, which is to review every string message and UI label. We have a UX team, they design it, they’ll implement it, QE test it, and then we go through with sort of a sanity check, I guess it is, just for the end user perspective, asking questions when we think things don’t make sense or terminology’s not consistent. I think it’s a good thing overall, because it really adds value to the product, the overall look and feel of the product as well as how it works, how you navigate through it, and I think it adds value to the organization as well. Again, it’s like another pair of eyes looking at things.”

In all of these responses, it is clear that an important strategy is to involve technical writers “or the content contributors, … more … in the overall user experience and the design of the documentation, even the design of the product.” Regardless of whether the content is seen at the presentational level or not (Kimball, 2015b, p. 140, this issue), it remains clear that the importance of functioning as an intermediary between the content experts and the users is where the value lies.

As one of our participants reflected at the very end of the Web conference, the situation is not necessarily dire. Even if the age of document-based information development may be dead, there are many interesting and potential avenues for technical communicators to pursue.

“I think that most of us are in agreement that the role of the technical communicator has to expand. I believe we have to keep pace with what’s happening in the world. Technology and information is just so fluid right now, and so dynamic. I think, in terms of the career path, technical communicators are, are not doing what they did even five years ago. I think they’re all being asked to do more and more and to broaden their skill set. And actually, from the career perspective, I think that for a technical communicator, that’s kind of exciting. Because I think that one of the things that they can do is, they learn new skills and grow these new skills. They have opportunities for other positions, especially in larger companies like mine. A technical communicator can easily move or, I should say, much more easily move, around the organization because of the skill set that we’re able to give them, and it goes well beyond writing.”

Because the situation is dynamic and “fluid,” it opens up opportunities. As Albers explained very early when discussing problem solving and content analysis, “The potential choices and reasons for making the choice become the dominant factor” (2003, p. 263). His comment has relevance as we consider the potential choices facing technical communicators and managers. Our field’s practitioners and its managers need to embrace the complexity involved and demonstrate how, by editing and directing they can help solve the “business problems” by shaping content into coherent products that meet customers’ quickly changing needs. Technical communicators are, after all, the ones who work in the intersection between the content itself and the customers. We can help those customers process the increasing amount of information available in dynamic and constructive ways.

So, to conclude, I’ll end with questions one of our participants posed as he pondered this fluidity:

“[T]wo to three years back, we would be in the same boat that [another participant] had described, where we were being marginalized to the last step in the process, and then we had to really work our way upstream and show the benefits. And it was, the whole point of getting to market faster is what helped us get upstream. Currently, though, we are struggling. So we’ve swung the pendulum on the other end, and so now there’s inefficiencies based in us being in every single meeting, because that’s not efficient either. So we’re trying to achieve that right balance of, when do we get engaged? At what point in time?”

I can’t answer this specific question of when each technical communicator should get engaged in the development process, but I am absolutely certain technical communicators need to be much more engaged in the definitional, advocatory, and educational processes surrounding the products and processes related to the work they do. Technical communicators should consider how they can be more involved in gaining (or teaching) video, social media, and interview skills. And they should take to heart the reality that one of the participants outlined in discussing the challenges the field faces: “I don’t know whether or not tech communicators will move to a design emphasis, but the products they support certainly will… . These products are simply too complex, especially if we write to help the user ‘achieve goals’ rather than tell them about the UI.” By more clearly adopting the roles of director and editor, they can almost bypass the issue of whether or not they are “designers.” Instead they become the user advocates leaders in the field such as Redish have argued for decades that technical communicators should be (2010, p. 196).

In closing, whenever I face questions of this import, I often return to an essay I read the first year I taught, Annie Dillard’s “Seeing” (1973). In it she says, “I’ve been thinking about seeing. There are lots of things to see, unwrapped gifts and free surprises. The world is fairly studded and strewn with pennies cast broadside from a generous hand… . [and] if you cultivate a healthy poverty and simplicity, so that finding a penny will literally make your day, then, since the world is in fact planted in pennies, you have with your poverty bought a lifetime of days.” (p. 19). In this instance, the pennies the world of technical communicators is strewn with are pennies of content; and content is what needs to be cultivated. The tools we choose are important; the education we seek and advocate for will help our crop grow. Most important will be our attitude, which needs to be rooted in versatility.

References

Albers, M. J. (2003). Complex problem solving and content analysis. In M. J. Albers & B. Mazur (Eds.), Content & complexity: Information design in technical communication (pp. 263–284). Mahwah, NJ: Lawrence Erlbaum.

Albers, M. J. (2005). The future of technical communication: Introduction to this special issue. Technical Communication, 52(3), 267–272.

Allen, K. S., Whitehorn, R. S., Carey, C. M., Dowell, R. S., & Bartell, A. L. (2008). Identifying future skills for technical communicators: An action plan. IEEE Professional Communication Conference, 2008. IPCC 2008. IEEE International, Montreal, QC: IEEE. doi: 10.1109/IPCC.2008.4610191

Ames, A. L., & Jensen, S. M. (2003). Transforming your career: Contributing strategically to your company or client. 51st Annual STC Conference Proceedings, Baltimore, MD: Society for Technical Communication.

Baehr, C. (2015). Identities and relationships of technical communicators in leading industries and companies. Technical Communication, 62(2), 104–117.

Carliner, S. (2010). Computers and technical communication. In R. Spilka, (Ed.), Digital Literacy for Technical Communication (pp. 21–50). New York, NY: Routledge.

Carliner, S. (2012). The three approaches to professionalization in technical communication. Technical Communication, 59(1), 49–65.

Carliner, S., Qayyum, A. & Sanchez-Lozano, J. C. (2014). What measures of productivity and effectiveness to technical communication managers track and report? Technical Communication, 61(3), 147–172.

Carroll, J., & Van der Meij, H. (1998). Ten misconceptions about minimalism. In J. M. Carroll (Ed.), Minimalism beyond the Numberg funnel (pp. 55–90). Boston, MA: MIT Press.

Courant Rife, M. (2007). Review of the book Technical communication international: Today and the future, (Vol. 9) Schriften zur Technische Komunikation, Band 8. In Journal of Business and Technical Communication, 21(2), 227–232.

Davis, M. T. (2001). Shaping the future of our profession. Technical Communication, 48(2), 139–144.

Dicks, R. S. (2011). The effects of digital literacy on the nature of technical communication work. In R. Spilka (Ed.), Digital literacy for technical communication (pp. 51–81). New York, NY: Routledge.

Dillard, A. (1973). Seeing. In Pilgrim at Tinker Creek (pp. 19–36). New York, NY: Harper’s Magazine Press.

Faber, B., & Johnson-Eilola, J. (2002). Migrations. In B. Mirel & R. Spilka (Eds.), Reshaping technical communication (pp. 135–148). Mahwah, NJ: Lawrence Erlbaum.

Firth, J. (2014). Forum moderation as technical communication: The social web and employment opportunities for technical communicators. Technical Communication, 61(3), 172–184.

Gentle, A. (2009). Conversation and community: The social web for documentation. New York, NY: XML Press.

Giordano, C. (2011). Integrated technical communications: A strategy for technical communication. TechWhirl Magazine. Retrieved from http://techwhirl.com/integrated-technical-communications-strategy-for-technical-communicators/

Hart, H., & Conklin, J. (2006). Toward a meaningful model for technical communication. Technical Communication, 53(4), 395–415.

Hayhoe, G. (2000). What do technical communicators need to know? Technical Communication, 47(2), 151–153.

Hayhoe, G. (2005). The future of technical communication. Technical Communication, 52(3), 265–266.Hea, A. C. K. (2013). Social media in technical communication. Technical Communication Quarterly, 23(1), 1–5.

Jones, D. (2000). A question of identity. Technical Communication, 42(3), 567–569.

Kimball, M. A. (2015a). Special issue introduction: Technical communication: How a few great companies get it done. Technical Communication, 62(2), 88–103.

Kimball, M. A. (2015b). Training and education: Technical communication managers speak out. Technical Communication, 62(2), 135–145.

Leximancer. (2014). Retrieved from http://info.leximancer.com/

Longo, B. (2014). Using social media for collective knowledge-making: Technical communication between the global north and south. Technical Communication Quarterly, 23(1), 22–34.

Lyons, C., & Brown-Hoekstra, K. (2014). 2014 Year in review. Washington, DC: Society for Technical Communication.

Mirel, B., & Spilka, R. (Eds.). (2002). Reshaping technical communication. Mahwah, NJ: Lawrence Erlbaum.

Myers, E. M. (2009). Adapt or die: Technical communicators of the twenty-first century. Intercom, 56(3), 6–13.

Nyberg, M. (2013). Advice from a professional: The DNA of a technical communicator. Communication & Language, 2, 64–71.

Poe Alexander, K. (2013). The usability of print and online video instructions. Technical Communication Quarterly, 22, 237–259.

Redish, J. (2002). Foreword. In B. Mirel & R. Spilka (Eds.), Reshaping technical communication (pp. vii–xiv). Mahwah, NJ: Lawrence Erlbaum.

Redish, J. (2010). Technical communication and usability. IEEE Transactions on Professional Communication, 53(3), 191–201.

Schriver, K. (2003). Foreword. In M. J. Albers & B. Mazur (Eds.), Content & complexity: Information design in technical communication (pp. ix–xii). Mahwah, NJ: Lawrence Erlbaum.

Shank, P. (2008). Web 2.0 and beyond: The changing needs of learners, new ways to learn. In S. Carliner & P. Shank (Eds.), The e-learning handbook: Past promises, present challenges (pp. 241–278). San Francisco, CA: Pfeiffer.

Spilka, R. (2002). Becoming a profession. In B. Mirel & R. Spilka (Eds.), Reshaping technical communication (pp. 97–109). Mahwah, NJ: Lawrence Erlbaum.

Spinuzzi, C. (2000). Genre ecologies: An open-ended approach to understanding and constructing documentation [online]. ACM Journal of Computer Documentation, 24(3), 169–181. Retrieved from http://dl.acm.org/citation.cfm?id=344646.

Swarts, J. (2015). Help is in the helping: An evaluation of help documentation in a networked age. Technical Communication Quarterly, 24(2), 164–187.

Virtaluoto, J. (2014). “Death of the technical communicator”—Current issues and future visions for our field. Technical Communication, 61(1), 38–47.

About the Author

James M. Dubinsky is associate professor of rhetoric and writing in the Department of English at Virginia Tech (VT) where he directs the Center for the Study of Rhetoric in Society (CSRS). From 1998 until 2007, Jim was the founding director of the Professional Writing program, and from 2008–11, he served as founding director of VT’s Center for Student Engagement and Community Partnerships (CSECP), now VT-ENGAGE.  Jim is also a veteran, having served in the US Army on active duty from 1977–1992 and in the reserves from 1992–2004 before retiring as a lieutenant colonel. Contact: Dubinsky@vt.edu.

Manuscript received 8 April 2015; revised 6 May 2015; accepted May 7 2015.