A Writer’s Salary: Technical Writing Careers

Name: Anonymous
Job Title: Technical Writer, Information Architect
Where: Syracuse, NY
Years of Experience: 10+
Other Relevant Experience: Program Director, AMI-NYS; Communications Coordinator, Rural Housing Coalition; Multimedia Designer, RPI; Technical Support, Berkshire Online; Volunteer work: designing, writing, laying out newsletters, brochures, and web pages; Organizing and managing information for distribution to external sources
Education: BA in English, Chapman Univ.; BA in Psychology, Chapman University; MS in Communication and Rhetoric, RPI; Graphics certificate, RPI; Human Factors training, RPI; Training courses in Java, DB design and management
Annual Salary: Use PayScale's Research Center to find the best technical writing fields for high technical writing salaries. 

In the current job market, those interested in professional writing have a wide range of career options to explore. Writing continues to become a more and more specialized trade, in correlation with rapid technological advances and the increased demands of varying industries. Not only does this advancement mean more jobs for writers, but increased specialization can also mean higher salaries. If you're searching for the highest paying writer's salary, technical writing careers are a good place to start. 

Our tour guide for this Salary Story is a professional technical writer with over 10 years of experience in the field. You'll get a detailed, first-hand explanation of technical writing as our guide describes several examples of technical writing assignments. After reading this inside look at a technical writing career, find out how technical writing salaries compare to the salary range for grant writer jobs and copy writer salaries.

Technical Writer Job Description:

Technical writers are assigned particular pieces of technology or specific products to document. The first step of any project is to review all specifications and any existing documentation for the assigned technologies or products. You then install the products or work with them to become familiar with the product as a customer is expected to do. I walk through everything that the user is apt to do with the software, even if it hasn't been documented. If something is possible, users will do it, even if it's not the intended use of the technology/product. I also take time to observe users, talk with usability testers, software developers, and other writers in order to assess user needs.

I then create an outline for the product documentation and gather feedback from editors, architects, marketing, and software engineers. It's best to identify potential problems in the documentation before you start writing it. Combining my outline and any feedback I receive, I then write a first draft of the documentation and submit that for feedback as well. As I’m submitting documentation drafts for review, I’m also testing the documentation against the most current build of the software and resolving any problems that arise. I also try to identify any usability issues with the interface or software design and communicate those back to the developers. About a week before the due date for a project, I’ll put out one final approval draft for review. This draft is reviewed only by key people (development team lead, marketing lead, lead architect, lead writers as appropriate). The review lasts two days and should not bring about any non-essential changes.

Depending on your role in the team and how your company structures its information development departments, you may also be responsible for some infrastructure tasks like building and testing plug-ins for information centers. More and more, technical writers are not just the secretarial arm of software development. We are actively involved in product development, internal tool development, and basically driving changes to products and procedures based on usability, efficiency, and cost. So, as a technical writer you will likely encounter a multitude of various projects, including writing business proposals, advocating for changes to internal tools and external products, writing and driving the implementation of specifications, working directly with human factors, development, marketing, and customers to drive product and documentation changes that will improve sales and usability, while keeping costs down.

PayScale: How did you get started as a technical writer?

I was working in the non-profit sector doing a lot of writing on various specialized subjects and supporting a small network, but I wasn't getting paid very well. I heard about tech writing from a friend who was going to RPI. Technical writing requires all of the skills that I'm good at: troubleshooting, thinking on your feet, learning complicated subjects quickly, writing about complicated subjects for targeted audiences, working with cutting edge technology without a lot of hand holding, and strong writing and communication skills – and it pays very well! So I applied to RPI, got in, and worked my way through the program doing jobs that provided me with relevant experience.

PayScale: What do you like best about being a technical writer?

I love that I get to help people. For example, I was assigned a tutorial that was badly broken and not very well organized. I reorganized it and fixed the inaccuracies. A few months after it was released to customers, I received a personal note from a person in upper management, congratulating me on redesigning the tutorial. Apparently, a big customer was very pleased that they now had a usable and useful tutorial they could hand out to their employees. It saved them (and us) a lot of money in training costs. I also love the direct impact that I can have on a product. For example, I participated in the design of a brand new product and received a patent for my work. I also helped redesign an installer so that I could do away with over sixty pages of documentation, because now the user could just follow the prompts in the installer instead of having to read pages and pages of documentation.

I love finding more efficient ways to document products and technologies so that writers can spend more time working on usability issues and less time duplicating work. For example, I engineered a migration from SGML produced topics (which is very labor intensive and prone to duplication) to DITA which is much more appropriate for documentation that has to be updated and reshipped frequently. It took me a couple of years to convince management and it was a massive undertaking (tens of thousands of topics and over 100 writers and translators to be trained) of over three years, but the result was worth it. We can now support individual technologies and deliver appropriate documentation in a matter of minutes, instead of weeks. The approach is now spreading across the company.

PayScale: What are the biggest challenges you face as a technical writer?

Convincing other people to do the right thing in spite of schedules. For example, when faced with developers who think a thirteen screen wizard is a good thing, it can be a challenge to convince them that it's actually worth the extra effort in the long run to design something easier to use. Another challenge can be in convincing other writers that doing something a certain way will be more work up front, but less work down the line. In other words, the big challenge is getting others to see the big picture.

PayScale: What advice would you give to those wanting to become a technical writer?

Get as much technical knowledge and training as you can. Take the time to learn how to write user-oriented documentation. It really does require specialized knowledge to write good documentation. Not just anyone can do it well. The ideal writer will have strong technical skills, combined with strong writing and communication skills. Be a go-getter. Don't wait for projects and learning opportunities to come your way – seek them out, ask for them, identify a problem and propose a solution, then follow through. Challenge yourself to learn new skills constantly, and protect your integrity and credibility at all costs. Don't lie if you forget to include something in your documentation or if you make a mistake. Take responsibility for the accuracy and quality of your work. Help others if you can do so without endangering your own deliverables. Be sure of what you are saying before you open your mouth. Writers do not get second chances if they convey inaccurate information or say something stupid. If you make a little effort to learn the technology, you won’t ask incredibly obvious questions or inaccurately identify bugs. Once your credibility is gone, your career is over. Engineers expect us to be a pain, because we're expected to be ignorant. It's up to us to prove otherwise.

PayScale: What's the most exciting or crazy thing about being a technical writer?

Migrating a team from several different source formats to a single format is probably the craziest thing I've ever had to do. It’s nerve racking for sure. When you're leading, success belongs to the people that you lead, but failure is yours. I had to deal with resistance to change, training large numbers of people without disrupting the production process, ensuring that nothing was lost in the process, ensuring that our changes meshed perfectly with every context in which our documentation is conveyed, revamping our infrastructure tools and process, ensuring that the architecture and infrastructure were completely compatible and that infrastructure decisions were driven by architectural needs.

I also had to do the pilot project that this change was based on. I had to convince a vice president of marketing that it was worth the time and effort for development to create an installer for a stand-alone information center. Development was very resistant, so I had to do some design work for them, including write a spec, have the spec reviewed and approved, and write some code. I checked in constantly to ensure that the work was being done, troubleshot any problems that they ran into, taught the writers how to create their documentation in a new way, built and tested the information center, and worked with translation to ensure that issues with the translated documentation were fixed (corrupted files, broken links, etc.). Both projects brought about major changes across the company.