Tell me about technical writing
February 10, 2016 11:50 AM Subscribe
Are you a technical writer? How did you get your job? What do you do on a day-to-day basis? What are the pros/cons of your job? What's the salary like?
I've worked in the academic sciences since graduating college (biology PhD, two postdocs) and am considering jumping ship. Not sure what to do with my life, but given my technical background and strong writing skills, I'm thinking about technical writing. Not sure I'm qualified, or what the qualifications are, or what these jobs really entail, or much of anything else ... so if you're a technical writer, or former writer, please tell me about your job.
I've worked in the academic sciences since graduating college (biology PhD, two postdocs) and am considering jumping ship. Not sure what to do with my life, but given my technical background and strong writing skills, I'm thinking about technical writing. Not sure I'm qualified, or what the qualifications are, or what these jobs really entail, or much of anything else ... so if you're a technical writer, or former writer, please tell me about your job.
... And there's the other side of technical writing, which doesn't involve any coding know-how whatsoever. You can write proposals, whitepapers, case studies, technical reports, that sort of thing. It's all under the larger scope of technical writing.
I started out writing online help sixteen years ago, my first job out of college. (I have a Journalism degree but have never worked as a journalist.) For a few jobs, I had to use Frame or InDesign, but by and large, I use Microsoft Word. My best skills are 1) Convincing subject matter experts to participate in the process, 2) Accepting edits gracefully, 3) Writing clean, standardized copy.
The qualifications vary as much as the work itself. For my first job, I had to sit on a lot of conference calls with people in remote offices and track features to write about in future software releases. Based on the release date, our project manager would set a schedule for drafts and revisions, and we'd work with various editors and subject matter experts to make sure everything was clean and ready for prime time.
My second job was working as a technical writer for a dotcom. I wrote online help, as before, but also some user manuals for web-based software, whitepapers, disaster recovery documentation, and internal policy documents. I also did a lot of software QA. The best part of my job was working with the marketing team, where I served as a liaison between marketing folks and the development team to translate technical features into layman's terms. I used Word almost exclusively.
My third job was writing HIPAA training for a small chain of nursing homes. Word again.
My fourth job was more software documentation, working with a project manager to finish up a thick user guide that another writer had abandoned. Lots of feature discussions, working with legal, taking calls with developers in Minsk (really), and dropping everything into Frame and RoboHelp.
My fifth job was proposal writing and editing. Also in Word. I learned some graphic design basics and turned whiteboard drawings into clean graphics and process flows.
My next job (after a departure into totally different work) was also proposal writing and editing. A lot more focus on being able to read and interpret requirements, work with subject matter experts without making them angry or frustrated, and cram everything into short page limits.
So yes, absolutely you can go the way of super-technical writing that requires more than a basic understanding of coding/database principles. And there's fantastic money in that. But I'm a total Luddite and I've always been able to find technical writing work in some sort of flavor. It's not easy work, but it's not bad.
posted by mochapickle at 12:34 PM on February 10, 2016 [3 favorites]
I started out writing online help sixteen years ago, my first job out of college. (I have a Journalism degree but have never worked as a journalist.) For a few jobs, I had to use Frame or InDesign, but by and large, I use Microsoft Word. My best skills are 1) Convincing subject matter experts to participate in the process, 2) Accepting edits gracefully, 3) Writing clean, standardized copy.
The qualifications vary as much as the work itself. For my first job, I had to sit on a lot of conference calls with people in remote offices and track features to write about in future software releases. Based on the release date, our project manager would set a schedule for drafts and revisions, and we'd work with various editors and subject matter experts to make sure everything was clean and ready for prime time.
My second job was working as a technical writer for a dotcom. I wrote online help, as before, but also some user manuals for web-based software, whitepapers, disaster recovery documentation, and internal policy documents. I also did a lot of software QA. The best part of my job was working with the marketing team, where I served as a liaison between marketing folks and the development team to translate technical features into layman's terms. I used Word almost exclusively.
My third job was writing HIPAA training for a small chain of nursing homes. Word again.
My fourth job was more software documentation, working with a project manager to finish up a thick user guide that another writer had abandoned. Lots of feature discussions, working with legal, taking calls with developers in Minsk (really), and dropping everything into Frame and RoboHelp.
My fifth job was proposal writing and editing. Also in Word. I learned some graphic design basics and turned whiteboard drawings into clean graphics and process flows.
My next job (after a departure into totally different work) was also proposal writing and editing. A lot more focus on being able to read and interpret requirements, work with subject matter experts without making them angry or frustrated, and cram everything into short page limits.
So yes, absolutely you can go the way of super-technical writing that requires more than a basic understanding of coding/database principles. And there's fantastic money in that. But I'm a total Luddite and I've always been able to find technical writing work in some sort of flavor. It's not easy work, but it's not bad.
posted by mochapickle at 12:34 PM on February 10, 2016 [3 favorites]
I've been a technical writer off and on (mostly on) since 1992. I'm another one who fell sideways into the job - I was working as a developer and suffering from burnout. I was asked to do a technical review of a document, and found myself rewriting it. I thought to myself, "I could do this." I eventually networked my way into a technical writing role, and basically learned by doing.
I am paid well, but that's partly because I have more of a technical background than most writers - I also maintain our company's DITA architecture, and can whip up Perl scripts when needed.
I'm not sure whether actual educational experience in technical writing is required nowadays. Probably not, if you can produce a portfolio to show at interviews.
The writing tools depend on the environment. Large shops use Adobe FrameMaker, but I haven't used it in years. In other places, I've used DITA, Madcap Flare, and plain old Word. You'll also need to be able to create and edit screen shots (images) - GIMP is a free tool for this, and I've frequently used SnagIt and have a working relationship with Photoshop (when it's available).
You'll need to be able to write clearly and concisely, and to identify the audience that you are writing for. You'll also need some people skills - the people who have the information you need ("subject matter experts" in the trade) are often very busy, and reluctant to give you the time you need.
Good luck - I hope it works out for you. I have no regrets about my career path.
posted by tallmiddleagedgeek at 12:37 PM on February 10, 2016 [2 favorites]
I am paid well, but that's partly because I have more of a technical background than most writers - I also maintain our company's DITA architecture, and can whip up Perl scripts when needed.
I'm not sure whether actual educational experience in technical writing is required nowadays. Probably not, if you can produce a portfolio to show at interviews.
The writing tools depend on the environment. Large shops use Adobe FrameMaker, but I haven't used it in years. In other places, I've used DITA, Madcap Flare, and plain old Word. You'll also need to be able to create and edit screen shots (images) - GIMP is a free tool for this, and I've frequently used SnagIt and have a working relationship with Photoshop (when it's available).
You'll need to be able to write clearly and concisely, and to identify the audience that you are writing for. You'll also need some people skills - the people who have the information you need ("subject matter experts" in the trade) are often very busy, and reluctant to give you the time you need.
Good luck - I hope it works out for you. I have no regrets about my career path.
posted by tallmiddleagedgeek at 12:37 PM on February 10, 2016 [2 favorites]
And re: how I got my jobs... Referrals. After the first two technical writing jobs, every other job I've gotten has been through referral. I've known writers to have very long memories and be pretty loyal to writers who are easy to get along with and turn in halfway decent work.
posted by mochapickle at 12:39 PM on February 10, 2016 [1 favorite]
posted by mochapickle at 12:39 PM on February 10, 2016 [1 favorite]
I was a technical writer for about six years. I was hired out of university (I have a math degree) based on my ability to code and a writing sample from the student newspaper.
Day to day work was as described above - writing technical documents based on software specifications/actual review of code/using product/talking to the developers or analysts, circulating documents for review and edit, publishing documents. I used Word in one job and some custom XML tools in others. I also maintained some documentation build tools and automated review tools.
I quit technical writing because it was boring. I felt I spent too much time by myself pounding out repetitive documents and not enough time talking to people. I was paid very well at a large company and was worried I would not be able to advance my career or my pay working elsewhere. Also I found that technical writers were typically looked down upon by the other disciplines. I transferred into a related technical career based on a referral and was very successful afterwards doing other things that pay even better.
Work/life balance as a technical writer was excellent. It was very compatible with pregnancy and raising an infant/toddler. Once you know what you are doing it doesn't take too much brain power. I do not regret doing the job, it was a great start to my career and gave me a lot of transferable skills that serve me well today. I also do not regret quitting at all.
posted by crazycanuck at 12:48 PM on February 10, 2016 [2 favorites]
Day to day work was as described above - writing technical documents based on software specifications/actual review of code/using product/talking to the developers or analysts, circulating documents for review and edit, publishing documents. I used Word in one job and some custom XML tools in others. I also maintained some documentation build tools and automated review tools.
I quit technical writing because it was boring. I felt I spent too much time by myself pounding out repetitive documents and not enough time talking to people. I was paid very well at a large company and was worried I would not be able to advance my career or my pay working elsewhere. Also I found that technical writers were typically looked down upon by the other disciplines. I transferred into a related technical career based on a referral and was very successful afterwards doing other things that pay even better.
Work/life balance as a technical writer was excellent. It was very compatible with pregnancy and raising an infant/toddler. Once you know what you are doing it doesn't take too much brain power. I do not regret doing the job, it was a great start to my career and gave me a lot of transferable skills that serve me well today. I also do not regret quitting at all.
posted by crazycanuck at 12:48 PM on February 10, 2016 [2 favorites]
I have been a technical writer for about 3 1/2 years, working for a state government agency. In my previous job, I primarily did software training, but also developed a lot of user documentation. Otherwise, I've never taken any technical writing classes, or even any college level English.
My job is actually a mish-mash of developing online help for computer systems, creating electronic tutorials, creating user manuals, providing end user training on a variety of systems, and also doing QA/writing test scripts for system enhancements.
I mostly use Word, SnagIt, HTML, and CSS in my work. I have played with MadCap Flare a bit. I use Adobe Captivate to create tutorials.
For me, this is one of the duller jobs I've held, but I think a lot of that has to do with the organizational environment I am in.
posted by medeine at 1:28 PM on February 10, 2016 [1 favorite]
My job is actually a mish-mash of developing online help for computer systems, creating electronic tutorials, creating user manuals, providing end user training on a variety of systems, and also doing QA/writing test scripts for system enhancements.
I mostly use Word, SnagIt, HTML, and CSS in my work. I have played with MadCap Flare a bit. I use Adobe Captivate to create tutorials.
For me, this is one of the duller jobs I've held, but I think a lot of that has to do with the organizational environment I am in.
posted by medeine at 1:28 PM on February 10, 2016 [1 favorite]
Although I am now an in-house software developer biotech/pharma-type company, I was a technical writer for a software company for about five years in the early 2000s, and wrote help systems, user manuals, quick start guides, etc. Like most of the people who have already responded in the thread, I came into the gig sideways: I was a technical support engineer until the company had a shakeup and outsourced most of the tech support positions. As I had a BA in English and had been the editor of the monthly tech support newsletter, I was able to transition to the Pubs team.
Day-to-day duties were a mix of meetings, time spent learning the software, and writing...although working on the Help system was more like a form of development, as it was HTML- and XML-based and needed considerable testing of its own. I worked closely with a very good editor, thankfully - there's a large gap between knowing how to write and knowing how to write a technical document for non-technical end users. Thankfully, she was a patient person.
Pros: I wrote a lot, I was mostly respected for my work, I was a contributor to larger projects that could not have shipped without my participation, and I got to see my work appear in print.
Cons: The work could be very dry, I did not always feel valued, no one really wanted to read what I was writing, and the job didn't pay exceptionally well. But it was a job, and on the whole it was a better job than technical support. It has been eleven years since I transitioned from technical writing to development and I don't miss the technical writing at all, TYVM.
Software used: FrameMaker, Word, HTML, XML, and some specialized Help authoring tools I can't remember.
Other thoughts: Tech writing is a respectable job, but in my experience it does not command the respect it likely deserves. Even though your documentation is often a critical deliverable, no development schedule is ever going to be extended on your behalf. The job sits off to the side of other technical development roles -- it's important, but its not IMPORTANT. Still, there are many, many worse ways to make a living.
posted by mosk at 1:54 PM on February 10, 2016 [1 favorite]
Day-to-day duties were a mix of meetings, time spent learning the software, and writing...although working on the Help system was more like a form of development, as it was HTML- and XML-based and needed considerable testing of its own. I worked closely with a very good editor, thankfully - there's a large gap between knowing how to write and knowing how to write a technical document for non-technical end users. Thankfully, she was a patient person.
Pros: I wrote a lot, I was mostly respected for my work, I was a contributor to larger projects that could not have shipped without my participation, and I got to see my work appear in print.
Cons: The work could be very dry, I did not always feel valued, no one really wanted to read what I was writing, and the job didn't pay exceptionally well. But it was a job, and on the whole it was a better job than technical support. It has been eleven years since I transitioned from technical writing to development and I don't miss the technical writing at all, TYVM.
Software used: FrameMaker, Word, HTML, XML, and some specialized Help authoring tools I can't remember.
Other thoughts: Tech writing is a respectable job, but in my experience it does not command the respect it likely deserves. Even though your documentation is often a critical deliverable, no development schedule is ever going to be extended on your behalf. The job sits off to the side of other technical development roles -- it's important, but its not IMPORTANT. Still, there are many, many worse ways to make a living.
posted by mosk at 1:54 PM on February 10, 2016 [1 favorite]
I was a technical writer for a while, mostly early in my career, but I'd dip back in for a project here and there.
Writing software manuals and online help was one of the most boring things I've ever done. A lot of it was very repetitive, filling in boilerplate and having the most tedious arguments you can imagine about style guides and shit. I once wrote a 300-something page manual without using any be verbs (E-Prime) just to stay awake.
But I have also done some ghostwriting type stuff that was more interesting and much less repetitive, writing articles and white papers and things. That could be kind of fun sometimes.
There is a very wide range of types of technical writing, and as a lady working in primarily male dominated fields, I'd have to deal with people assuming my job was much more administrative than it was, which could get pretty miserable sometimes, especially when I was in a position where I was dealing with different clients for each new project and I'd have to deal with it all anew for each project individually. The male technical writers I've known didn't seem to have the same problems.
That sort of thing still happened after I moved on and had different titles and responsibilities as well, but it was the worst with technical writing because there is such a wide range of technical writing jobs.
Most of my experience was in software development and telecommunications, though, so I don't know if that'd apply in your fields.
posted by ernielundquist at 3:59 PM on February 10, 2016 [1 favorite]
Writing software manuals and online help was one of the most boring things I've ever done. A lot of it was very repetitive, filling in boilerplate and having the most tedious arguments you can imagine about style guides and shit. I once wrote a 300-something page manual without using any be verbs (E-Prime) just to stay awake.
But I have also done some ghostwriting type stuff that was more interesting and much less repetitive, writing articles and white papers and things. That could be kind of fun sometimes.
There is a very wide range of types of technical writing, and as a lady working in primarily male dominated fields, I'd have to deal with people assuming my job was much more administrative than it was, which could get pretty miserable sometimes, especially when I was in a position where I was dealing with different clients for each new project and I'd have to deal with it all anew for each project individually. The male technical writers I've known didn't seem to have the same problems.
That sort of thing still happened after I moved on and had different titles and responsibilities as well, but it was the worst with technical writing because there is such a wide range of technical writing jobs.
Most of my experience was in software development and telecommunications, though, so I don't know if that'd apply in your fields.
posted by ernielundquist at 3:59 PM on February 10, 2016 [1 favorite]
For my job I'm pretty much a technical writer, although I never went looking to be a "techincal writer" when I graduated college, and my title isn't "technical writer". I'm an environmental consultant. I applied to private consulting firms once I got my geology undergrad degree and have been doing the work ever since - going on almost 10 years. My day to day work involves writing up environmental reports, and project proposals and summaries, and also editing others work. I also do field work, but a majority of my time is spent sitting around a computer and writing up all the reports. The reports are for regulatory agencies, or my clients and their lawyers. The main pro of this job (and consulting in general) is you generally have flexible hours depending on the company. If I need to leave for a doctors appointment, I can go do that. If I need to leave early, I can do that, and then go work from home because I can literally type up reports from anywhere. The main downside is the billable hours thing. Consultants bill their time, and depending on the company, you are required to remain highly billable, meaning at least 30-40 hours of your time each week is billable to a project. Some companies require 40 billable hours minimum each week. This can often mean working more than 40 hours, because we all end up doing things that you just can't bill. Regarding salary - it depends on what level you get hired in at. Most people I've met in the 0-10 year experience range make somewhere between 40K and like 85K or so. It will also depend on what state you are in too. Feel free to memail me if you have more questions.
posted by FireFountain at 4:07 PM on February 10, 2016 [1 favorite]
posted by FireFountain at 4:07 PM on February 10, 2016 [1 favorite]
I've been a technical writer for 11 years. After college I was hired as a developer at a software company, but I have a second bachelor degree in English. When a technical writer at the company wanted to move to QA, she got in touch with me about replacing her. I've been doing it ever since. Over the years, I've worked for three software companies and two financial institutions that develop a few tools in-house.
I currently work for a very small company, so I do a lot of different things each day. For example: I document new features; fix documentation bugs; improve older documentation that wasn't written well the first time; write release notes and email announcements (and do some JIRA gate-keeping related to releases); make videos explaining products, showing how to use new features, or showing off integrations with other products; edit text that appears in the GUI of products; design and code our documentation website; come up with realistic-looking screenshots for marketing blog posts; and edit lots of one-off documents/emails/blog posts.
Pros: I get to do many different things, not just documentation. I work with people in many different roles and at many different levels of the company. People respect my answers to questions about language. I get lots of thank-yous from consultants and customers who find my work helpful and useful. I've been able to make myself a vital part of the process of releasing new software. People in Marketing come to me first for help with technical topics. Sometimes I'm included in management-level decision-making that, for example, software developers aren't. I know that I'm good at nit-picking details, so I get satisfaction from the editing side of my work.
Cons: It can be hard to get things done when you have to rely heavily on the cooperation of subject matter experts. In past jobs, I've been caught in the middle of ugly fights between Development and Operations. You'll always have customers who would rather open 100 support tickets than read any documentation themselves. Sometimes you'll have to work with people whose job title is "technical writer" but who can barely check their emails. It can be hard to move into a management role, because many companies don't have a big enough tech writing team to manage. I don't have enough time to improve my coding skills.
I make enough money to support two adults (no kids), but it took a fair amount of job-hopping and some pretty aggressive negotiating to get to where I am now. I was underpaid at my first two jobs; management knew it, but were pretty open about it being more important to raise developers' salaries than to raise mine. Now I make more than a few senior developers I know, but again, I attribute that to some gutsy salary negotiations. And I think I'm bumping up against the top of my salary potential in the country where I live.
posted by neushoorn at 10:31 PM on February 10, 2016 [1 favorite]
I currently work for a very small company, so I do a lot of different things each day. For example: I document new features; fix documentation bugs; improve older documentation that wasn't written well the first time; write release notes and email announcements (and do some JIRA gate-keeping related to releases); make videos explaining products, showing how to use new features, or showing off integrations with other products; edit text that appears in the GUI of products; design and code our documentation website; come up with realistic-looking screenshots for marketing blog posts; and edit lots of one-off documents/emails/blog posts.
Pros: I get to do many different things, not just documentation. I work with people in many different roles and at many different levels of the company. People respect my answers to questions about language. I get lots of thank-yous from consultants and customers who find my work helpful and useful. I've been able to make myself a vital part of the process of releasing new software. People in Marketing come to me first for help with technical topics. Sometimes I'm included in management-level decision-making that, for example, software developers aren't. I know that I'm good at nit-picking details, so I get satisfaction from the editing side of my work.
Cons: It can be hard to get things done when you have to rely heavily on the cooperation of subject matter experts. In past jobs, I've been caught in the middle of ugly fights between Development and Operations. You'll always have customers who would rather open 100 support tickets than read any documentation themselves. Sometimes you'll have to work with people whose job title is "technical writer" but who can barely check their emails. It can be hard to move into a management role, because many companies don't have a big enough tech writing team to manage. I don't have enough time to improve my coding skills.
I make enough money to support two adults (no kids), but it took a fair amount of job-hopping and some pretty aggressive negotiating to get to where I am now. I was underpaid at my first two jobs; management knew it, but were pretty open about it being more important to raise developers' salaries than to raise mine. Now I make more than a few senior developers I know, but again, I attribute that to some gutsy salary negotiations. And I think I'm bumping up against the top of my salary potential in the country where I live.
posted by neushoorn at 10:31 PM on February 10, 2016 [1 favorite]
I have specific information on technical writing in Boulder/Denver. MeMail me if you still have questions.
posted by Sheppagus at 6:01 PM on February 11, 2016
posted by Sheppagus at 6:01 PM on February 11, 2016
Coming late to this.
"Technical writing" is a pretty big tent. I love what I do*, but I don't think my job is typical.
I came in with experience as a system administrator and also, separately, as a writer/editor. Most of what I've written over the last decade has been infrastructure installation and configuration manuals for operations staff at national ISPs.
It's a lively, collaborative environment. I'm one of four writers. We're an integral part of the engineering group. We work closely with the PMs and developers. We jump in early, while the products are still evolving, and find ourselves doing a lot of inadvertent product testing. (In fact, one of our writers recently moved into QA because that was what he liked best.) We're respected and paid accordingly.
I agree with kindall above that good technical writing manages "to organize information clearly so users can find what they want, and write succinctly so they don't have to wade through a lot of verbiage to get the knowledge they want."
When we're hiring, the struggle is to find writers who can do just that, and make themselves comfortable with the products, and work well with a wide range of people including PMs and engineers. Tools are a secondary issue. (For what it's worth, though: for our PDF/HTML output we moved away from FrameMaker a couple of years ago. MadCap Flare, as immature and sometimes frustrating as it can be, gives us much more flexibility.)
*To be fair, I was recruited right here at Metafilter.
posted by tangerine at 8:34 PM on February 11, 2016 [1 favorite]
"Technical writing" is a pretty big tent. I love what I do*, but I don't think my job is typical.
I came in with experience as a system administrator and also, separately, as a writer/editor. Most of what I've written over the last decade has been infrastructure installation and configuration manuals for operations staff at national ISPs.
It's a lively, collaborative environment. I'm one of four writers. We're an integral part of the engineering group. We work closely with the PMs and developers. We jump in early, while the products are still evolving, and find ourselves doing a lot of inadvertent product testing. (In fact, one of our writers recently moved into QA because that was what he liked best.) We're respected and paid accordingly.
I agree with kindall above that good technical writing manages "to organize information clearly so users can find what they want, and write succinctly so they don't have to wade through a lot of verbiage to get the knowledge they want."
When we're hiring, the struggle is to find writers who can do just that, and make themselves comfortable with the products, and work well with a wide range of people including PMs and engineers. Tools are a secondary issue. (For what it's worth, though: for our PDF/HTML output we moved away from FrameMaker a couple of years ago. MadCap Flare, as immature and sometimes frustrating as it can be, gives us much more flexibility.)
*To be fair, I was recruited right here at Metafilter.
posted by tangerine at 8:34 PM on February 11, 2016 [1 favorite]
This thread is closed to new comments.
I got into the field sideways, like many of us do. Out of college, I was hired to do technical support for a mail-order computer store that specialized in Apple II products. I had already had some articles published in programming journals while in school. The company started bringing out more of its own products and I was tapped to write documentation for them. Eventually I was the editor of their magazine, wrote much of their marketing material, did all their product documentation (a couple of which were pretty substantial), wrote and co-produced a lot of videos, and managed their online service for schools. When I left there I went freelance. After five years of that I moved to Seattle and worked for a string of tech companies, including a contract at Microsoft.
I have an associate's degree in computer programming, which qualifies me to write COBOL programs for banks and insurance companies. I have never written COBOL programs for a living, not even in 1999. Nobody I have ever worked for has cared about my formal education. They cared about my writing samples and, in some cases, my ability to do some programming, or to write for a developer audience. At my current job I mostly use Python and JavaScript when I code.
My current salary is within spitting distance of six figures. The actual software developers make more, but except for some really senior people, not that much more.
You'll want to know: Adobe FrameMaker and/or InDesign, HTML, XML, DITA. Some ability to automate your processes will be helpful; you can automate Adobe products using a dialect of JavaScript, so that'd be nice to know. Microsoft Word is probably the best tool for collaboration, but it's a crappy tool for actually producing sizable documentation. Much documentation these days is Web-based or otherwise embedded in products and you will generally have a workflow that takes mostly the same content and outputs in multiple formats (e.g. PDF and HTML help). Aside from that, the primary skill you'll need is how to organize information clearly so users can find what they want, and write succinctly so they don't have to wade through a lot of verbiage to get the knowledge they want.
posted by kindall at 12:13 PM on February 10, 2016 [3 favorites]