What is a Technical Writer (my job, and how I do it)

I work as a technical writer. What does that mean?

For any of you budding writers seeking a sustainable career, or for those who are curious, I figured I’d share what I do as a full-time technical writer.

Quick background: I was studying Chemistry and English (Creative Writing) in college, and I had no idea what I wanted to do after graduation. I knew I wanted to write books and publish them, but I didn’t want to pin my life and limb on it. Assistant Chemist at one of the state’s chemical plants? Freelance writer? Publishing house internship? Internship somewhere? I had no clue.

What I knew was what I liked doing in class.

Signs I Should Have Recognized

  • Whenever a classmate asked me to read their essay, I tore it apart. Line edits, syntax, grammar, organization, argument, flaws in logic. I loved it.
  • Whenever I read a classmates story/poem, I tore it apart. Detailed notes, descriptive and in depth write-up and analysis.
  • Even if I only received a couple notes in return, I rode around with my red pen scepter.
  • Commas are, and always have been, fun.
  • I payed attention when we talked about grammar and syntax back in high school.
  • I had a meticulous eye for detail when doing chemistry lab reports and memos and observations (if not the neatest handwriting).
  • I read some of my chem textbooks and lab procedures and thought, “Meh, I could have written this clearer/better.”

To me, these were just parts of my personality. I didn’t think that they would apply to a career, necessarily. Sure, an eye for detail would make me better at whatever job I chose. But when I finally perused the job possibilities, I felt instantly connected to technical writing. Not only did it list things I was good at, but things I enjoyed. My interests became my strengths.

What it is I Actually Do

I take manuals written by engineers over the past three decades, and I rewrite them, reformat them, and fix them up. I also create job aids (helpful instructions) on everything from using Adobe Reader to managing a SharePoint workflow.

Writing (Re-writing, in this case)

This means I spend a lot of time reading things that I don’t understand. Welding? Shrug.

Even if you don’t understand the content, you still know when it doesn’t make sense. If there are thirty steps in a process, and two of them say the same thing but neither of them make sense, it’s time to fix it up. If the entire thing is written in passive voice with “shalls” all over the place, cringe and fix it.

SMEs

Because I don’t know the content, I spend a lot of time consulting with SMEs (Subject Matter Experts). I get to chat with lovely engineers and explain what does and doesn’t make sense. I ask silly questions like “is this word really supposed to be butt-weld?” I consult them while I rearrange sentences so the subject and object is clear.

Other Writers

I spend just as much time working with any other technical writers who are working alongside me. We need to have one common language. One common style and format so that the finished manual fits together as if one person did it.

Designers

I also communicate with the folks who design and layout the manuals in their shiny new format (aka: not typewriter style from 1985). The more I understand about the process, the more I can help provide a product that the end-user will enjoy (end-user = the people actually using the final product). How are we organizing sections, chapters, and books? We’re including hyperlinks? What sort of language and style do we use (not click here)?

Proofreading

Then, proofreading. Cue three-thousand printed pages of manuals my red pen, highlighters, and sticky notes. Make sure every sentence has the proper punctuation, the correct terminology, that headers and links are formatted the same. I had to fight my boss (and by me, I mean my supervisor) in order to allow the proofing stage. He didn’t think it was necessary, that having two writers and an SME work on it should guarantee it was free of faults. He was wrong (as bosses often can be). Proofing is critical. And no matter how many times you do it, or how careful you are, there will still be mistakes.

This brings up an interesting point though, that not everyone sees the importance of proofreading or technical writing in general. If you’re a technical writer, most people you meet will think you are doing a secretary’s job. Poor, poor souls. They are wrong.  So very wrong.

Revisions

Further along in the process, I started working with the revisions. I make changes to the manuals requested by end-users while maintaining style, formatting, and clarity. Sometimes I have to contact them and say, what exactly is it you want changed?

For instance, I once got a request that stated “typo.” That’s it. Nothing to tell me or anyone else where the typo was or what it was. And I wasn’t about to read an entire chapter or manual searching for a misspelling. So I emailed and asked, and it turns out it was a numerical typo that I NEVER would have found on my own. People want to be helpful. They just don’t always know how.

Supplemental Work

Because I’m part of a goal-oriented team, my job slowly expanded to include a lot of other things that weren’t in the original job description. At my discretion, most of the time. I created a tracking system for our team to standardize linking.

  • I manage part of our business site and track a lot of data in excel. Part of this comes from my exposure and ability with excel and data while studying chemistry. A lot of it involves Google and tech forums.
  • I’ve gone around the state training employees on how to use the manuals, and I’ve learned a lot about the company and its technology and people.
  • I learned enough HTML/CSS to create basic webpages and sift through data to find what I’m looking for.
  • I’ve attended training sessions to learn more about SharePoint management, design, and structure.
  • I’m making really cool forms integrated with the SharePoint site, which is a combo of excel-type data and aesthetics, plus a healthy dose of end-user instruction.
  • I’ve gleaned the basics of various programs I didn’t previously understand very well, such as Adobe InDesign, Illustator, DC, and Reader.

Let’s Add a Conclusion

All of this is to say that being a technical writer, depending on where and with whom you work, can be a very broad and basic job description. It involves a lot of writing, attention to detail, strong knowledge of English language (that grammar and syntax stuff I mentioned earlier), and a bit of solid initiative.

Please ask me questions if you have any! If you want to know more specifics about how I work or what I do, I’ll do my best to answer. If you’re a college student wondering about World After Graduation, hopefully I can help ease your mind.

What about you? Are you an aspiring writer? Fully emerged in a career already? Buoyantly bobbing across the surface of adulthood?

Advertisements

One thought on “What is a Technical Writer (my job, and how I do it)

  1. Pingback: Other Humans | words — and other things

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s