My journey from academia into technical writing

8 minutes read

Occasionally, unhappy academics ask me for advice on how to get non-academic jobs. Few of them consider technical writing as a career option, and I think more of them should—technical writing values skills that many academics already have, and provides similar intellectual challenges, but with greater career flexibility than academia has.

Here, I’ll describe my journey into technical writing and why I found it fulfilling, adding on some basic advice and views on the technical writing job market. I should clarify, however, that all my experience is in technical writing for software. It’s possible that much of what I say here also applies to other domains of technical writing, such as for medical devices or hardware. It’s just that the technical domain knowledge you might have to pick up would be different.

My story

I got into technical writing sorta by accident. Similar to many PhDs in my time, I was attempting to transition into data science. I was applying to data science jobs, and getting some interviews, when the job sites started displaying ads for technical writing jobs to me. The skillsets requested in those ads (coding knowledge + writing skills) seemed to fit me well, so I thought “why not” and applied to a couple of those jobs. As it happened, the first job I was offered was a technical writing job, so I took it.

I didn’t have much expectations of the job at the time—my main priority was leaving the toxic environment of academia and being paid a decent wage. Those two conditions were met, but in addition, I also found the work to be surprisingly interesting and fulfilling. It turns out (shock) that I really enjoy the challenge of organizing information and writing elegantly about difficult topics. And that I also like learning new concepts and technologies on a regular basis (and being paid for it to boot). I’ve since transitioned to a new role where I’m doing responsible AI research and education full-time, but I sometimes think about returning to technical writing.

What I like about technical writing

Technical writing sounds boring—how interesting can it be to write software manuals? But it turned out to be a mix of figuring out creative solutions to pedagogical problems, learning new technologies, and research—all activities that I enjoy.

The creative aspect of technical writing is one that is probably invisible to most people. As a technical writer, you cannot just regurgitate an edited version of the engineers’ description of the software. This will be unhelpful to most users, who don’t have the background knowledge that the engineers who made the software do. Your challenge is to take a perspective that many engineers don’t take—what a user needs to know to be able to accomplish their tasks with the software—then find and organize information in a way to fit that perspective.

Let’s start with finding that information. Of course, you should read the design specs and engineering docs. But that’s far from enough. To educate users, you should yourself be a frequent user, trying to accomplish the tasks that you think your target audiences wants to accomplish. You will often be the alpha tester of new software features, and you will find lots of bugs in the process of figuring out what happens when you take a series of actions that the engineers did not anticipate. You will be interviewing subject matter experts in all parts of the organization, such as support, QA, software engineers, solutions engineers, and product managers, in order to find out what they meant a certain feature to do, or what kinds of goals they expect users to have. If you became an academic because you are intellectually curious, you will take naturally to the task of gathering such information and figuring out where the gaps in your knowledge are.

Doing this research involves some creativity on your part—the information you need will by no means just be lying there for you to edit and publish. Once you have the information, the crafting of documentation will also involve creativity. If you have any teaching experience, you’ll know that there are better and worse ways to present or organize information, relative to your pedagogical goals. Technical writing is no different. You’ll need to write topics of different styles and catered to different levels depending on your learning objectives and audience. You’ll need to find creative ways to make complicated concepts clearer and less intimidating. If the product is complicated, you’ll have a creative challenge figuring out how to organize hundreds or thousands of different topics in a way that enables readers to find the information relevant to their needs as easily as possible.

Finally, unlike in academia, your outputs are typically published much more quickly and you’ll have the satisfaction of seeing your work “out there” and being used on a more frequent basis. You might even get to interact with satisfied customers and hear how you helped them solve their problems.

How to transition to technical writing

So, how do you get to the happy place of having a reasonably paid, intellectually satisfying, and creative job? Especially if you have not worked in the software industry before? I lucked out by getting interviews at companies that were happy to hire junior writers with no experience in the industry, but if I were to start over, I’d do the following:

  1. Have a writing sample that is an example of software documentation. You can do this by writing an explanatory blog post (a tutorial on how to do some task, or an explanation of a technical concept) or by contributing to open-source software documentation.
  2. Rephrase my teaching skills in terms that are clearly related to the job description and understandable to non-academics. Teaching is ultimately about communication, so your teaching experience is a plus for any job that asks for good verbal or written communication—you just have to rephrase it to directly include the communication-related key phrases in the job description.
  3. Rephrase my research skills in terms that are clearly relevant to technical writing and the job description. As part of your research, you almost certainly had to quickly learn new technical concepts, determine what information gaps you need to fill to proceed, and figure out whom to talk to to get the relevant information. These are all skills that are important in technical writing.
  4. Emphasize long-term project planning and time management skills. Planning and successfully completing something as complex as a dissertation is evidence of project planning skills. So is designing and planning an undergraduate course. And, like most academics, you almost certainly had too much to do and too little time.

Worried about doing 1. because you have no prior programming experience? You can restrict yourself to technical writing jobs that don’t ask for that experience, but as a career move I think learning a programming language is the better option in the short and long term. There’s more competition for entry-level jobs that don’t require programming experience, and you’ll get paid more for more “technical” technical writing jobs. Bear in mind that you do not have to become as expert in programming as a software engineer. You just need to be able to know a language well enough to write short snippets of functional code in it, and to be able to read code. Something like Google’s course on Python can get you started.

Market conditions

I found the technical writing job market to be somewhat maladjusted, to the benefit of qualified applicants. My assessment, based on a few years of job searching and interviews as someone of mid-level seniority, is that it’s really easy to get interviews for software documentation jobs, if you have reasonable programming skills and have software documentation writing samples (especially developer documentation). This is due to a confluence of the following factors:

  1. The combination of skills (programming plus writing, with actual writing samples to show for it) is still relatively rare.
  2. If you have been a software developer before, or have a computer science degree, you can typically get paid a lot more being a software engineer, than being a technical writer. So a lot of people who are qualified are not in the market.
  3. There is rapidly growing demand for developer documentation, as more and more software products being sold are tools for developers, such as APIs.

I regard this as a sort of market failure, since according to standard economics, if there’s high demand for a combination of skills that are hard to find, salaries should rise accordingly. My suspicion is that a lot of salaries for technical writers are still being benchmarked to salaries for technical writing jobs that don’t require knowledge of programming. In addition, communication and teaching are traditionally undervalued functions. While there are a few companies that have adjusted wages somewhat to account for supply/demand discrepancies, a lot of the market is still underpaying given the rarity of the skills they demand. For a mid-senior level job in the US that requires me to read source code and write code samples, my view is that something in the low six figures is the minimum acceptable compensation, but I consistently see people lowballing that even in expensive metropolitan areas.

Resources

If I’ve convinced you that technical writing is a career worth exploring, check out the following resources for more information: