Chapter 6: Moving from Academe to Industry

Thomas Barker, Texas Tech University

Introduction

Technical communication professionals, terms I use for persons who manage and author technical manuals and help for a living, often see themselves as boundary spanners in the organizations in which they work. And the nature of technical communication lends itself to this view. Technical writers deal with persons in different departments, getting technical information here, marketing information there, coordinating production with manufacturing departments. They also span the boundary between user and product, designing technical information in ways that allows the efficient and effective use. Finally, the span the conceptual boundary between the highly technical and the non-technical, translating from one discourse to another as part of their every day work. Technical writers get good at being effective in more than one world.

Technical communication educators share a similar view of themselves. While they work primarily in an academic setting, they associate frequently with technical communication professionals. They span the boundary between students and the students' future employment, between the principles of writing, document design, graphics design, and documentation management in the classroom and the practices of writing, designing, and management in the workplace.

In particular, teachers of specialized courses, such as software or hardware documentation in universities and colleges, find themselves confronted with a need to know the realities of the workplace. You have to keep up with tools and practices of tc professionals, you need to identify characteristics of successful technical communication professionals to aim for in teaching, you need to maintain employment contacts for students, and you need to meet the demands of employers with projects looking for employees or interns. You can't do this without amassing some body of knowledge and experience in workplace technical writing. This boundary spanning among technical writing teachers sets them apart from other academics in English departments and writing programs. When I look around the halls in the Department of English at Texas Tech University I see lots of people who don't have the opportunity to interact with business professionals, or who do, but in a different capacity.

But I do have the opportunity, and I'm the kind of person who likes to take advantage of opportunities, both to supplement my income and for the career growth and professional development--a concern for all technical writing teachers. The kind of work a technical writing teacher finds him or herself doing brings many opportunities to take on a project or spend some time doing professional technical communication work.

When I write of doing professional technical communication work, I mean independent work primarily, working as a consultant or independent contractor. I know of others who have not worked independently, choosing to work for a documentation company, like Judy Glick-Smith's Integrated Documentation, Inc.; a software company, like Lotus Development or Computer Associates; or a contract company or agency, like PTS Learning Systems or Berger, Inc. My experience, however, lies in doing individual projects infrequently for local companies in Lubbock, TX, and in striking out on my own as an independent contractor in Long Island, New York, which I did in 1995. I will mention these non-independent configurations in this chapter, but will focus primarily on the decision to do independent technical communication work.

This chapter discusses the issues surrounding the decision to go from technical communication educator to technical communication professional from the point of view of a person considering doing just that. First, I examine the reasons why a person would want to stretch a career to cover professional technical writing work, and the various kinds of jobs you can expect to do. I then examine the qualifications you will need to perform well in these kinds of jobs. I will then examine these qualifications more closely, in the context of the differences between the world of teaching and the world of practice in technical writing. This analysis will help us see and understand the kinds of obstacles that a teacher can expect when working as an independent, and understand ways to overcome them.

Reasons for Wanting to Work in Industry

As with any important career move, you want to approach it with a clear idea of your reasons. If you're currently teaching technical writing and want to gain workplace experience you will do it for a number of reasons. I discuss some of the more common ones below. Those reasons fall into two categories: those that allow for a partial involvement, doing occasional work or smaller projects while still teaching--moonlighting, in other words; and those that require a total immersion in the workplace--a new career.

Moonlighting

• You want to supplement your income. According to the STC 1996 Salary Survey, the mean salary for technical communication professionals is $43,782.00. We don't have a figure for the average salary of a technical communication educator, but I don't think it would vary that much. No, the incentive to do the occasional technical writing project to increase your monthly take-home pay really comes from the myth, or misconception, that technical writers make more per year than their university or college counterparts. We hear of writing for $65 per hour, or getting a thousand dollars a day as a consultant. These figures can entice a person to try this kind of work irregardless of the reality of the situation: that this money goes to well established companies or individuals with a vast skill set and strong reputation. The average technical writing instructor has little chance stepping into this kind of work like you would step out of a cab and into the lobby of a plush hotel. It's more like stepping off the sidewalk into the street...a busy street.

• You want to enhance your teaching. It makes sense that a tc educator would want to gain workplace experience to enhance teaching. How can you teach design principles, document formats, management practices, estimating techniques, review strategies and other such elements with just the benefit of a textbook. Tc educators need not only workplace experience, but they need a steady dose of it.

This rationale, for example, underlies the STC Faculty Internship Program. The designers of that program reason that partnerships between workplace professionals and academic professionals can strengthen technical communication education. Workplace projects can give the teacher a ready supply of "real" examples, and the discussion of them increases the students' respect for the teacher.

• You want to do research. Tc professionals in education need, often, to fulfill a research obligation to their institution. This research obligation usually requires funded research into workplace practices, design theory, or work in the many feeder disciplines to technical communication: end-user computing, cognitive psychology, human factors, linguistics, management, and the like. It takes the form of articles, books, chapters of books, conference presentations, and textbooks, all bearing the person's university or college affiliation.

The workplace offers many chances for productive research. I have done some such work among computer users at a national scientific lab, and I have surveyed, while I served on the Academe/Industry of the STC, our alumni for information about tools and kinds of work. Like any knowledge building activity, this kind of research helps define the profession of technical communication educator, and provides ample stimulus for taking on a project, surveying users, designing usability studies, and other research-related workplace activities.

The kinds of motivations I've discussed above allow you to work part-time as a technical communicator and retain your position at a university or college. You retain your health, retirement, and other insurance, and so does your family in most cases. You can add the work to your resume as consultant work, and list the company as one of your clients, but you can not use the writing you do for a company as a substitute for writing you do to fulfill your obligation to research.

For this kind of work I created a one-page "consultant's resume," containing a list of skills, previous clients, interests and other information that I could use to introduce myself to a potential client. From time to time a client would come to me. Once I had a visit from a baffled pair of administrators from the local municipal court needing to make sense out of their ticket processing system. Another time I discussed work with a colorful cowboy named Steve who pulled a laptop out of a saddlebag, plugged in a key, and demonstrated his rodeo software to me in my office. "Works for any timed, competitive event!"

For the next kind of work, you will have to change your entire career, leave academia behind and completely immerse yourself into workplace activities for an extended period.

New Career

• You want a career change. For some tc educators, the business world looks fast-paced and romantic. It's players come and go, make big bucks, buy bass boats, and always stay in nicer hotels at the conferences. They pay to put their employees through expensive training seminars costing a thousand a day. They fly you in helicopters and cater your lunch. (This actually happened to me once, while I served on a university committee for Digital Equipment Corporation.) This conception of workplace pizzazz lures graduate students into leaving their comfy academic classrooms and cubicles for industrial cubicles and work groups. Or they leave, thinking you can sit back in your remote office with the rocky mountains outside your picture window and your satellite dish connecting you to high-paying remote clients. You get a greater reward perhaps, because of the concreteness of the challenges, the late-night, coffee-fueled deadlines, the triumphant product roll out. You have a proximity to much better technology, and if you really enjoy technology, you have much better toys to play with at IBM than you do at a local community college.

• You want to accompany a family member to another location. More often than not your motivation to simply take up roots and dive into a new career comes as a package, along with the motivation to follow a spouse or family member to a new city or state. In this case you have major changes ahead of you, because you have to relinquish your ties to your existing job and deal with the uncertainties and newness of a new location and a new career at the same time.

This kind of change represents the most drastic change you can make in your career, and requires a good deal of thought, planning, and care. They say if you're starting out as a technical communication independent that you need at least 6-months' salary to get you started. A woman I corresponded with told me her salary dropped 20% the first year. Depending on your market, your skills, and your ambition, it can take up to a year or more after you actually start before you see a profit.

In my recent excursion into the workplace I took the kind of drastic move I'm describing above, because I had good reasons. My two young children had moved to Long Island and who wouldn't want to spend time in their vicinity? I had taken a paid leave of absence in New York the year before to finish a textbook, and so I knew something of the market and the culture there. I'll tell you a couple of things that convinced me I could do it: my past experience (I'd worked individual projects in the past and knew how to write manuals) and the February 1995 issue of Technical Communication including the Special Section: Measuring the Value Added by Professional Technical Communicators, which gave me a justification for my services and led me to believe I could convince software developers of the value of a technical writer.

But as I prepared to launch my mini career in the Spring of 1995, I did something that proved very useful to me later:  I inventoried my skills as a technical communication professional--not as an educator--and used that inventory as a base for my planning decisions. If you're thinking of making a similar move, the inventory of writing skills below can help you feel out your areas of strengths, because you'll need them.
 

  Inventory Your Technical Communication Skills

As I mentioned above, making a shift from the classroom to independent technical writing work means that you need a clear idea of what you have to offer clients. Of course, you might think you have a vast array of skills to offer, and don't need to waste time listing them. But if it makes any difference, I found that really you only offer one or two key skills in your independent work, and you do them very well. They make you your money.

Skills for the technical educator mutating into professional fall into two categories:  the skills that you bring into the workplace and the skills you need to pick up. The first category of skills derive from the work you did in gaining your education and your subsequent teaching/professional career. The second category of skills you usually don't learn about until you've done some independent work and see what a difference they make in your success.

What skills do you bring to the workplace?

• Writing and editing. Researching information, drafting procedures and brochure copy, writing clear sentences, identifying errors and cleaning up text, re-organizing documents, converting documents from paper or old timey word processors into command-driven formats, helping someone write a proposal, proposal editing. You have a chance to acquire these skills in your work as a teacher.
• Graphics. Edit bitmapped, scanned images, draw conceptual overviews, capture and label screens, paste up pages. The tools for this kind of work exist on your home pc as it comes from the box. You can familiarize yourself with new packages, especially the ones that do cool Web graphics, on your own time.
• Teaching and tutorial writing.  As a teacher you know how to structure a lesson, state objectives, design learning activities, and monitor progress. You're a natural for writing tutorial documentation and other getting started pieces that clients love so much. You can really help a client keep costs down by socking the procedures into a help file and producing a slim but highly focused getting started brochure. Your skills as a teacher prepare you for this work. You can also handle classroom teaching or teaching in the many computer training rooms that companies have.
• Interviewing. As a researcher and teacher you're used to interviewing other people for information. You know how to take down pertinent notes and ask the right kinds of questions. You know how to create surveys and questionnaires about the audience, users, or other persons involved in a documentation project. You know how to sit down with a subject-matter experts and get information to use in a manual.
• Planning. You have experience planning people and resources for a semester-long project called a class, so you should have some skills to apply to the planning of workplace projects. Not only can you plan a project, but you have the determination to carry it out.
• Collaboration. You know how to collaborate in a writing project, how to delegate writing or researching responsibilities, and how to maintain quality among collaborators. You should, if you have had experience writing articles, know the process of revision, editing, and proofreading that accompanies any production of valuable text.
• The ability to take rejection. As a submitter of articles to scholarly journals or, worse, short stories to short story anthologies or magazines, you know what it means to get a manuscript back in the mail with a polite letter. You will need this skill in the workplace, because you get very few clients from among the very many potential clients you pitch to.

What skills might you need to pick up?

As a teacher you bring a wealth of skills to the workplace that can give you a "service" to offer. However, you should look closely at those skills that you will need to acquire that perhaps your academic or moonlighting training might not have prepared you with. Consider the following list of such skills.

• Bidding. Sizing up a software program on the spot or from a set of disks, counting tasks/menus/screens/options, giving a fixed-price bid, or an estimate of the hourly rate. You don't want to scare any potential clients away, but you don't want to sell yourself too short. Finding just the right path between these conflicting goals can only come from experience. It makes me tremble just to think about it.
• Contract writing. How to write letters of agreement, non-disclosure agreements, formal contracts, informal contracts, and other legalistic documents. Luckily you can refer to Chapter 11 in this book for information on this topic.
• Document production. What processes to use for brochures, manuals, bound documents of all sorts. Just because of their involvement in business, my clients (at least in some cases) knew more than I did about books, printing, and other elements of production than I did. My academic training had not prepared me for this.
• Project management. Organizing writers on real-world projects, sharing responsibilities for writing, planning and scheduling with other employees, flowcharting or spreadsheeting projects.
• Hardware and software tools. You need experience with systems like Windows NT, UNIX, DOS, and tools like FrameMaker, Ventura, PhotoShop, WinHelp 4.0, RoboHelp and other professional tools. It also helps to say you know a broad range of business programs and utilities, including WordPerfect, Quatro Pro, Word, Excel, PowerPoint, Acess, Money, and various multi-media authoring tools. You can't get practice and facility with this broad a range of programs in most academic work, and will need to acquire them to succeed.
• Ability to follow formats. You think that you have control over format, and the cherished principles of things like balance and parallelism or task orientation. Perhaps, but for the most part you need a willingness to give up a theoretical format for a practical format, or more likely, a format that your client wants.
• Handling office politics. You have to recognize the existence of a power situation existing in any office where you occasionally come for interviews, review meetings, and other interactions with clients. Because of the laisez faire atmosphere in academic departments you may not handle the politics of an office or department as effectively as possible. Believe me, it's so easy to say something stupid at just about any time that it's a wonder I didn't get thrown out a window. Here's a for instance:  I once just blithely walked into a dimly lit programmer's area and started hunting up a propellor head to help me figure out how a print sequence worked. Oops! I got in major trouble for that, because the information I obtained, and used, became highly suspect later in the project by the person who believed she knew exactly how things worked, despite what the programmers said. Clearly I hadn't followed channels, and clearly I lacked the skill in sniffing out these kinds of things.

The problem with these skills, the ones you need to pick up, lies in the fact that you can't just take a crash course in them or read a book about them. You have to experience their lack, it seems, before you even know they exist or know enough to care about them. Face it, there's a fundamental difference between the nature of technical communication education and technical communication practice. In fact, an examination of some of that difference can supplement our discussion of skills by casting those skills against the background of ideological diversity.

Differences between academic work and industry work

In an article entitled "Collaborative Partnerships: Academia and Industry Working Together" in Techncal Communication, November, 1995, Deborah Bosley writes that,

"Higher education has as one of its primary missions the acquisition and dissemination of knowledge as an end in itself. Traditionally, higher education focused on acquiring knowledge, not necessarily on learning to use it. Conversely, industry views the value of knowledge and research as related directly to the market value of the products it produces."

I agree with this distinction because it clearly defines the two concerns of the different worlds:  one to produce knowledge for itself, and one to produce products. I see it played out over and over again. For instance, in technical communication education you would never admit that you taught students types of documents, because that smacks of "product" orientation. We enlightened teachers do things the "process" way, in fact encouraging students to consider how they do things rather than the end result. So the term product has bad connotations for starters among educators. But it has nothing to do with manufactured products, or only an abstract relationship. In another example, an alumn returned to campus to donate a stack of outdated software to our lab. Her "tutorial" on how to use the software consisted in the training session they do on their new hires to get them to assemble a Frame 4.0 manual the way they do it at XYZ Corp. It had little of what we would call education, but passed as such in the corporate world. The distinction extends to training versus education, theory versus practice, capitalism versus altruism, free information versus information as currency or information as politics.

Why do you need to know about the fundamental distinction between academia and industry if you 're considering a move to industry? Because you have to start thinking in terms of products. For good or ill, I tried to do this in my brochure, a document containing thumbnail sketches of the kinds of documents I could produce. You need to see where you can use your strongest asset, your writing and language skills, to further the client's business goals, or simply to get a job done cheaply and expediently. And because of the reduced interest in navel gazing, most clients get impatient when you tell them they should set up a focus group with their users to determine their document characteristics. They know all they need to know about users already. Users don't read the manual. For the most part, despite what you read in the journals about modern business, clients don't listen when you tell them to examine their business practices. They don't want to hear about any long-term investment in a company-wide style guide. It's not a product they want.

So the fundamental distinction between academia and industry does have some relevance to our discussion, because it helps understand, and give a background to, some of the understandings or misunderstandings that can arise when you embark on workplace activities. The differences between the two arenas carries over into other things like pacing, the importance of standards, and the nature of your daily contact with people.

You will also have to deal with pacing differences in any move into the workplace. Consider that the academic world revolves around two large time frames, the year and the semester (or quarter). In business you don't get such neat time durations. Everything needs to happen right away, or in a kind of convoluted before yesterday time frame, whereby you always come in under your time budget as a way of asserting your additional value to a client. In fact, the whole pacing of the corporate world continues to baffle me in some respects. I can never figure the absolute assertion of deadlines and product releases against some schedule slippage that would put an academic journal out of business.

Work in industry seems to move in different fits and starts, a seeming inconsistency that parallels the issue of standards and their application. For it's good natured sharing of information, the academic world didn't prepare me for the heat you take for misspellings, typos, and other flubs that the user notices and that damage your credibility. I tried to dot all my ts and cross all my is, but invariably I'd let some typo slip by. I seemed to have a knack for misspelling clients' names, or their company names, or for remembering clients' names wrong. It's scary to have a client point out a mistake a month into the project that you just never got around to fixing. Like it or not, the academic world breeds sloppiness in maters of copy editing and proofreading, and you can easily demoralize yourself with a juicy typo or hyphen fault.

Another difference between academia and industry lies in the way people come and go in the workplace whereas the set of colleagues in the university or college tends to remain more stable. I have had the contact person I knew on a job fired without anyone informing me, and the disks I had supplied taken, lost, or at least non-existent to the new person. Yet this person now overtook the management of my project, knowing nothing about it. This happens quite frequently, because as projects evolve you work first with some people and then with others. You need to develop a sense of acting and thinking on your feet and not let it bother you when this happens. It's just a part of business and you roll with it.

In these ways, the values, principles, and attitudes of the business world differ from that you know and love at the university or college. I hope this discussion has brought out some of the more startling instances of these differences as a way of helping you understand what you're in for in your move. And even though you can clearly see the differences between the two worlds (and I haven't dwelt on their many similarities) you still need to know what to expect that will startle and confuse you simply because of your training and familiarity with the academic environment.
 

What Can You Expect?

• You don't have any competition. When you start working you get your job by first sending a brochure, then a follow-up call, then an interview with 30 minutes (really 1 1/2 hours in Long Island), then a doc plan or proposal, then an OK. In effect the client has hired you because you convinced him or her of the need for your services. But the client didn't acknowledge the need for a writer before you showed up and thus hasn't made a prior commitment to the work you plan to do. This puts you on very shaky ground with "give up the project" as a ready alternative. You're disposable. But even more insidious, you don't have the validation of beating someone else out of the position and going through the reality check of that process.
• Companies may not know how to manage a writer. If you go about finding clients in the way I did, you will encounter customers who don't know how to manage a writer. This means that they don't have set schedules for paying a writer or cutting checks for one, and you end up having to bill against a purchase order or something where you forgot to put in milestones in the first place and so have to wait to the end of the project to get paid. In a related area, you can also expect clients not to appreciate how much writing costs. Of course for some paying you $35 per hour sounds like a bargain, but others get horrified at more than $10.00 per page. You can talk yourself blue in the face about the additional costs, ramping up and all that stuff, but to most clients you look expensive.
• Draft work has a diminished status. Oddly, in the business world, as I experienced it, the draft of a work has little status. I had difficulties getting clients to look my work over seriously, although in some cases you do get very thorough and expert technical review that can really help a project. In academia, a draft can get circulated plenty of times, with slight changes, in its progress toward perfection. But you may pay a price for showing around unfinished work to a client, because the client may mistake the unfinished-ness of the work for poor quality.
• You're an outsider. Because they've hired you to come in and take on a project, or even to come in for the obligatory times when you need to conduct interviews or work the scanner or copy machine or have a meeting, you don't know and can hardly get a handle on the people you encounter. It's hard to remember names, even if you try. And you don't have the chance to interact. I developed a self-absorbed persona, so that I just focused on the task. Of course, you can't do this all the time, and you relish a chance to get to know someone on the job. Sure you meet interesting people and get to work with neat systems, but in some cases, where you're physically isolated from other employees and don't have clear channels for communication then you can easily not communicate and it can get you in trouble. In some ways the academic world little prepares us to communicate as much as we really need to in the workplace in order to get the job done.

Conclusion

In this chapter I have tried to examine the motivation and kinds of skills you will need to make a smooth transition from the academic world of technical communication education to the workplace world of technical communication practice. The discussion focused on the differences between the two communities and cultures, but not without acknowledging their similarities. In some ways academic training prepares us very well to take on writing and editing work, and in other ways it offers us pitfalls and obstacles that, understood in terms of the differences between the two spheres, can lead to realistic expectations of workplace practices.