Tech & Work

Job snapshot: Technical writer

For people who are good with words and readily grasp technical processes, the job of technical writer is tailor-made. Two professional technical writers describe their experience.

This is another installment of a series within the Career Management blog in which I feature a short survey of a tech pro in a particular specialty. It's not a comprehensive look, just a snapshot of what the person likes best and likes least about his or her chosen profession. I'm hoping it will give a little anecdotal direction to those of you who are just starting out in IT or are looking to change direction. (If anyone wants to talk about their job for the benefit of our readers, feel free to answer the three questions below and email them to toni.bowers@cbs.com)

See also:

This week we have two installments from technical writers. First, we'll hear from David Wandelt who currently works as a Senior Systems Integration Engineer (and functional technical writer) for news and information distribution service provider PR Newswire. He has had several positions with the actual title of Technical Writer, but most have been some variation on programmer, system architect, or engineer. What do you like best about your job?

The knowledge that I'm empowering someone else to get their job done. Most consumers of the fruits of my labor will never know or see me, but I know they're out there, and appreciate the care I take to communicate clearly the information they need.

If we're honest with ourselves (and been in IT long enough), we've all been there: It's after hours, and you'd rather be home with your family. But you just can't get a handle on one nagging thing that's preventing a delivery, and the boss is breathing down your neck. The delivery is tomorrow, and heads will roll if it's missed! You're desperate. Desperate times demand desperate measures. Breaking out in a sweat, you go to your tool of last resort: The Manual!

Quickly checking the index, you find the function you were searching for, but then your eye lights upon another phrase across the page, et voilà! You have a breakthrough, because the documentation writer thought to include your particular scenario in the index. The delivery is made, you get to go home, and your status as the go-to guy is cemented. Okay, so maybe that's a little dramatic, but like I said, if you have been in the business long enough, it's played out for you. And yes, when I'm writing, I imagine some put-upon guy like me just trying to do his job the right way. And for me, knowing that I'm providing the information to make that happen is very satisfying.

Other positive aspects of the work include the exposure (some work products are seen at very high levels in the company), and variety — user or system documentation is only the beginning. I've worked with legal departments on contract language, marketing departments on lay-oriented descriptions of technical topics, written white papers evaluating competing vendors' technical solutions to various problems, and lots more.

Oh, yes. And a chance to actually be paid to learn! I love to learn new things, whether it's how traffic is routed through the world's largest, devilishly complex packet-switched network (think modern-day Ma Bell), or cutting edge user interface design paradigms. In my 35+ year career, I've had many such opportunities.

What do you dislike most about your job?

Of course there are some aspects of the work that can be unpleasant and/or discouraging. Not unlike testers in a company that creates a technical product, the documenters tend to get caught in the end-of-cycle crush. The product may or may not have had a specification, but usually the actual delivered feature set is at least a little bit different from what was specified. And because documentation is not normally its primary product, some companies tend to view it as a necessary evil, or an accessory they must provide just to keep customers from complaining too much. Even though those who have to use, program or administer the system must have it, it's valuable; you know it is. But too often, those in a position to support it see it as a non-essential waste of their time. And trying to produce it without support can be frustrating indeed. For similar reasons, in such cases the documentation group (if you aren't working alone as a one-man-band) tends to get shuffled around a lot within the organization, because no one really wants it.

Like many jobs, you have to get your satisfaction from knowing you've done the best job you could, given all imposed constraints, and move on — when you are able to do so without acquiring a bad name as a deserter. This is especially important if you do a lot of consulting work, since a bad name in that business can easily translate into extended "beach time". And sometimes you can stay on an assignment for years, and still be treated like Benedict Arnold when you finally do leave.

What education/background prepared you for your job?

My primary qualification has always been my insatiable curiosity about how things work, and my love of clearly and concisely communicating what I've learned, to those who are interested. When I was a freshman in high school, in the early 70's before personal computers had been conceived, I taught myself BASIC (didn't have their required prerequisites to get into a programming class) by booking time on the school's only teletype, by which we could dial in to a minicomputer at a nearby college. The math department actually had me teach a class on it, without ever having taken the class myself!

After leaving engineering school without a degree, I got a job repairing mechanical relay-based pinball machines. That led to the next job, testing, and repairing military power supplies. After that, building and testing TTL- and microprocessor-based intelligent word-processing computer terminals, including building engineering prototypes. Eventually I worked on the SCADA system used to distribute electric power in New York City, programming it in machine language; wrote a 4GL-based database system to maintain their shift scheduling; wrote the requirements for a database of equipment testing results. On and on it went, company-to-company, and in virtually every position, I also became the logical person to write the documentation. At last count, this job is my 28th.

35 years later, sure, I have gone back and taken quite a few college classes in both technical and non-technical disciplines, and a few professional certificates in areas like system architecture and project management, but never have taken the time to put it all together into a degree. Too busy! But by now enough people know me that I seldom have time to take a break between jobs.

Overall, I love what I do, and wouldn't change it. At least not until I retire. Then—who knows? Maybe I'll set up an herbalism practice!

———————————————————————

And, from Bruce Poropat: What do you like best about your job?

I enjoy assembling detached bits of information into a cohesive document that tells a story to a particular audience. I've been lucky enough to work with some employers and clients who get why good documentation is important and provide the environment and resources to support it. I also like the variety of media available to modern technical communication. In a single project I might produce print documents, work with HTML and CSS in a Wiki, create technical diagrams and illustrations, and make a slide deck with tasteful animation.

What do you dislike about your job?

Lately, most tech writer jobs are contract positions, and not even directly, but through agencies that take excessively large cuts and provide no benefits. Plus, even when companies know poor documentation costs them big bucks, many hire technical writers last and let them go first.

Other companies don't value good documentation enough to create a climate that facilitates its production. I worked on a contract for a large financial institution where there was no source material for the document I was supposed to produce, and I couldn't get access to the subject matter experts. Additionally, no two people agreed on exactly what the document should cover. I had replaced another tech writer who gave up after a week. I lasted two weeks, but it wasn't fun. Gleaning source material from extremely busy people is always an organizational and diplomatic challenge, but that was an extreme case.

What education/background qualified you for your job?

In my early career, I fell backwards in to one job after another, and was good at most of them. As time went by, the jobs became more technical until, suddenly, I was an electrical engineer. I probably should have stayed an engineer, but thought I'd be good at technical sales—which turned out to be the one job I really stank at. In most of these jobs, I was the person in the office who understood sentence structure and the difference between a comma and a semicolon, so I did a lot of writing and editing.

When I decided to be a technical writer full time, I enrolled in UC Berkeley Extension's technical communications certificate program. With a bit of arrogance, I thought I didn't have much to learn, but the certificate would make my resume look more normal. However, I soon learned that technical communication involves a rich and highly evolved set of methods and skills. The UC classes were great, covering writing style, information architecture, usability, localization, writing project management, and many other topics. I got my first tech writing job while still in the program.

Get the PDF version of this post here.

About Toni Bowers

Toni Bowers is Managing Editor of TechRepublic and is the award-winning blogger of the Career Management blog. She has edited newsletters, books, and web sites pertaining to software, IT career, and IT management issues.

Editor's Picks

Free Newsletters, In your Inbox