Tech Writing, Just for the Fun of It

In going through reader emails, two questions never fail to surprise me: 1) what is Bill Gates really like? and 2) how does one become a tech writer?
First answer: how should I know?
Second answer: how should I know?

My only meeting with Mr. Gates was a thing of chance, very brief, and well documented in a previous column. Some people seem to think that, if you work at Microsoft, you automatically know everyone else at Microsoft. All 50,000 plus. Well, after almost four years on the job, I really only know a couple dozen people. I know Bill Gates about as well as I know Michelle Pfeiffer, which, sorry to say, is not at all.

I don’t know how you can become a tech writer either, because I just kind of fell into it myself. The reason this question surprises me is because there are so many interesting and exciting professions out there, I don’t know why anyone would ever choose to become a tech writer. Of the seven people on my team at Microsoft, none of us wanted to be a tech writer. We all set out to write novels, or news stories, or software – pretty much anything besides technical manuals. (And there’s one guy who always wanted to open a pizza place, but he’s living on another planet anyway.) The odd thing at Microsoft is that the real test of your writing skills comes not in the daily grind of typing up step-by-step procedures. The real test comes when you have to write your annual progress review, because that’s when you have to explain in 500 words or less why you’re so excited and passionate about technical writing. Now that’s a trial.

For those of you who think you want to enter this field, my hope is that this column will serve as a literary Taser gun to shock you back into clear thinking. [But I’m warning you right now: this is dull stuff. In fact, as far as I’m concerned, you can stop reading right now and still get credit for the whole article.]

While the tools and forms of technical documentation have changed quite a lot over the years, the actual writing is as mundane as it ever was. There is only one best way to install a piece of software, or create a user account, or add a channel ID to a gateway. My job is to document that best way in as few words as possible.

When I started in this business, everything I wrote ended up in a printed manual that shipped in the software box. I remember about twelve years ago at WordPerfect when one of the VPs was discussing the total dollar cost of everything that went into the shrinkwrapped box, including the shrinkwrap. We sold WordPerfect for about $200 and the total cost of goods was about $20. Not a bad profit. But here’s the kicker: the WordPerfect printed manual made up $14 of that $20. That explained the VP’s mandate for us to write shorter manuals, and the subsequent bulldozer push toward putting the whole manual on a disk. When 900 percent profit isn’t enough, you know you’re in the right industry.

So all the big companies started putting manuals on floppies, then on CDs, and now the delivery method of choice is the Web. The ability to deliver software manuals (or, “docs”) on the Web has taken the technical writing world by storm. Tech writers the world over are singing its praises. The way they carry on, you’d have thought someone had discovered a way to flash the docs in the night sky like the Bat signal. At technical writing conventions (Sweet Moses! I can’t even type that without yawning), every session seems to discuss docs on the Web. It’s good for the software maker, good for the author, and good for the customer, they say. And it’s hard to argue. The company gets off cheap. As a writer, I no longer have to allow for an extra month for the manuals to be printed and bound, or even burned to disk, so there’s less of a chance that I’ll be staying late at the office to meet a deadline. And the consumer gets to enjoy continuous publishing, which just means that your manuals are always up to date.

Docs on the Web. That’s technical writing these days. If you spent a day in my office, you’d hear more conversations about authoring tools, conversion techniques, and markup languages than you would about actual software concepts and procedures. But at the end of the day, not much has changed, really. I still have to deliver docs that help customers understand and use the software. Just like when I started doing this back in the 1980s.

There. I hope I’ve done some good by saving you from a life of instructing users to “make sure you click this before you click that.” Please heed my advice. Maintain your sanity. Turn back. The bridge is out.
And, remember, a well-run Pizza Hut franchise can turn a profit inside of fifteen months.


  1. Ken, I enjoyed reading your style. I agree that writing manuals can be somewhat boring. But what about expanding into other related territories, such as video tutorials, quick reference material, illustrations, web 2.0 formats, and so on? There’s also the design of an online help skin and help site.


Speak Your Mind