Should you get a degree in a tech comm program? Two considerations to keep in mind
- Tech comm programs are a popular topic
- A few disclaimers
- Risk #1: Not enough emphasis on tech skills
- Risk #2: Drift from corporate relevance
- Small-time programs versus big-name programs
- Your reactions and input
Tech comm programs are a popular topic
Recently I was chatting with a student from a Technical and Professional Writing undergraduate program at San Francisco State University. She wanted to know more about API documentation (since this wasn’t necessarily emphasized in her program) and was doing some research about its importance in the field. So she scheduled some time to come down to my workplace and interview me about it.
I’ve come across several other students who read my blog, see the emphasis on API documentation, realize it’s not covered in their tech comm program, and suddenly start to feel a bit concerned. They often reach out to me for more information as well.
My chat with the SFSU student got me thinking about tech comm programs in general. The topic seems to be constantly cropping up regularly. For example, on the technical writing forum on Reddit, I often see threads like this:
(By the way, for more scholarly research on tech comm academic programs, see Lisa’s article Master’s Programs in Technical Communication: A Current Overview.)
Also, my oldest daughter is in the middle of deciding where to go to college (but not for tech comm), so I guess I have academic programs on my mind.
In short, discussions about tech comm programs are lively as ever. But the question is usually whether these programs are worth attending, especially since most current tech comm professionals didn’t graduate from these programs. For years I haven’t had much advice when asked this question, but now, especially after attending an academic conference in Louisiana (which I wrote about here), I have some more insights. Even so, I am not an expert in this area, and I probably shouldn’t be writing about it, but I will go ahead and say a few things anyway.
A few disclaimers
Before I get into my insights on this topic, keep in mind a few things. First, I’ve never attended a tech comm program nor taught in one. I’m also in the San Francisco Bay area, in the field of software documentation. Also, I haven’t worked with many people who have tech comm degrees. People frequently tell me I’m in a bubble, so maybe my recommendations only apply within my bubble. Take my thoughts with a grain of salt, recognizing that I’m an outsider looking in, and am often proved wrong. Yada yada yada.
Also, my advice here applies only if you’re looking to eventually get a corporate/professional job working as a technical writer of some kind. If you don’t have professional ambitions for the corporate world (for example, maybe you want to teach rhetoric at a university), then you can probably skip this post. (Actually, if you have academic ambitions to study rhetoric for its own sake, you’re probably not even reading my blog.)
Okay, with those disclaimers out of the way, my advice for those contemplating tech comm programs is to be aware of two main risks with tech comm programs:
Both of these points are more subtle than they initially appear, so let me elaborate.
Risk #1: Not enough emphasis on tech skills
Academic programs will teach you how to think — how to analyze, evaluate, synthesize, argue, conduct research, and more. The point of an academic education is usually to deepen your mental faculties and make you more analytical, insightful, and aware. Academic programs emphasize the theoretical aspects of tech comm, looking at discourses and patterns across various genres. Most assume you can already write (though they might provide courses on editing, which you should certainly take).
The problem is that when you finish your program and start looking for jobs, most hiring managers at companies won’t know much about the theoretical foundations of technical communication. They’ll ask for a writing sample, and if it reads well and resembles common documentation patterns (with subheadings and numbered lists), it will probably pass their “sniff test.”
I say “sniff test” because it’s almost impossible to evaluate writing with any depth unless you can spend a lot more time with the document than most hiring managers are willing to do (spending time to understand the documentation’s context, its place within your doc portal, its audience and skill level, evaluate the accuracy, assess the terminology, and so on).
Without more understanding about how to evaluate your writing, they’ll begin to evaluate your technical skills instead. Technical skills are much easier to assess than writing skills. Hiring managers can assign a junior programmer to probe your technical knowledge. The programmer might draw a function on the board and ask you what it does. With tech knowledge, it’s easy to check boxes — does the person know the various parts of a function/class/algorithm? Either they know the various components of the function, or they don’t. Easy to assess.
Because tech skills are easier to assess than writing skills, the hiring process will often focus more on the tech skills rather than the writing skills. Much of that knowledge about the theoretical foundations of tech comm that you learned in a tech comm program will be overlooked — not because it isn’t valuable or useful or highly relevant, but because most hiring teams simply lack the awareness about how to assess writing beyond a superficial level.
If you really want to evaluate whether the technical writing samples in a portfolio are any good, you’d need to ask some of the same questions that I pose in my section on How to evaluate documentation, which pulls highlights from the various essays in my Simplifying Complexity series. For example:
- Does the writer break up the complex information into a way that is easy for users to follow?
- How does the writer create workflow maps or other navigation to help users through each chunk in the larger process?
- What kind of metadata does the information have that makes it discoverable? How is this metadata integrated with search functions?
- How does this information fit into the larger information landscape on the doc portal?
- Does the information follow a progressive disclosure flow, with increasing levels of detail from title to summary to mini-toc to section headings to topic sentences within sections and so on?
- Does the information follow the expected discourse patterns within the genre? For software doc, that might include goals, prerequisite states, action and reaction, unwanted states (troubleshooting)?
- Does the information align with the needs of the user? How did the writer discover what information needs the users have? What mechanisms are in place to ensure feedback for future iterations?
- Are the right technical terms being used? How do these terms compare with other terms in the domain, with competitors, and other external sources?
- Does the software documentation communicate the larger story of the product? What is the company’s story about the product versus the user’s story, and how does the information align the two?
And so on. These aren’t questions you can easily answer by glancing at a 2-3 page writing sample during the hiring process. If you have an experienced technical writer interviewing you, maybe he or she can ask these questions during an interview to surface the information, checking to see if these topics are even on your radar. Then you can articulate all the decisions you made around organization, focus, terminology, and more. If you draw blanks, the interviewer can see that you lack these deeper theoretical foundations.
But many companies that are hiring technical writers don’t really understand much about tech comm. They don’t know enough to ask questions like the ones I listed above. They know they need good docs, so they look for a technical writer. But beyond a few superficial ideas about what constitutes good docs (clear language, some visuals?), they simply lack the background to vet the candidate’s writing, so they will focus on your tech knowledge instead.
Since most academic programs focus on theory rather than tech, the programs won’t necessarily open doors for you at companies. As a result, if you are in a tech comm academic program, where possible, look to complement your study of tech comm theory with a smattering of technical courses as well. Minor in a technical specialization, for example.
The variety of technical specializations within tech comm is too diverse to mandate any specific curriculum of courses. Suppose you require all students to take Java programming. That’s great for those moving towards API documentation, but what about the ones aspiring toward science writing? What about the required course in physics? That would be great for science writers, but what about the course in chemistry? That would be great for the medical writers, but what about the course in mechanical engineering? That would be great for hardware documentation jobs, but what about … See my point? You can’t expect your professor, who is under the gun to publish or perish in academic journals, to also be an expert in 17 different technical fields. Therefore, you might have to go out of your way to take technical courses in your program, deciding for yourself what is right for your focus. More on that later in this post.
Risk #2: Drift from corporate relevance
The other risk of technical communication programs relates to a theme I wrote about in my corporate exodus narratives post. It’s the problem of drift in academia away from corporate concerns. You might find yourself in a tech comm program where people are pursuing masters and dissertations on topics that are largely irrelevant to corporate needs and interests.
For example, take a look at these dissertation topics from Texas Tech University’s Technical Communication & Rhetoric program. Suppose you’re hiring a technical writer to document your software. Which of these topics looks relevant to the job?
- Tracing economic sustainability in the global coffee trade: The rhetoric of the international coffee organization
- Negotiating the supermarket: A critical approach to nutrition literacy among low-income consumers
- Safety within oil rig culture: Deciphering intercultural miscommunication among offshore petroleum workers
- A case study investigation of the shared identity of the Papua New Guineans against domestic violence Facebook group
- ‘Tell me what it’s like’: Narrative lifeworlds of white, American expatriate women in Qatar
You might object and say that these students aren’t aiming for technical writing jobs in the corporation, so their areas of study are entirely justified and valid. Yes, I would agree. But I’m operating on the assumption that students in tech comm programs have aspirations for professional technical writing jobs in companies. In that case, would the areas of study still be relevant?
There are many PhD topics that do look relevant to corporate needs. For example:
- Workplace communication practices and perceptions of novice engineers
- Identifying editing strategies for grant proposals: Results of coding editors’ approaches to comments, comment types, and edit types
- How games work: A case study of role-playing games as instructional documentation
- Reports, recommendations, and retellings: Communicating aircraft accidents and the rhetorics of safety
- A praxis approach to understanding the Internet and computer technologies use among the aging population in India: A study in cultural technical communication
- User experience of access points: Eye-tracking, metadata, and usability testing
Overall, there’s a lot of freedom under the umbrella of rhetoric, and students are free to choose their own topics and interests. Many academics don’t see themselves as a “tool of the capitalist state,” and so you will find that rhetoric is a discipline that stands on its own, with a rich history of analysis that doesn’t need to have anything to do with technical writing at a company.
Admittedly, to some extent, the topic of inquiry doesn’t really matter (whether you’re analyzing coffee grounds or oil rigs or the patterns ants follow on sidewalks); what matters is how your approach the topic, because the real focus in an academic program is to deepen your analytical skills and research abilities. Even so, if you do your master’s thesis or dissertation on a topic of little interest to corporations, and then you start shopping yourself around to companies, they might be completely baffled by your research. Not only do corporations already lack understanding of writing beyond the basics, they understand rhetoric even less (we try to avoid rhetoric around here, they might say). They will look at some of these topics and perhaps dismiss their relevance entirely.
Small-time programs versus big-name programs
Now here’s the irony about tech comm programs. At higher-level, more prestigious universities, if your faculty have their heads buried in peer-reviewed journals and make enough to stay within the confines of the university, this might actually work against you, prompting you more towards the drift I described earlier.
In contrast, if professors are adjuncts, paid less, or teach at lower-tier colleges, they might be more apt to have one foot in the world of consulting, working by night on corporate gigs and by day at the university, or vice versa. Many tech comm professors are hybrids like this. And if your aim aligns with a corporate trajectory, these hybrid professors who have one foot in and one foot out, so to speak, might just prepare you more than someone who is so far immersed in peer-reviewed academic discourse and free-range critical inquiry that he or she can’t pronounce the word “DITA” correctly and also draws a blank when you say “docs as code.”
Additionally, the small-time programs (e.g., community colleges that might have recently transitioned into four-year programs, or other lesser-known programs) might have a stronger focus on job placement and hiring after graduation. They might have a more vocational, tech-heavy emphasis, which again, is something that benefits students with a corporate trajectory (at least at the lower levels of employment).
In contrast, a top-tier tech comm program might encourage you to get a PhD in rhetoric just for the love of learning. You’ll be the only one who can excogitate the ways agile scrum workflows subtly align with Burke’s Rebirth Cycle, and no one will really care, but you might be able to put that learning to good use somehow (as long as you don’t bring it up in a job interview).
To be fair, higher-level analytical thinking (both encouraged and required in top-tier programs) probably prepares you to climb up the corporate ladder into more strategic and executive levels, where you really need this kind of in-depth rigor to make data-driven, weighty decisions. But it can take years to get to that point.
Regardless of where you find yourself, in a small-time program or the most prestigious program in the nation, if you’re going to choose topics for research, consider focusing your research on topics like this:
- “Application Programming Interface Documentation: What Do Software Developers Want?” by Michael Meng, Stephanie Steinhardt, and Andreas Schubert. Journal of Technical Writing and Communication. 2018, Vol. 48(3) 295–330. (ResearchGate link)
- “When Not to Comment: Questions and Tradeoffs with API Documentation for C++ Projects.” By Andrew Head, Caitlin Sadowski, Emerson Murphy-Hill, and Andrea Knight. 2018 ACM/IEEE 40th International Conference on Software Engineering. (ResearchGate link. I also found it online here.)
(I summarized these articles here and here.) This assumes your focus is on software documentation, which might not be the case. If you’re studying medical writing, policies and procedures, corporate communications, science writing, or something else, do research relevant to the types of jobs you might pursue post-graduation. Maybe consider the scenario where your research comes up in a job interview. Would the interviewer consider this knowledge relevant to the role?
Coming back to the original question: are tech comm programs worth it? My stance is that education is almost always a good move. Seriously, especially if you’re young and don’t already have a family to support, get education while that window of opportunity is open. Once you’re saddled with obligations, carving out time for an academic program while also working full-time and tending to a family can be either impossible or exhausting.
Unfortunately, as I mentioned in my post on risk-taking, often the choice to pursue technical writing doesn’t come until after your big dreams fail and reality sets in, so chances are you might be in all kinds of life situations (in your thirties or forties or so) when you decide to transition to technical communication. Whatever your case, if the opportunity for education presents itself, by all means do it, especially if you want a stronger foundation in tech comm strategies and theory.
And if you have your target set on a corporate job, take care to do the following in your program:
- Supplement your tech comm theory with technical courses. Take as many technical courses as you can, actually. (An ultimate move would be to minor in a technical specialization or complementary skill, such as graphic design, computer science, or the like.)
- Do research that companies would perceive to be relevant to the job. Again, this applies only if you have ambitions of working in the corporate world after graduation. And what qualifies as relevant obviously depends on the corporate sector, industry, and domain you want to enter.
If tech comm programs don’t fit into your life (maybe you already have a full-time job and family obligations, or maybe the programs are too expensive), then don’t worry. You can make yourself marketable by doing the same two points:
- Take some technical courses online (e.g., with Lynda.com, Pluralsight, Udacity, Udemy, Coursera, etc.). Take as many as you can related to the specialization you’re targeting.
- Make your knowledge visible through a blog. Write a dozen posts that show off your curious, analytical, articulate mind in action. Focus your posts on tech comm theory (which you can learn from reading books, journal articles, and blogs on tech comm topics). This will impress hiring managers about all the writing elements they probably never considered.
Your reactions and input
Here’s a short survey to gauge your reactions and input on the ideas in this post. You can view the ongoing results here.
About Tom Johnson
I'm a technical writer / API doc specialist based in the Seattle area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out my API documentation if you're looking for more info about that. If you're a technical writer and want to keep on top of the latest trends in the field, 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.