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.
I'd Rather Be Writing Newsletter
Get new posts delivered straight to your inbox.
About Tom Johnson
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in simplifying complexity, API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.