One of the many informative experiences I had at this year’s WriteTheDocs 2018 conference was my chat with employers/recruiters at the Job Fair. My primary goal was to learn what they looked for in their technical communication interns and entry level recruits, so I could bring that back to school. What I learned was not surprising, having only recently left industry for academia, but it was a wake-up call.
Recruiters want people (even their interns) who have experience and they want current and relevant experience.
I agree, that’s a bit of a Dog bites man story. Of course they do. All other things being equal, having current and relevant experience is almost always better than not. I suspect it is because the assumption is that with it, the person will become a productive team member sooner than later. What I think is often overlooked is how other idiosyncratic aspects of the specific job might have a greater influence in the time to productivity, such as the onboarding support (discussed in Sarah Day’s talk at this year’s conference), but that’s not something that I, as an educator, have much control over (unless you’re hiring me to consult on the process, of course).
What an intern needs
One of the things I have to keep in mind when reviewing my notes is that I was at a software documentation conference and the companies I talked to were software companies with open-source software products to document. In that context, it was natural that they were looking for writers with experience in their product domains: open-source tool experience (Git, GitHub, Markdown, etc.) They also looked for a passion for documentation—as evidenced by experience in such tools (e.g. documenting an open-source project in GitHub). I don’t know how many of these observations transfer to looking for writers in other industries.
The employers I talked to also expected a portfolio with writing samples. Presumably, not ONLY writing samples but also some project experiences, perhaps that included writing samples. I don’t know if one employer I talked to had read my website before we talked or was actually interested in candidates who could talk about documentation quality and the metrics used to measure it (I’d like to think the former, but I suspect it was really the latter).
Other topics that came up in our conversations were knowledge of, and ideally some experience with, single sourcing and content management systems (CMS).
It wasn’t clear if they were describing their ideal candidate or their minimum bar. I suspect the former, because as the latter, they’d have a very small pile of resumes to review because these are topics that many experienced professionals are still wrestling with.
The good news
Fortunately, my department has discussed these issues in our conversations on how we might improve our curriculum to produce graduates who are more qualified to compete in today’s job market. I’ll be creating a course to give to our undergraduates this fall that covers open-source documentation tools, CMS principles, and I might throw in some analytics as icing on the cake. I also have some projects that could use some documentation love and that would also make for some great additions to a portfolio. These are just a few things we are planning to help position our future graduates for success.
The challenges
An ongoing discussion in technical communication education surrounds balancing the teaching of tools and theory. Teaching tools is expensive, time consuming, and has a very short half-life (the time it takes for the instruction to become half as useful as it used to be) but it makes students more appealing to their first employer. Teaching theory is somewhat less expensive and less time-consuming (theory changes much more slowly than tools) but it puts the tool-learning burden on the first employer; however, having a solid understanding of theory should produce technical writers who are able to pick up tools more quickly and be more valuable in the long term. That’s the idea, anyway.
Teaching tools presents several big challenges: cost and maintenance. Licensing tools for students can be expensive for both the school and the students. Some tools have educational discounts, which helps, but some don’t. Departments and students don’t always have the budget to support these (often recurring) expenses and sometimes, what’s affordable isn’t always what the job market is asking for. Yet, even if the tool cost isn’t a problem, updating and maintaining the tools and their corresponding curriculum to keep up with industry practices and preferences adds another level of effort for the instructors. Not only do we have to keep the software up-to-date (i.e. be the sysadmin for the tool), but we have to keep the course notes, examples, and exercises up to date, which is an additional cost that the theory classes don’t require as much.
Unfortunately, the middle ground isn’t really a middle ground. To teach tools and theory really means you have to do all of both and not just some of each. Practically, using tools in the context of theory, or vice versa means teaching both of each and all the curriculum updating and tool maintenance that goes along with it. In my experience, teaching tools and theory at the same time has resulted in a superficial understanding of both, because both take time to master.
The net result
I’m fortunate to work in a department that recognizes the need for this type of change and has the collaborative spirit to share the load of taking this on. We want to do what’s best for our students, even if that means additional workload. As such, we’re dividing and conquering this challenge.
If you ever wondered what professors do in their “summers off,” developing new courses and keeping up with the industry and the state of the art are some of those things (there are many other things as well, by the way).