Author Archives: season1980
I think that I am getting the hang of this “rhetoric of technology” now since Clark simplified it to “technology and rhetoric are…co-bedded in culture,” and that for technology to be a “real cultural phenomenon,” people have to start bickering over it (Clark, 2010, p. 85). Additionally, it has been drilled into me that all these technology analyzing tools are based on society and culture and its users, which in combination also plays a part in the workplace. I will be discussing my role as a contractor in the workplace with this cultural theory in mind.
According to Clark, who invokes Johnson to confirm that
[T]echnological design and implementation that places users, rather than systems, at the center of our focus, and that we have an ethical and cultural responsibility to learn and argue to collaborative approaches… (Clark, 2010, p. 93).
For my last assignment, we did just that. We had our users in mind – new people who had no training, and who were from another country – when we were told to update our content managing system (CMS) to be more user friendly, go through all documentation to either update or delete them, and to create new documentation if the documentation did not exist. The CMS was cleaned up, updated to have visuals such as icons and graphics, and had proper meta tags added each document to make them easier to find in searches.
While this fury of work was being done, we joked about how we are providing so much helpful documentation that we would all be out of a job. And we were. Once everything had been completed and tested over a month in another country, all of us contractors were given notice that all of our jobs were now going overseas, and that those people overseas would be actual, hired employees. But everyone here had a job to do, even though we knew we were putting ourselves out of a job. Thus, when Hart-Davidson wrote, “[T]he combined threat that many technical communicators have confronted firsthand: outsourcing and work fragmentation,” I could only nod in agreement and wonder what I have gotten myself into, again (2010, p. 141).
To make matters worse, when Hart-Davidson goes on to say that “users providing their own help content…actually present dramatic new roles for technical communicators to play,” I wanted to throw this book because he never explains which new roles that these were going to be (2010, p. 141). I do not want generics, I want real answers. Maybe being a consultant or contractor is a dream job for many, but when you have a family to take care of, bills to pay, and you are the nearly the sole wage earner, hearing that you only get so much time at a job is scary. In my opinion, it is sad that companies seem to only care about the bottom line and their customers, but not their employees. Employees used to be the ones valued, and their worth was rewarded with stock options, PTO, health benefits, etc. No more. The companies’ real value is information, which Hart-Davidson writes is the true “valuable commodity” (2010, p. 128).
Now, at another assignment, which I already know the exact date when to start packing up my stuff, I have tried to get them to be more efficient with their workflow, work instructions, and etc. But just as culture and society have certain conventions, rules, and guidelines, so does this workplace too. I have already been told that once a decision on how the templates were made, no further changes will ever be made. I understand that with global companies, they have to think globally, and when there is a change to the standard, then that change needs to be reflected in every document, which costs money. But working with these old templates creates extra work, as some things are duplicated, and there are fields on there that no longer apply, in my opinion. I believe that these templates could be edited for efficiency, remove confusion for the user, and look more professional, but the “power relationship encoded” in this template has limited what I can do with it (Salvo & Rosinski, 2010, p. 103).
Additionally, there is an issue of storing these documents and templates. It has been repeated throughout this course so far that there is a need for companies to store their information for others to find it. I brought this issue up in two meetings at work, with the reply of being that they know it is a problem, but it is not important enough to deal with. I would have to disagree. Even Salvo and Rosinki remark that “information that cannot be easily retrieved when needed is useless” (2010, p. 103). And if information is a “valuable commodity,” as already referenced above, then there is a problem that needs to be resolved sooner, rather than later (Hart-Davidson, 2010, p. 128).
In the end, while I learned that technology is based in culture and society, there are limits, rules, and guidelines that I have to play by. Some companies may be open for change; for others, they are more ridged due to political concerns. Many contractors understand that have an ethical and cultural responsibility to their client, even if it is to their detriment. While some scholars are hopeful that there will be plenty of jobs for technical communicators, some are not, and this theme continues to be weaved in and out of texts, which makes me hope that when I am on my deathbed, I can look back and know that I made the correct choice. Otherwise, dang it.
Clark, D. (2010). Shaped and Shaping Tools In R. Spilka (Ed.), Digital Literacy For Technical Communication (p. 93). New York, NY: Routledge.
Hart-Davidson, W. (2010). Introduction In R. Spilka (Ed.), Digital Literacy For Technical Communication (p. 93). New York, NY: Routledge.
Salvo, M.J. & Rosinski, P. (2010). Introduction In R. Spilka (Ed.), Digital Literacy For Technical Communication (p. 93). New York, NY: Routledge.
While Spilka and her contributors for Digital Literary for Technical Communication drove me crazy by repetition large chucks of text ( see pages 11, 13, 16 regarding who the target audience for her book is) and having a chapter summarizing all the other chapters, there are a couple of things that I learned, besides understanding that if I have to read any more of this book, I will either need a couple of aspirins or a bottle of vodka. These two things that I found most important were evolving and that technical writers must play well with others.
Yes, everyone should already know that technology is constantly evolving, and so its delivery methods and how technical communicators craft their messages need to evolve too. Without evolving, technical writers will fail to gain all the skills necessary for the latest publishing tools, such as FrameMaker and RoboHelp, to help their users and to continue building a positive reputation for whatever company is providing the products and resources. An example of this need for evolving ones skills is in the chapter titled, “The Effects of Digital Literacy on the Nature of Technical Communication Work,” Dicks writes,
The nature of work for many technical communicators is changing so
rapidly that many now perform an entire task set that they did not even
know about five years ago (p. 51).
But evolving to keep up with the changing technology should be common sense, and Saul Carliner provides a chapter on history (just to show how fast technology has changed when companies, seeking higher profits use user input to create the desires of the customer – custom corporate software, better online help, easier desktop publishing, etc. By evolving, companies and people have saved money and time, which is usually one of the main goals of nearly everyone. And as for me, my goals are to learn FrameMaker, RoboHelp, and Illustrator, because I missed out on getting my resume read by hiring managers in the technical communications field because I did not have experience in those tools. I, too, must evolve.
Must play well with others.
Life would be great if everyone played nice and worked well together, and working well with others is an important soft skill that many people lack, especially for those technical communicators who have been working alone for so long. But in today’s technical communicators’ work places, it is necessary to work with others to gather information and for review. As Spilka states,
[W]hat seems most critical and meaningful is how we can contribute to
social, team, or collaborative efforts toward the greater good of large
scale projects…Our work is also more like than before to be
international scope (p. 5).
Thus, to be a desirable technical communicator, one of the main skills is knowing how to work in a team. By helping co-workers in a timely manner, work can be fun, enjoyable, and a success. As a valued part of the team, the technical writer may learn additional skills and be wanted for further projects, which new skills may be needed, so it would be a great opportunity to evolve again. That is why I would suggest to anyone in this field to always take a chance to learn something new. Take on a more challenging project to increase your knowledge and skills.
All in all, so far, I learned from this book that one must not be afraid of the latest technologies, and they should evolve by trying to learn how the latest technologies can benefit themselves and their work places. Besides learning the forever-changing technology tools, methods, theories, and etc., it is also important to know how to work with others, as most projects will involve many people who will be working on the same project, and the technical communicator will need to gather information, and give and receive feedback on the project, so that the project is a success. And if the project turns out not to be successful, have a drink, think about what could have been done to have made it successful, and then try it again next time. With that, you are evolving. Start your evolution now.
Dicks, R. (2010). The Effects of Digital Literacy on the Nature of Technical Communication Work In R. Spilka (Ed.), Digital Literacy For Technical Communication (p. 51). New York, NY: Routledge.
Carliner, S. (2010). Computers and Technical Communication (Ed.), Digital Literacy For Technical Communication (p. 5). New York, NY: Routledge.
Spilka, R. (2010). Introduction In R. Spilka (Ed.), Digital Literacy For Technical Communication (p. 5). New York, NY: Routledge.