Discourse, Agency, and Writing Outside the University
Roger Graves, Department of English, DePaul University, Chicago
Email from a student after completing the winter 2000 undergraduate Technical Writing course:
[the] Second reason I am writing this e-mail is to THANK YOU for teaching this class. Everything we had in this class from document design, memos, and all those in class assignments helped me to do my job successfully now. I was hired as IT and promoted to People Soft developer where presentations, document design, creating set of instructions for end users are required. My boss and some other managers, including end users love it because is organized, readable, my points are on the place, plus I use pictures. They love it. I just want to thank you for it. Thank you
One school of thought -- articulated in Worlds Apart by Patrick Dias, Aviva Freedman, Peter Medway and Anthony Paré -- has it that workplace writing is so distinct in its context, its attenuation of learning tasks, its collaboration, its ownership of text, and its goals from academic writing assignments that only a general rhetorical awareness and general rhetorical strategies can be usefully taught in the academic classroom (pp. 185-200). However one might want to quibble with this conclusion, it seems a reasonable enough one if you accept certain premises: that most academic assignments in a professional writing course -- and the "report writing" genre springs to mind here along with any set of memo or letter writing exercises -- are sorely lacking a meaningful context for student writing. That is, if the reader for the writing is, for all intents and purposes, the instructor, then this kind of writing activity has little potential for transferring learning from the academic context to the workplace one. I think that, if you assume this as the paradigm for instruction in professional writing (and there is some reason to believe that is a reasonable assumption), this view accounts for the middling (or worse) success of traditional, textbook-based undergraduate instruction in professional writing. This does not mean, however, that there is no point in teaching professional writing courses at a university or that we should accept the learning conditions we are handed. In fact, we can change these learning conditions if we pay attention to useful criteria that Dias et al have identified: collaboration models, attenuation of learning tasks, goals for learning, and models of student participation.
My recent experiences suggest two circumstances where professional writing can be gainfully taught. I want to re-examine, first, a "faculty internship" experience I had recently in light of the issue of "context." What did I know about the context of my writing at this company before I went to work there? What context for this writing did I build in the five weeks I spent on site? How could I create or re-create a similarly meaningful context for my graduate students who were learning to write these kinds of documents? I will argue that both this course and student internships provide models of how academic study can be mingled with workplace contexts to provide meaningful learning experiences, especially for students of professional writing.
A second curricular innovation I have been working with for the past three years also challenges the conclusion that professional writing cannot be taught in a meaningful way in an academic setting. I teach a "service learning" course that directs students to write grants for a social service agency. To complete this assignment, students must "learn the agency:" travel to the agency several times, meet with the agency director several times, interact with the clients the agency serves, research possible foundations the agency could apply to for money, write about the agency and the project they need funding to initiate. All of these activities -- reading, writing, interviewing, researching -- build the context traditionally associated with workplace writing. All of these activities take place in the shared context of our weekly class meetings at the university and our trips around the city. These learning experiences introduce students to environments where collaboration counts, tasks are not attenuated, the goals for learning are to produce usable documents, and student participation moves quickly from attenuated authentic participation to legitimate peripheral participation.
Workplace/Academic Writing: My experience
I spent a little over one month working at the Chicago Interface Group, a software firm located at 368 West Huron Street in the River North area of Chicago (www.cig.net). In that time I was able to write or co-author three manuals, contribute to planning meetings, and even help with product development in a minor way. In many ways this work reinforced the ideas I already had about teaching technical writing: the kinds of things I already teach are the right things to be teaching. That is, there is a rough match between what goes on in my technical writing classes and the kinds of documents and methods of work that I encountered at this work site.
Entering a Community of Practice (COP): Details of my Internship
While working as a technical writer, I employed ethnographic research techniques to gather data: notes, interviews, and drafts of documents. I focused my research on these issues:
What kinds of writing projects do working professional writers work on?
I found that the people at this small company work on a broad variety of documents:
The manuals that enable purchasers to install the product are extremely important, as are the manuals used to teach the employees of these companies how to use the products. Without these documents, CIG's products do not get used and the licenses to use them are not renewed. Sales of new product licenses depend to a great degree on past product performance; that is, if companies liked the last product CIG produced, they are very likely to buy the next one. To sell new products, CIG relies on mailers and direct marketing to people who use mainframe computer systems. They also rely on white papers (case studies) and functional overviews to support sales people when they present the products to customers. I think two things are important here: first, the written documents are part of the product (without them, there is no viable or usable product); and second, written documents support marketing efforts in critical ways (without marketing documents, sales slow).
What technology do they use to create their documents?
CIG uses the Microsoft Office suite of products on most workstations, but they also bought a special word processing product called Doc-to-Help. This program adds sub menus to the regular MS Word menus, so that when you click on "Edit" from the top menu bar you would see an elongated drop-down list of choices. Many of these choices make it easier to create manuals by automating the formatting of the document. Headers appear in a set size, typeface, and place on the page, and all text and sub-heads are automatically indented.
Doc-to-Help produces print, online, and web-based documents from the same original files. The technical writer at CIG told me that they chose Doc-to-Help specifically because it produced print output. The users of CIG products were, for the most part, still print-based; they did not use the internet extensively, although that was changing. These users demanded print documents for the manuals; the sales people also needed print documents to leave behind after sales calls and to mail to prospective customers. The support people at CIG, however, did post FAQs (Frequently Asked Questions) to the web site, and they were in the process of moving more of the troubleshooting advice/documentation to the web site. They would also make PDF formats of the manuals available for clients to download. They used a variety of software packages (it differed from person to person) including Microsoft FrontPage to create these documents.
How do they use the technology to create documents?
Because the company creates and sells computer software, everyone in the firm works with a computer on their desk and internet access. I did not see a hand-written document or draft of a document the entire time I was there. During planning meeting we used white-boards to visualize processes and outlines of activities. These whiteboards often remained up for weeks; some of them appeared to have been up for months. They were handwritten, but that was about it.
The word-processed word, then, dominated. Once a document file had been created during the drafting process, it was available to anyone on the network. I could open a document on the technical writer's computer, for example, and then save it to mine or change it and save it back to that other computer. Sometimes documents were sent as email attachments to others to review.
Handwritten whiteboards provided the means for sharing ideas in group meetings. Word-processed agendas for meetings and draft documents of all kinds were shared through the computer network. Draft documents were also printed out for review and testing. In short, a person who could not use computer technology would not be able to contribute to the success of CIG. Furthermore, everyone was expected to use both their own and company time to add to their computer skills. The environment demanded continued learning and quick learning in a computer environment.
How much testing do they do of their documents?
Key documents were tested extensively. The installation manual I helped write and edit was originally drafted by one of the co-owners of the business, a mainframe computer programmer. This document was given to the three people working on documentation/support for this new product: the technical writer, the web support person, and me. The technical writer and I each reviewed the draft separately and then met to compare changes. These changes were what I think of as editorial: steps were left out or not numbered, formatting for the same kind of information would vary, that kind of thing. After comparing our responses and compiling them into one document, the technical writer met with the programmer who drafted the installation guide. We then revised the document based on our suggestions and comments from the programmer.
We then tested this draft (draft 2) by asking another computer programmer to use it to install the software product onto a mainframe computer. I conducted this user test on April 18. It lasted from 9:30 am until 4:00 pm; the subject was not able to install the program, even after all this time had passed. It took almost 2 hours to complete Step 1, a process that in the final test took 20 minutes. Ultimately, we were able to revise the manual so that in the final test the total elapsed time was 2 hours.
Within one work week we created 8 different versions of this manual. The final version shipped with the "beta" version of the software product. This amount of revision, and the collapsed time frame we did it in, is exceptional and not documented in the research literature of professional writing.
How do they build cognitive models or conceptions of their audiences and the purposes for which they read?
This is hard to uncover. Some of this conception of audience is clearly internal: the programmer who wrote the installation guide imagined an audience much like herself. For her, there was a logical way that she would go about installing a product. She had also worked with a great many other programmers, so this internal conception included that experience of listening, watching, and working with teams of programmers installing new products. She told us (April 11/2000 meeting) that these installers were "not web guys" but they did know Endevor (a mainframe software program). So some of her conception of audience was derived from social experience. She also tried to imagine how this audience would try to read -- what kinds of words and sentences and images would make sense to them. She tried to imagine metaphors that would communicate the concept of the new software program; at one point she kept mentioning that the actions of this program were like putting something into "cold storage" and then taking it out again.
One part of the new program offered an option for the user to add their picture to the computer so that other people could see that photograph when checking to see if a particular file had been checked out. The authors of the new program clearly thought this was a benefit, and they were conceptualizing a work place in which the users did not know each other personally but might be able to recognize each other's pictures. So they changed the new software with this kind of audience in mind. They applied this conceptualization of the audience to the manual as well. When planning the user manual, we began with typical user tasks and then structured the manual around these tasks. The second chapter, for example, was structured around a product's "life cycle," a metaphor that users were familiar with from Endevor and from mainframe computing.
How do they develop the content of their documents?
In the case of the installation manual, one of the two main software developers wrote the first draft of the manual. This draft itself was based on an installation manual written for a previous software product. That is, the structure of the installation manual, including the kinds of things written about and the way in which they were written, were guided in large measure by the previous document. What we have here is an evolving genre of document. The particular adaptations made in this genre at CIG were not limited to format, although format was important. As the document underwent usability testing by other programmers/installers, more information was added. Crucial steps were re-written to explain more clearly exactly how to follow the steps. Some steps were deleted because they were unnecessary, and other steps included information that simply was incorrect. The testing team added icons to identify where upper and lower case typed input became significant (in Unix environments) because we saw test subjects continually make errors at these places in the procedure. The content, then, became an amalgam of text and visuals created in the first draft and overwritten with text and visuals from the computer programmer who helped me test the manual.
The user guide was a different story. The technical support people (the technical writer, the web support person, and me) met with the other owner of the company, the person who worked on the source code for the product we were writing about. Together, we sketched out what should be in the manual and who should write which sections. Each of the support people was given a section to write. I was put in charge of assembling all the pieces and working them into a coherent whole. To write each section, we all opened up a copy of the product and "played" with it. We tried to break it: ask it to do things it couldn't do. For each function of the program we described the purpose of the function, how to activate this function, what each computer screen would look like, and what information users would need to fill in the boxes or fields of the screen. We included pictures of what users would see if they filled in the boxes correctly and what to do if things didn't work out. The content of this manual came largely from personal experience using the product ourselves. However, this was the first version of this document and unlike the installation manual, it would be used over and over (the installation manual is used once and set aside). It is likely that this document will be revised extensively after the company gathered feedback from actual users in the workplace and through training courses.
Transitions or Transmogrifications?
I'd like to consider four elements that Dias et al identify in Worlds Apart -- attenuation, collaboration, goals for writing, and kind of participation -- in the context of the internship situation described above. How did these variables affect the nature of my experience as an internship student?
Because of my status as a "professor" and former instructor for the technical writer in the company, I was not given "appropriate authentic attenuated tasks" (190). Instead, I was asked to collaborate on an installation guide and user guide without any sense that the tasks were attenuated. In some ways there was a real curiosity about what kind of a document I would produce since in some ways I was regarded as the "expert" who was slumming (a GenX term).
Dias et al overstate the differences when between the ways university classes and workplaces treat collaboration when they claim that "In the end, all university students are graded individually, even when they collaborate on specific assignments" (198). In my classes this simply isn't true. When students work collaboratively on assignments they all get the same grade and the same comments. In my work during the internship the installation guide drew efforts from at least five different individuals at different times and in different roles. This common activity parallels what Dias et al lead us to expect. In my classes, I use policies like the following one to encourage a similar collaboration environment:
Students are encouraged to work in groups of not more than three. Groups will be treated in the same manner as individuals: projects that are group written do not have to be longer than projects written by individuals. Each member of a group will be assigned the same mark for group assignments.
The goals for writing at the worksite were similar to what Dias et al call action and policy oriented (189). That is, the writing had a material product as its end result rather than operating as an evaluation of whether or not I had learned how to produce such a document.
In many ways my participation can best be described as "autonomous professional practice" (Dias et al 188) because I operated and was treated more like a consultant than a neophyte. Consequently, I did not experience the kind of guided and attenuated assignments that Dias et al describe in their research.
Case 2: Student as Autonomous Professional
In addition to my own experience of working as a full member of a Community of Practice (COP) [Dias et al's term for social groups in a workplace setting who share a discourse], I have witnessed a similar experience in several students in my service learning course on grant writing (http://condor.depaul.edu/~rgraves/377home.htm). I want to detail the experience of one student, Alissa Hull. Her experiences in the course seem to violate the easy separation of academy and workplace that Dias et al rely on in their conclusions about the nature of the writing done by students who participate in multiple COPs or what might also be called discourses (see Chaden et al). Ultimately, I want to argue not that Dias et al are wrong or incorrect in their characterization of what they found during the course of their research. Rather, I want to point to other data and suggest that there are other ways of constructing the student writing relationship that lead to an understanding of students working as full members of multiple discourse communities simultaneously. These other models may not be widespread, and certainly not in Canada (service learning does not seem to have made inroads in writing pedagogy at Canadian universities as of 2003), but that should not preclude our consideration of these other practices as possibly superior and worth pursuing as we seek to close the gaps Dias et al identify in their work.
COP and Autonomous Professional Practice Take Over The Course
Researchers tend to assume that students are young and inexperienced, and that is the paradigm normally assumed. However, increasingly I have encountered students who are not traditional college age (they were over 25) and whose participation in a COP predates their enrollment in a course. As a consequence, these students interact with a course in a much different fashion, one not detailed in research literature. In the following two paragraphs I summarize the goals of the grant writing course as described to the students. Alissa took this course with me in the fall of 2001:
This is a service learning course that fulfills the experiential learning requirement for the liberal studies program. Because it is a service learning course, we will engage in two kinds of work:Alissa came to the course after having been part of the Young Women's Empowerment Project (YWEP) for 18 months. At the time of this writing (April 2002, eight months later), she continues to work with this group as she prepares to graduate. In her grant proposal, she says:
To learn to analyze the discourse of non-profit agencies and of funding sources we will read and study grant proposals that have been written for non-profits. I will lecture on the characteristics of this kind of discourse. This will involve a lot of traditional classroom work: going over the theories, applying them, writing analyses to see how well the concepts are understood. One analysis will focus on a document written by the agency you will be working with when you write the grant proposal; your analysis will be used to help the agency understand how they are representing themselves and to help you write a good proposal for them. So this aspect of the course, while theoretical and analytical, will provide the groundwork for writing the proposal.
- learning how to analyze language in the specific professional context of non-profit agencies
- writing grant proposals for agencies
The second aspect of the course is the service work (a total of about 25 hours, although some class time will be used to fulfill this requirement). The "service" that we will do in this course is writing grant proposals for agencies. To do this well, you should plan on spending at least 6 hours on the site of the service agency learning about their programs, talking to people who work there, and helping run the agency. You need this background so that you can write about what they do with conviction and specific detail. You should also budget 5 hours to spend at the Donor's Forum researching possible sources of grants (the foundations that give out money). Finally, expect to spend between 10 and 15 hours writing, revising, and presenting your work. You will present a draft of the proposal to the agency contact in the second last week of the course; the final proposal must be ready on the last day of class.
[The Young Women's Empowerment Group is] a collaborative effort by survivors of prostitution and their allies to seek social justice for girls and young women who trade sex or being sexual for money, gifts, drugs, or survival. Each participant in the project is recognized as being able to make decisions about one's own life while seeking opportunities for harm reduction. The Project focuses on the systemic conditions which create a population of women and girls to be used in prostitution and seeks ways to effectively influence youth in order to create changes in the sex industries.YWEP branched off from the original group, called the Advocates for Prostituted Women and Girls. Among other actions, this group protested the award of an honorary street named for Hugh Hefner (Playboy began in Chicago) by the Chicago City Council. YWEP began as a series of peer-based counseling, art expression, and information groups designed to provide skills such as how to survive on the street but also discussions about how issues such as racism, foster care, and economic inequality structured the lives of these women.
The grant that Alissa worked on focused specifically on obtaining money to run these workshops. In March of 2002, the YWEP was awarded $4,000 from the Crossroads Foundation as partial funding towards these workshops. In April of 2002, other potential funders were performing site visits, a second stage of investigating an organization and a good sign that further funding would be forthcoming.
In addition to writing a successful grant, Alissa took the textbook for the course, Grassroots Grants, and used it in the YWEP strategic planning mission session in October. Chapter Four begins by impressing upon the readers the need for establishing a "case statement;" Alissa took this planning process back to the YWEP and had them use it as part of their development process. The key thing here is that reading from the course was taken into the workplace COP and in fact created a practice within that group. So in a manner completely opposite to what Dias et al report, where the initiate must conform to the established practices of the workplace or community, here the student functioned as a full member of the group and not as peripheral or in an attenuated capacity -- as an autonomous professional.
Rethinking Workplace/Academy Metaphors
In the case of MA in Writing students, they are already established in COPs. In many cases these students come from or "originate" not in the school context but in a workplace context. When they come back to a school context, they are already experienced members of a COP and know its ways. They take night or weekend courses and then bring that knowledge back to the COP where they then use it to change the writing practices of that community. This model envisions a completely different kind of agency on the part of students. Rather than being neophytes, they are already established members of their communities. Rather than having to "learn new ways to learn new genres" they are already well versed in the model of life-long learning, as evidenced by their enrollment in a MA program. Rather than viewing school as a place to demonstrate their learning prowess, they bring an expectation that it should instead "relate" or extend somehow to professional practice in writing.
These MA students are not alone, however, in their approach to writing at work. As my students become less and less stereotypical college students and more and more part-time and returning students, the easy distinctions between workplace and academic writing practices blur. In Illinois, undergraduate students work an average of 30 hours per week; at my institution this number may in fact be somewhat low. Beyond the obvious problems this situation imposes on courseloads and reading, it is significant from a research point of view precisely because it implies that at least some of these students are already located in a COP and write within that context. When they write as students, they adapt or perhaps revert to school discourse as they read the classroom situation and teacher expectations. That is, they provide yet another example of individuals for whom the "transitions" metaphor simply doesn't fit. Instead, they are more appropriately seen as members of multiple discourse communities.
Beaufort, Anne. Writing in the Real World: Making the Transition from School to Work. New York: Teacher's College Press, 1999.
Dias, Patrick, Aviva Freedman, Peter Medway, and Anthony Paré. Worlds Apart: Acting and Writing in Academic and Workplace Contexts. Mahwah, NJ: Lawrence Erlbaum, 1999.
Dias, Patrick and Anthony Paré. Transitions: Writing in Academic and Workplace Settings. Cresskill, NJ: Hampton Press, 2000.
Graves, Roger. "Writing the Community, Writing the Classroom: Confronting Multiple Discourses in Service Learning Courses." With Caryn Chaden, David Jolliffe, and Peter Vandenberg. Reflections 11(Spring 2002): 19-39.
_____. "Meeting the Audience: Responses to Student Writing from Service Learning Clients." Business Communication Quarterly 64 (2001): 55-62.
Robinson, Andy. Grassroots Grants: An Activist's Guide to Proposal Writing. Oakland: Chardon Press, 1996.