Jenni Virtaluoto
Abstract
Purpose: The aim of this paper is to explore the current state of technical communication in Finland, with a look into the future of the field as practitioners see it. This article is part of a larger study investigating technical communication through activity theory.
Method: The study utilizes autoethnographic interview data to explore and analyze some of the issues technical communicators are currently facing, and how these issues affect their expectations for the future. The literature of the field is used to further illustrate the points made.
Results:User-centeredness is widely recognized as one of the main quality factors in technical communication, but the current work processes of the field do not allow technical communicators access to users or user data. The interviewees are not satisfied with their current work conditions and fear for the future of the field.
Conclusion: It is discovered that while we are currently facing serious problems, there is still a need for user advocates in the product development process. A new model for technical communication is needed in order for the field to survive.
Keywords: technical communication, autoethnography, activity theory
Practitioner’s Takeaway
- Technical communication has been a main career option for English majors in Finland, including the author of this article, but the current restructuring of the IT sector and the offshoring and outsourcing trends are making the future of the field seem uncertain.
- User-centeredness is widely recognized as one of the main quality factors in technical communication, but the current work processes of the field do not allow technical communicators access to users or user data.
- A new model for technical communication is required while the profession still exists in Finland. This article is part of a larger study exploring the possibility of creating such a model using activity theory.
Introduction
I have been a technical communicator since 1998. Around this time the IT industry began booming in Finland, with Nokia as the flagship company. Suddenly, there was a new job market for English majors such as myself: we may not have known exactly what technical writing was, but we knew we had the language skills to do it. A lot of us fell into the industry quite by accident—as one of the interviewees in this study put it, “I didn’t want to become an English teacher, so this was my getaway.” Others had an interest in technology and wanted to be part of the growing IT sector. This article explores the field of technical communication in Finland as it is seen by the eight Finnish technical communicators I have interviewed. The field has had its ups and downs, with the current challenges being “more daunting than any we’ve confronted before” (Hayhoe, 2005, p. 265).
Although the general tone of this article is somewhat critical, I am fully aware that even today, there are technical communicators who are satisfied with their work—in fact, one of them is an interviewee in this study. I too have had wonderful experiences in the field of technical communication, been able to use my full skill set and grow as a professional of user advocacy. However, the industry today seems focused on technical communication as a commodity, not on technical communication as an art or a field of expertise. It is seen as a drain on resources rather than a value-adding aspect of product development or a form of customer support. Technical communication is not seen as part of the product, which is why it is so easy to subcontract or offshore it. According to the interview data in this paper, the technical communicator is very far removed from the users of the products being documented, and one reason for this is the current subcontracting and offshoring trend. These issues are further explored in sections 2 and 3. Section 4 focuses on the future of technical communication in Finland as the interviewees see it.
Methods
My professional background influenced my choice of research method in this study. Autoethnography—the “ethnography of one’s own group” (Reed-Danahay, 1997, p. 2) anchors the researcher within the phenomenon he/she is investigating. This approach may offer the researcher easier access to information than an “outsider” would have. On the other hand, being an “insider” naturally means that the researcher must put special emphasis on the objectiveness of the study. The purpose of the interview data in this paper is to offer an objective and multifaceted picture of the issues discussed. My own experiences and the interview data will be augmented with previous research in the field to provide a fuller account of the issues technical communicators are facing; in autoethnography, analytic insights are provided through recounting the researcher’s own experiences as well as those of others (Anderson, 2006, p. 384). Although the researcher is visible in the text, the aim is not to generalize one person’s experiences over a complex whole (Anderson, 2006, p. 386). I have only been an in-house technical communicator, which is bound to influence my understanding of the field—none of the interviewees had in-house experience only. In addition, I have only worked with business software and hardware while many of the interviewees had experience of documenting customer products, too. This adds diversity to the data of this paper.
Anderson (2006, p. 375), introduced the term analytic autoethnography to refer to ethnographic work where the researcher is a full member of the group or setting being studied. According to Anderson, the five key elements of analytic autoethnography are as follows:
- complete member researcher (CMR) status
- analytic reflexivity
- narrative visibility of the researcher’s self
- dialogue with informants beyond the self
- commitment to theoretical analysis (Anderson 2006, p. 378).
My background as a technical communicator grants me CMR status; while my ‘self’ is clearly visible in this paper, I attempt to reflect on my experiences analytically and contrast them with the literature of the field as well as the interview data. Finally, the aim is to provide a theoretical analysis of the issues discussed, rather than a subjective, narrative account.
Eight technical communicators were interviewed for this study. I used by my own professional networks to find the interviewees, who are based in three different Finnish cities. The interviews were originally conducted in Finnish and have been translated into English by me. Six of the interviewees (A, B, D, F, G and H) have been working both as in-house and as outsourced technical communicators, two (C and E) as subcontractors only. The interviews were face-to-face and semi-structured (di Cicco-Bloom & Crabtree, 2006, p. 315), with questions ranging from professional and educational backgrounds to future visions and aspirations. The semi-structured interview type was chosen in order to have a common framework for the discussions while allowing them to progress freely. None of the interviewees had a degree in technical communication, but three of them (A, B and C) had completed a technical communication minor or other studies in the field. All had a background in English studies and a minimum of 10 years of work experience. The interviews have also been used as data in Virtaluoto (2013).
The aim of this paper is to provide concrete examples of a technical communicator’s work as it is today and how the interviewees see it evolving in the foreseeable future. This paper is part of my larger study investigating technical communication as an activity.
Users: Our Top Priority
We already know that users go to documentation when they cannot get help elsewhere (for example, Anson, 1998, p. 94; Schriver, 1997, p. 384), and they expect it to be accurate and easy to use so that they can complete the task at hand (Anson, 1998, p. 94). In other words, documentation is not read from cover to cover, but to solve current problems as they come up, and often as a last resort. According to, for example, Price and Korman (1993, p. 6) and Van der Geest (1994, p. 54), we should be able to show users how they can carry out the tasks in their own work, rather than describe the product and let the users figure out how they can benefit from it. Spinuzzi (1999, p. 21) points out that we should be aware of the user’s activities and available resources for the documentation to fit into its intended environment—its “ecology of genres”—and to be truly useful. Spinuzzi goes on to emphasize the need for “coauthoring,” the technical writer as a collaborator and facilitator for the user (1999, p. 21).
My own experiences in the field of technical communication correspond with the above visions of user-centeredness. I was once involved with documenting a radio broadcasting system called RadioMan, which encompassed the entire workflow at a radio station—from editing various types of material to broadcasting and archiving. The company producing the RadioMan system was small and flexible, allowing me to broaden my own professional horizon from technical writing to training and consulting. Once, while I was presenting the RadioMan software at a User Group meeting, one of the system’s users came up to me to discuss documentation issues: they had recently gotten a new version of the RadioMan user guide, and had questions about the jingle section. The RadioMan system contains a jingle bank for broadcasting short audio clips on top of the actual playlist; these are often ads for future programs, traffic announcements and so on. The way the jingle bank works is quite simple: you can drag-and-drop audio clips from the database onto the jingle buttons on the screen, and then play the jingles by clicking the corresponding button on the screen or by using the special On-Air keyboard that comes with the system. In the studio, the clicks of a mouse are not desired background noise, so the keyboard is mainly used for playing the jingles. On the keyboard, there is a numbered button for each jingle, corresponding with the jingle bank section visible on the screen. Once you play a jingle, an X appears on the button on the screen, but this does not stop you from playing the jingle again: it is just a visual cue showing which clips had already been played.
This was more or less the information provided in the user guide, too, but the person that had come up to me said they wanted to “know more about jingles; you know, more information about them.” I was dumbfounded. To me, that was all the information there was about the jingle bank: drag-and-drop, click to play, play again if needed. It was not until much later, when visiting another customer, that I realized what the user guide was lacking. There was a hectic afternoon show on in the studio, with two audio engineers manning the computers, traffic announcements coming in, guests coming and going, the next presenter waiting in the wings—and the jingle bank was used to wrap up the show in a very innovative way. Instead of playing one short clip at a time, the presenter of the previous show had placed a long, instrumental music piece on the first jingle button and hit play; the subsequent buttons were then used for shorter ads and announcements, fading out the music slightly for each one. With the help of the jingle bank, the audio engineers were able to change the playlist from the current show to that of the upcoming show without interrupting the broadcast, giving the next presenter ample time to get ready. Whenever a jingle was played, a special cardboard place holder was placed on top of it on the On-Air keyboard, making it clear on the keyboard as well as the screen what the play order was. The users had augmented the system with an additional tool (compare to Spinuzzi, 2000, p. 174), and were getting more out of it than we, as the designers of the software, had perhaps intended. The user guide, on the other hand, had been written with the product, not the user in mind: it described the functionality of the product accurately, but did not show how a broadcaster could use it in real life.
In my opinion, the only way for a technical communicator to gather this type of user information is to see how users work in the real world, and it is impossible to be a user advocate without this information (compare to Price & Korman, 1993, p. 6; Van Laan & Julian, 2001, p. 99). This, I thought, would be the future of technical communication. And yet, none of the technical communicators interviewed as part of this research had direct contact with users; none of them attended user meetings or had established feedback channels for user comments. Anson (1994, p. 99) suggests that technical communicators do not analyze their audience but provide information on a “the more information, the better” principle. This is probably true, but it is the result of the current work environment rather than an unwillingness to get to know the audience; if you include “everything,” there is less chance that something crucial is left out by accident.
Lee and Mehlenbacher (2000, p. 547) report that technical communicators see themselves as “information gatherers”: their work involves learning as much from the SMEs (subject matter experts) as they can. However, one of the technical communicators in their study stated that their role is to “get the facts and data I need to write useful information for the users of the software” (ibid.). Lee and Mehlenbacher do not mention which departments the SMEs belong to, but it is mentioned that the SMEs write code and create software (2000, p. 548). This product-centeredness mirrors the interview data in this paper: the people who design the product are used as an information source when writing for the users of the product. Is the typical software engineer really a user expert? They will be able to tell you how the product has changed and what the new features do, but will they know why these new features have been introduced and how the users are expecting them to work? Price and Korman (1993, p. 30) suggest trainers, marketing staff and troubleshooting engineers as useful people for finding out who your audience is. However, subcontracted technical communicators rarely have access to any other SMEs than the ones appointed by the customer—and usually, these are “R&D engineers” (according to Interviewee F, for example).
According to Spinuzzi (2000, p. 170), a documentation set has traditionally been seen as a closed, centrally designed system, intended as the only source of product information for users although Carroll and Van der Meij (1998, p. 80), for example, have also emphasized that documentation should be an “actively evolving solution rather than a relatively stable and contemporary documentation set.” In addition, usability has been seen as a feature of the documentation product: either in the product or not in it (Spinuzzi, 2000, p. 171). In the real world, of course, things are not this simple. As Spinuzzi (2000, p. 170) puts it:
In practice, then, the technology-in-use is not documented by a closed document set; it is documented by a perpetually open-ended, dynamic, shifting, and always unfinished ecology of resources encompassing a variety of media and domains. (Spinuzzi, 2000, p. 170.)
According to Spinuzzi (2000, p. 176), technical communicators should consider their documentation set as an open system, a genre ecology, while they “plan research studies; analyze data from the research of existing documents; and plan how to implement new forms of documentation.” Carroll and Van der Meij (1998, p. 59) also call for an iterative design process of user documentation, where “feedback from users and their work contexts pervades the process.” Perhaps this is further evidence of the gap between technical communication scholars and technical communication practitioners discussed by Blakeslee and Spilka (2004, p. 82—83), but according to the data of this study, the reality is that the current technical communication environment does not allow for any of that to take place. Spinuzzi goes on to suggest dynamic user profiling as a way to construct documentation:
With knowledge about the software and hardware that a user has available—as well as information about the habits and past computing experiences of the user—a skilled technical communicator would be able to design more appropriate documentation than typical user profiles allow. (Spinuzzi, 2000, p. 179)
It is unclear what types of products-to-be-documented Spinuzzi is referring to here, but for me, this type of approach is quite hypothetical: for example, in a radio station environment such as the one discussed above, there are various users per workstation which all have standard software and hardware. The users may log in as themselves or as generic users, depending on the task at hand. Even in a more traditional workstation setting, not all users are willing to share their computing habits for tailored documentation purposes. In addition, in today’s hectic, offshored and outsourced technical communication environment, there is not enough time or resources for traditional user profiling, let alone for creating single-user documentation on the go.
Spinuzzi (2000, p. 178) suggests “organic engineering” as a way to plan dynamic forms of documentation: the aim would be to identify spaces within a user’s activity where we could introduce documentation pertinent to that component of the activity. For example, to go back to the radio station example, we could offer simple, laminated instruction leaflets for the studio environment, and a more comprehensive set of instructions for the newsroom. What these instructions would contain would differ from radio station to radio station; the production environment of commercial broadcasters is quite different from that of public broadcasters. Naturally, not all radio stations have the same system setup or the same applications in use, and the work processes and job descriptions of their employees also vary. All of these aspects should be taken into consideration when planning documentation, and the resulting information set would then be applicable in a specific radio station environment. Presumably, this type of tailored documentation would correspond better to the day-to-day tasks of the employees. However, as discussed above, the technical communicator would need extensive knowledge of the radio station and the way it operates to produce tailored documentation. According to Spinuzzi (1999, p. 21), this approach would “decenter” the technical communicator, transforming him/her into a collaborator of the user in the user’s work tasks. In my opinion, however, the technical communicator is very rarely in the center: documentation revolves around the product and its SMEs. The typing up of the information may seem as a central task, but it is not—it is often merely secretarial (compare to Slattery, 2007, p. 315). According to Slattery, “We face problems being experts, not in what information should be organized and how, but only in the process of bringing it together” (2007, p. 323).
In addition, when a new system is being introduced, the users of the existing system may not be entirely thrilled about the disruptions to their familiar routines. When visiting a radio station to discover their current work processes, the question I most got asked was whether I could “promise that nothing will change.” I suggested that change was precisely the reason they were upgrading to a digital system: certain tasks would become much easier than they had been in the past. The employees were not convinced. According to them, things were just fine as they were, and they also felt that whenever “the boss” introduced a streamlined work process, someone would get fired as a result. In a situation like this, it may be quite difficult to discover which spaces—or “ecological niches” (Spinuzzi, 2000, p. 178)—require tailored documentation. A traditional document set, at any rate, will not provide the needed information, which is why a lot of customers tailor it themselves to fit their specific needs. Is this the type of technical communication we should be offering? According to the interview data, our current work environments certainly do not encourage us to proceed in this direction. Subcontracted and offshored documentation teams especially have no access to the users or user data on the documents they produce—essential for producing tailored documentation.
Outsourcing and Offshoring
Outsourcing and offshoring are some of the current buzzwords of the technical communication industry. Along with other non-crucial IT sector tasks, technical communication was first outsourced and then offshored in the interest of cost-savings. Outsourcing, or subcontracted technical communication, was originally seen as a positive phenomenon in the field: the idea was that the subcontractors, being experts of the area, would offer services ranging from planning and quality improvement projects to day-to-day writing tasks. In reality, however, customers were often reluctant to pay for anything other than basic updates, and the technical writers were reduced to typing up information provided to them by the SMEs. Interviewee B had experience of being both an in-house and a subcontracted technical communicator, and found that being a subcontractor makes it difficult to have access to the necessary information and is also limiting in other ways:
Interviewee B: As a subcontractor, you are so far from the product that it is difficult to do high-quality work; the deadlines are impossible, and the customers are not willing to pay for development work. You are not allowed to do anything outside of what’s agreed in the contract. You get no feedback or input from the SMEs and have no access to the databases. When you are in-house, you are more invested in the quality and the end result, as it is your own company and products. You have more influence and possibilities for development. I was once involved in an outsourcing project where the subcontractor did a study on the problems that had occurred during the project, but nothing was done although the problems directly affected the user documentation of the customer company.
It would seem that in the case of subcontracted technical communication, the additional divide between the supplier and the customer company does little to enhance the quality of the documentation produced. Slattery (2007, p. 314) discovered similar issues in his study of subcontracted technical writing: the writers had little subject matter expertise and were not on the same site as the SMEs who provided the necessary information. According to Slattery (2007, p. 315), this type of documentation is assembled rather than written, and the writers are removed from the product development process both physically and institutionally. He goes on to point out that subcontracted technical communicators are facing the risk of their expertise being reduced entirely to the assembly of documentation (Slattery, 2007, p. 323).
There are various subcontractors in the field, each with their own company style. Interviewee A had worked for multiple subcontractors and discovered that there are major differences in the way the companies operate: in one company, there were problems in routine issues, such as getting the correct pay, while in another company, the employees had real influence in the way the work was conducted:
Interviewee A: There are big differences between different subcontractors: in one, we [the employees] had to constantly worry about basic contract-related issues, such as getting the correct pay. The company had an extra layer of middle management, which made the organization quite heavy. In another subcontractor company, the middle managers were let go instead of the employees, which resulted in, for example, better pay for us [the employees]. We were able to have a say in contract negotiations with customers, which resulted in more realistic projects. It is quite often the case that the sales people conducting the negotiations know nothing about actual technical writing, causing really bad contracts.
The divide between the sales people and the people doing the actual technical communication work seems to be quite a common source of problems. Interviewee E also had bad experiences of unrealistic contract negotiations—it seems that the sales personnel sometimes concentrate on getting the new client, regardless of the scope of the project:
Interviewee E: The sales people promise the earth in the negotiations, without really knowing what they are promising. We [documentation project managers] are not consulted in time, and we are not allowed to ask too many questions—they just want the new customer, whatever it takes.
Giammona (2011, p. 60) points out that outsourcing can be helpful if it is used as a way to support the existing staff, but that the use of unqualified resources—often the case in offshoring projects—can endanger the work done by technical communicators as a whole. According to Giammona (2011, p. 64) offshoring also means that the technical communicators in higher-cost countries need to develop project management and editorial skills. I slightly disagree—what would be the reason for companies to keep project management and editorial work in higher-cost countries when the rest of the tasks associated with technical communication are moved to lower-cost countries? Project management and editorial skills are quite generic and do not require high-level specialist knowledge of the product, the documentation system, the user or the customer. As an in-house technical communicator put it:
Interviewee B: Now that I’m a customer documentation project manager, I have no knowledge of the contents of the documents or the tools that are used in the documentation process. The product department “owns” the documentation, we just deliver it. It is not a specialist task, it is a delivery task.
Do we really need all these layers of management in order to create technical communication products? In a single, outsourced technical writing project, we may have a full management structure on the customer’s side as well as the subcontractor’s side, with the SMEs from R&D and product management all pitching in. This type of multi-layered organizational structure is quite costly and rigid, further reducing the technical communicator’s chances of independent decision-making.
Future Visions
In the previous sections of this article, I have discussed some of the main issues that the interviewees feel are currently shaping our field. I also asked the interviewees to comment on the future of technical communication as they see it. Most of them were quite skeptical; the IT sector is going through a major restructuring in Finland at the moment, which clearly shows in the field of technical communication, too. Many major employers are going through a rough patch, and the vendor companies, that traditionally have been able to bring new people into the field, are also struggling. There were two trends that showed in the interviews: the shift toward technical communicators with an engineering background, and the shift toward crowd-sourcing and collaborative writing:
Interviewee B: This is a dying industry; it is going through a major transformation. In the future, there will be no Arts majors as technical communicators, the work will be done by multi-skilled engineers instead. Collaborative writing will be the norm, customers will give direct feedback and the documentation will be updated as a collaborative project. My own future is open. I don’t think this is a job I’ll be able to retire from.
In addition to the shift from technical communicators with an Arts background to those with an engineering background, the cost of technical communication continues to be an issue. According to Interviewee A (a subcontractor), price seems to be the deciding factor, and he also mentioned crowd-sourcing as a way to cut costs even further:
Interviewee A: Quality doesn’t matter anymore; it’s all about the price. Customers don’t want the best, they want the cheapest. Technical writing has already been moved to low-cost countries. The next trend will probably be crowd-sourcing… what could be cheaper than that?
Interviewee D (in-house) had similar thoughts about the price of technical communication, and she also felt that the current work environment is quite demotivating: your own contribution does not matter when cost-cutting is the aim of the company.
Interviewee D: China and India are starting to be “expensive,” what next? The work has gone so insane that it is just basic survival now. I no longer put in extra hours because it’s no use, you can’t control chaos. Quality doesn’t mean anything—no matter how well you do your own work, you can still get fired just like that. Do they pull the names out of a hat or something?
Interviewee C also mentioned crowd-sourcing as a future trend for consumer products and compared technical communication to the subtitling business. In Finland, television programs and movies are subtitled rather than dubbed, and many major broadcasting companies have recently begun using vendors instead of their own employees for audiovisual translation. The vendor companies, in turn, often use freelance translators.
Interviewee C: The whole profession will be wiped out [in Finland], or it will become freelancer-based like the AV translation business. I think consumer product documentation will become crowd-sourced.
As outsourcing and offshoring have become more commonplace, fear for the future of the field in Finland (or any “higher-cost country,” for that matter) has also increased. I actually borrowed the rather provocative title of this article from an interviewee, who thinks that the future of technical communication is rather different from the present—a cross between crowd-sourcing and co-authoring:
Interviewee G: I don’t know, maybe it [the future] is the death of the technical communicator? A slow, withering death. I think user manuals will all eventually be online, where everyone can comment on them—that would be a good way to get direct feedback. Someone will, however, still have to write the first version that will then get torn to pieces in the social media.
In her vision, the technical communicator—or “someone”—will write the first version of a user guide, which will then be collaboratively updated. This is not exactly the type of co-authoring suggested by Spinuzzi as discussed above, but it does offer the technical communicator a direct channel for user feedback—something that is often lacking in our current work environments.
However, while certain consumer products may be open to crowd-sourced documentation, some products are so technically challenging that it is difficult to find a single SME to approve the documents for publication, let alone find a technical communicator capable of writing them. One interviewee had found herself in quite an impossible situation because of this:
Interviewee C: So we have the SME team who understands the product, and we have a customer representative who understands the product, and then we have a “stupid” Arts major in between trying to provide the product information.
In cases like these, the main responsibility for the document contents is left to the SMEs, emphasizing the general feeling that technical communicators are not doing their work. Interviewee C wanted to emphasize that she does not think she is “stupid”; it is the community around her that perceives the situation like this because of the impossibility of her task. As Barefoot (interviewed and quoted by Giammona, 2011, p. 65) puts it: “The days of the Arts major going into technical writing are numbered.” For the more technical products, this may indeed be the case.
The general feeling in the field is that being a subcontractor is generally more difficult than being an in-house technical communicator (compare to Virtaluoto, 2013). However, the only interviewee in this study who was basically happy with her work was a subcontractor. She felt that her expertise was valued both by her own company and the customers, and she also had direct influence over project deadlines:
Interviewee F: I’m very, very good at my job, and my boss knows it. She’ll ask me how long a job would take, I say three weeks, she puts three weeks in the contract and that’s it. I do the work in three weeks and everyone is happy. My boss knows she can throw any type of product in front of me, and I’ll find out how it works. As a subcontractor, I can offer an outsider look, a new perspective on the project to be documented. I get to use my expertise, and the customers are starting to ask for my help.
She was also the only one whose future visions were to do with the tools of the trade, rather than the future existence of the trade: she mentioned STI (Simplified Technical English) as a useful way to standardize a company’s technical communication products and cut down on the routine tasks associated with the field.
Conclusion
The aim of this paper was to discuss the current state and future of technical communication in Finland as the interviewees see it. The interview data was combined with my own experiences and the literature of the field to come to a more in-depth understanding of the issues we are facing. The field of technical communication seems to be going through a major transformation phase in Finland, and this transformation is coinciding with the worldwide economic slump and the restructuring of many Finnish export businesses. These things combined make this a very difficult time for the field, which is obviously reflected in the interviews. I would have liked to provide a more positive view of the future of our field in this paper—for myself as much as for the readers—but unfortunately the data did not allow me to do so. However, as this is an autoethnographic paper, it is necessary for me to also consider my own impact on the results; did I put enough emphasis on reporting what was being said by the interviewees, rather than my subjective interpretation of it? As a CMR, was I able to detach myself enough to be unbiased? My ultimate aim was to give the interviewees a chance to speak their mind, and I hope I succeeded.
So, is the technical communicator really the Willy Loman of the IT industry, with big dreams that never amounted to much? At least some of our skills seem to be no longer needed by the corporate world; our attempts at becoming “boundary spanners” or “strategic negotiators” (Hart & Conklin, 2011, pp. 140—141) have not yet materialized. In addition, while our single-sourcing environments offer us clear synergy benefits, they are often quite heavy to operate, resulting in more time spent fiddling with the system and less on actual technical communication. As Slattery (2007, p. 318) puts it, “there is the very real concern that the difficulty of these technologies and environments might relegate technical writing to a technological skill.” He goes on to point out that once structured authoring systems undergo the same usability evolution as desktop publishing, these types of tasks may become automated (ibid.); if that does indeed happen, what is the added value that technical communicators bring to the table? Are we the modern-day typing pool, soon to become obsolete?
As discussed above, we are supposed to be the user’s advocate, but have no access to users; often, we are as physically removed from the company creating the product as we are from the customers who use it. According to Spinuzzi (2000, p. 174), in the traditional, closed-set documentation genre, “writers design a manual to inform the user.” In my opinion, we are not even there yet—on the basis of the data in this paper, “writers update information to correspond with new product design.” The starting point is the product and its new or changed features, not the user. The writing process involves updating, augmenting and copy-pasting information from a variety of sources, rather than designing a manual as a coherent whole. Slattery (2007, p. 315) calls this type of documentation “not so much written as assembled—a pastiche of contributions from multiple individuals.” The writer is a master of the documentation system, not of the product or the user. This type of work is mechanical and repetitive, making it an easy candidate for outsourcing and offshoring. In 2005, Hackos (p. 275—276) argued that customer knowledge is critical to our work and also difficult for “low cost innovators to emulate”—in other words, something that is difficult to offshore. In my opinion, this is still true today, and it is where we should be heading as a profession. On the basis of the interview data, however, it is difficult to see any clear signs of the field actually progressing in this direction. It is also difficult to say what the future of the field will be in Finland, but generally speaking, it is likely that there will be different types of technical communication for different products: for example, crowd-sourced or co-authored documentation for consumer products and SME-driven documentation for technically challenging business products. This development requires us to expand our horizons beyond traditional technical writing tasks (compare to Spinuzzi, 2007, p. 273).
While the picture painted in this paper is quite bleak, the interview data has illustrated the complexity of the issues we are facing. In this complexity lies the seed of something new, a future. In the next stage of this research, I will apply the tools offered by activity theory and developmental work research (Engeström, 1995; Nardi, 1996) to the interview data to explore the possibility of discovering a more sustainable model for technical communication.
References
Anderson, L. (2006). Analytic autoethnography. Journal of Contemporary Ethnography, 35, 373-392.
Anson, P. A. H. (1998). Exploring minimalistic technical documentation design today: A view from the practitioner’s window. In J. M. Carroll (Ed.), Minimalism beyond the Nurnberg Funnel (pp. 91-115). Cambridge, MA: The MIT Press.
Blakeslee, A. M., & R. Spilka.(2004). The state of research in technical communication. Technical Communication Quarterly, 13(1), 73-92.
Brockmann, R. J. (1986). Writing better computer user documentation. From paper to online. New York, NY: John Wiley & Sons.
Carroll, J. M. (Ed.). (1998). Minimalism beyond the Nurnberg funnel. Boston, MA: MIT Press.
Carroll, J. M., & Van der Meij, H. (1998). Ten misconceptions about minimalism. In J. M. Carroll (Ed.), Minimalism beyond the Nurnberg Funnel (pp. 55-90). Cambridge, MA: The MIT Press.
Conklin, J., & Hayhoe, G. F. (Eds.). (2011). Qualitative research in technical communication. New York, NY: Routledge.
Di Cicco-Bloom, B., & Crabtree, B.F. (2006). The qualitative research interview. Medical Education, 40, 314—321.
Engeström, Y. (1995). Kehittävä työntutkimus. Perusteita, tuloksia ja haasteita [Developmental work research: Foundations, results and challenges.] Helsinki: Hallinnon Kehittämiskeskus.
Giammona, B. A. (2011). The future of technical communication: How innovation, technology, information management, and other forces are shaping the future of the profession. In J. Conklin & G. F. Hayhoe (Eds.), Qualitative research in technical communication (pp. 49-81). New York, NY: Routledge.
Hackos, J. T. (2005). The future of the technical communication profession: The perspective of a management consultant. Technical Communication, 52, 273-276.
Hart, H., & Conklin, J. (2011). Toward a meaningful model of technical communication. In J. Conklin & G. F. Hayhoe (Eds.), Qualitative research in technical communication (pp. 112-142). New York, NY: Routledge.
Hayhoe, G. F. (2005). The future of technical communication. Technical Communication, 52, 265-266.
Lee, M. F. & Mehlenbacher, B. (2000). Technical writer/subject-matter expert interaction: the writer’s perspective, the organizational challenge. Technical Communication, 47, 544—553.
Nardi, B. A. (Ed.). (1996). Context and consciousness: Activity theory and human computer interaction. Cambridge, MA: MIT Press.
Price, J., & Korman, H. (1993). How to communicate technical information. A handbook of software and hardware documentation. Boston, MA: Addison-Wesley.
Reed-Danahay, D. (Ed.). (1997). Auto/ethnography. Rewriting the self and the social. Oxford: Berg.
Schriver, K. A. (1997). Dynamics in document design. Creating texts for readers. New York, NY: John Wiley.
Slattery, S. (2007). Undistributing work through writing: How technical writers manage texts in complex information environments. Technical Communication Quarterly, 16, 311-325.
Spinuzzi, C. (1999). Grappling with distributed usability: A cultural-historical examination of documentation genres over four decades. SIGDOC ‘99: Proceedings of the 17th annual international conference on computer documentation, 16-21. New York, NY: ACM. Retrieved from: http://dl.acm.org/citation.fm?id=318372.318385&coll=DL&dl=A
CM&CFID=190572336&CFTOKEN=74839765.
Spinuzzi, C. (2000). Genre ecologies: An open-system 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.
Spinuzzi, C. (2007). Guest editor’s introduction: Technical communication in the age of distributed work. Technical Communication Quarterly, 16, 265-277.
Van der Geest, T. (1994). Hypertext: Writing and reading in a non-linear medium. In: M. Steehouder, C. Jansen, & P. van der Poort (Eds.), Quality of technical documentation (pp. 49-62). Amsterdam, The Netherlands: Rodopi.
Van Laan, K. & Julian, C. (2001). The complete idiot’s guide to technical writing. Indianapolis, IN: Alpha Books.
Virtaluoto, J. (2013). “It’s a strange little business”—Issues in technical communication. AFinLA-e: Soveltavan kielitieteen tutkimuksia, 5, 200-213. Retrieved from: http://ojs.tsv.fi/index.php/afinla/article/view/8747.
About the Author
Jenni Virtaluoto is a seasoned technical communicator, currently doing PhD studies in English Philology at the University of Oulu, Finland. She has been involved in challenging, international customer projects as a technical writer, consultant and customer trainer, with experience in many areas of customer-facing technical communication: from press releases to training materials, marketing materials and user guides. She is a Board member of the Finnish Technical Communications Society and can be contacted at jenni.virtaluoto@oulu.fi.
Manuscript received 20 August 2013; revised 24 January 2014; accepted 25 January 2014.
