Tactics for Survival: A Technical Writers Field Guide to Overcoming the Forces of Petty PMs and Broken IT Environments
Last week I attended an STC chapter event that consisted of educators and practitioners discussing educational programs and workplace realities.
Most of the discussion focused on tools, which is a constant topic in these discussions. What tools should educators teach? How do they gain access to tools? Can you learn a tool enough during the trial period? Can you substitute open source tools for industry standards? Which tools should students focus on?
The discussion on tools is not a trivial one. But tools too frequently dominates these academic-practitioner discussions. Rather than a discussion about tools, I want to learn is how educators are preparing students for workplace realities -- not in preparing students to accept workplace realities, but how they're preparing students to resist workplace realities.
The old paradigm of preparing students to excel in the workplace can be misguided. Sure we want to prepare students for the workplace, but we don't want to prepare them to accept bad workplace practices. We don't want educators to fashion students into sheep to trot the path laid out before them. Students should not be conditioned to passively use the outdated tools they're told to use, to produce the static deliverables they're told to create, to conform to the last-minute documentation efforts expected by petty project managers.
If educators prepare students to adopt a broken IT workplace, where they will be happy in marginalization, content in absence, and silent in requirements, they do their students and the profession a disservice.
When educators prepare students for the workplace, the preparation should involve two components: (1) an awareness of common workplace practices for tech comm, and (2) an awareness of how workplace practices with tech comm should be. The second awareness is more critical than the first. Students should not only recognize poor tech comm practices in the workplace, but be prepared to rise up and correct them.
I outlined the worst case scenario of workplace practices with my Xtranormal videos. Most people who watched the videos agreed they were "painfully true." Rather than preparing students to perpetuate these bad practices by suggesting the workplace environment is a reality they must prepare for and accept, education should empower students with tactics for survival and success.
For example, students should be empowered to overcome the following workplace scenarios:
- A project manager excludes the technical writer from reviewing the language on prototypes.
- A project manager doesn't involve a technical writer until a week before release.
- A subject matter expert ignores requests to review documentation.
- A department head assigns more projects to one technical writer than is feasible.
- A project manager believes a technical writer's only role is to make the sentences grammatically correct.
- A project manager wants to lock down wiki pages from community editing because he or she fears edits.
- An interaction designer fails to include a help button in the prototypes and only adds one at the last minute in the footer.
- A manager doesn't want the technical writer to create screencasts because he or she believes only a professional audiovisual expert should create them.
- A committee meets to collaboratively write a script for a software demo -- the end result is 10 minutes long, wordy, and chaotic.
- The CIO believes in user education but does nothing to encourage or champion the cause; in the end, everything else always has a higher priority.
These are the realities of the workplace. I hope tech comm educators aren't preparing a whole new crop of sheep to accept and endure these practices. I hope they're teaching students to be empowered, self-willed, independent thinkers and contributors. I hope they're raising up little firebrands to transform bad workplace practices.
How exactly do you teach this kind of self-empowerment, to reject workplace status quo and work to change broken policies and procedures? How do you convert a group of introverted writers from a model of yes-sir-ism and yes-ma'am-ism to a freedom fighting tech comm strategists?
If there isn't a required course on it, there should be. Academics just need the right textbook. I'd call it Tactics for Survival: A Technical Writer's Field Guide to Overcoming the Forces of Petty Project Managers and Broken IT Environments, or something like that. Given all the discussion about this topic on forums, listservs, and blogs, I'd be surprised not to find some published work already written. I believe students will get more benefit out of a 100 page book with 10 essays on this topic than they would the 400 page all-encompassing reference manual on "Technical Communication" that I flipped through while listening to a discussion on tools.
I have a lot more to say about this topic, so I'm marking this post into a series called "Workplace Practices." If you know of a text that outlines best practices for tech comm in the workplace, let me know. If you're interested in writing a guest post on this topic, also contact me.
I realize it's a little aggressive to expect entry-level technical writers to be capable of transforming a broken IT environment, but too often practices at the beginning of one's employment transition into the way things are done in the future.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.