Social Enterprise

Five tips for becoming a tech writer

If you've been reading tech books and articles for years and thinking, 'I could write stuff like this,' you may be right. Veteran author Katherine Murray shares a few tricks of the tech-writing trade.

Ah, the glamorous life of the tech author. Get the first glimpse of new software shimmering on the horizon. Hobnob with high-profile bloggers. Attend great industry conferences -- and bring home lots of swag. If you have a knack for technology, or a specific area of technology, and can write about it in a clear, no-nonsense fashion (or even with a little nonsense that your readers will enjoy), there may be a place for you in tech publishing. Here are a few tips to get you started making the rounds.

1: Write about what fascinates you (or at least what you know)

I think the best things to write about (and the most fun) are topics within the area that fascinates you so much that you want to spend as much time as possible -- whether you get paid for it or not -- learning about the technology. If you're obsessed with developing custom tools for SharePoint, writing how-to's about Joomla, or programming in some arcane language most of us have never heard of, that's a good place to start. The second-best gig -- and still a good way to build your writing credits -- is to write about what you know. Are you the one everyone comes to when they have trouble with Excel macros? Are you the one who always figures out mail merge problems? If you have a knack or a specialty, chances are there are people out there who need what you can do.

2: Start where you are

This is a great time to be a tech writer because there is so much technology to cover in so many different channels. When I first started out as a tech writer (think IBM PC XT), I wrote content for books. There were three or four magazines around at the time, but books were really the focus. Today, you've got blogs, sites like TechRepublic, discussion boards, wikis, intranets, online learning modules, the Web, magazines galore, and -- oh yes, books. Add podcasts and Webcasts to the mix, along with PowerPoint presentations and ebooks, and you've got just about as many outlets for your work as you can dream up.

When you're first starting out, look around your own backyard. Start a blog. Take a look at the sites you visit often. Leave comments on their posts. Pitch them an idea you have about a new slant on an existing application. Solve a problem for them. Once you get a "yes" or two from an editor, you're on your way to making a go of it. But be prepared to do some work up-front for less-than-pizza money, and start building your writing experience. Over time, that can turn into something editors are looking for, because they can see your track record and know they can rely on you.

3: Use your real voice

There are all sorts of tech writers in this space enjoying varying levels of success. And they have all kinds of voices. Some are snarky; some are funny; some drone on and on (but for some strange reason we like them anyway). Some solve our problems; some encourage us to dream up new things to do with our software. Most are teachers in one form or another. Often, new writers try to sound like someone they admire who has been successful. Sometimes that works, but mostly it doesn't. Why? Because your voice really is important when you're expressing your own thoughts. Imagine your reader as a friend you'd like to help with a technical problem. Explain a direct route to the solution. Keep it friendly. Be yourself. That being said, though, especially in the tech realm, make sure you're offering something readers can really use. Cute and funny won't go far if there's nothing of substance in your writing.

4: Ask, ask, ask

Whether it's through blogging, serving as a technical editor on a project, or volunteering to write an IT article for your company newsletter, building some publishing experience does give you something to show editors. However, it's not the be-all, end-all for getting published. Regardless of how much writing experience you have, if you think of a piece you'd like to write for a specific publication, ask the editor if they'd be interested. Resist the temptation to believe that editors hold the key to some kind of golden domain that very few writers get entrance to. In fact, it's almost the opposite. Editors need your content. If you have a good idea and can show that you have the enthusiasm and expertise they need, you might get a green light on your piece. In some realms, editors might ask you to write something on spec (short for speculation, which means they won't promise to pay you until they see the finished article and know whether they want it), but that's not a bad way to break in. Your foot is in the door, and with any luck (and good writing), you'll have a credit you can show other editors when you're pitching more ideas.

5: Build up to a book

The last few years have been dragging us toward a new day in publishing. Electronic publishing is no longer a "someday" kind of thing. The Kindle, the Nook, and other eReaders on all kinds of devices make it easy to purchase and download content -- forget the paper products -- right now.

The question What will happen to books? has been on every savvy publisher's mind for a good long while, and the jury is still out. Electronic content is mushrooming; book publishing is getting smarter.

There's still a market for your book. I think there will always be a market for a good book. But you'll need to choose your topic well. (Is this an idea that can't be presented easier and cheaper electronically?) Do your homework. (Know your competition, your audience, and your market.). Build a relationship with your publisher. (I think the best books are collaborative efforts). And be prepared to support the marketing of your book with workshops, podcasts, Webinars, and more. While you're putting together that amazingly detailed proposal, remember to daydream about (and make a list of) all the articles, blog posts, discussions, and videos you can create along the way.

Happy writing!

Additional resources

About

Katherine Murray is a technology writer and the author of more than 60 books on a variety of topics, ranging from small business technology to green computing to blogging to Microsoft Office 2010. Her most recent books include Microsoft Office 2010 P...

7 comments
bagby
bagby

This was disappointing on the "getting paid" front. I already know how to write well enough that people on discussion boards tell me I should write books about things I explain to them. What I don't have the first idea about, and this article doesn't cover, is how to begin translating that into money. I don't *know* any editors. I don't know how to find any or how to submit work to them. THAT would have been useful. Writing technical documentation well, is a different thing. Most people, including most who have the job title "tech writer" are dreadful at it, and produce the sort of useless documentation that accompanies most production software -- nowadays, most "help" files. The manual or file just blithely repeats what was already self-evident on the screen and goes not one step farther. (And if you're Microsoft, uses made-up names for things, instead of the existing ones.) People get paid for that??? If your problem is even a little bit out of the ordinary, or indeed is anything that isn't really self-evident, the documentation probably won't help you at all, and you'll be reduced to googling for answers to your problem. Most of the documentation won't even suggest helpful web sites to you. I find it nearly useless as anything but a reference AFTER I already know what it contains, and that it's much faster to figure out how to use the software on my own. "Manual? I don't need no stinkin' manual!" It goes on the shelf and it stays on the shelf until product EOL. Company style is epitomized by the extremely helpful, grievously false adjuration, "This Page Intentionally Left Blank". Great, you've started out by transparently lying to me. I can see this relationship is going to go well. To the extent that the term has an accepted meaning, it's one that needs to change.

Roc Riz
Roc Riz

Change your name to "Euripides Upmann," because that's what people will do with it, if it is not simple, interesting, to the point, with little bits of humor, and personal stories sprinkled in. Just my eleventy three cents.

ben.lagueux
ben.lagueux

in the IT industry. It would be no less absurd for Ms. Murray to state that someone who leisurely peruses the world wide web to see what serendipity presents them, is a "web browser." I may be overly-sensitive to word usage, but it strikes me as disingenuine for any writer to repurpose a mature term with a well-known definition - unless the intended affect is conflict with preconceived notions, as in parody or sarcasm. To me, and most of the TechRepublic audience, "tech writer" is short for "technical writer," a professional document producer whose skills include command of formal American English, formatting documents for usability, at least journeyman level use of electronic content development tools such as the Adobe Creative Suite, and perhaps a flair for graphic presentation of information. Conversely, what is offered in the article are tips for becoming a freelance author of IT content.

SirWizard
SirWizard

My eyes went immediately to two Os, too. And the critical comment titled Techncial (sic) Proofreading? Beyond those, this puff piece suffers from an incorrect title, which should have been, "Five tips for becoming a blogger." Far too many illiterate bozos crowd the field of technical writing, burying hiring or contracting companies with swarms of resumes, thus diminishing the visibility of actual tech writers. Hobnobbing with high-profile bloggers?! That's not what technical writing is about. It's more about getting the first glimpse of a steaming heap of half-digested software squatting on the horizon, and then detailing its interface and functionality so that while presenting no insult to the sensibilities of geniuses, any oaf could comprehend it. So, here are a few tips of my own for would-be tech writers: 0. (Zero-based indexing suits the situation.) Determine if you have a knack for formal language and quality writing. Are you really good with grammar, vocabulary, spelling, and proofreading? If so--great, because native talent helps a lot. If not, either abandon the idea of technical writing as gainful employment, or start becoming good through intensive study and education. 1. Do you like to use your real voice and include some fun and nonsense? Forget about it. That's fine for creative writing or unpaid techie guidance, but good documentation requires a consistent tone and formatting that matches The Company's templates, existing documentation, and style guide. Start reading a style manual: the Chicago Manual of Style, Strunk and White, U.S. Government, or the Microsoft Manual of Style. 2. Become very skillful with at least one word processing program, be it Word, InDesign, FrameMaker, or--well, there really aren't many others involved in paying work. Become conversant with styles: paragraph, font, numbering, and so on, and how they cascade. 3. Practice writing (especially instructive material), give it to nitpicking editors and grammarians, and learn from what they say.

cyndi
cyndi

Shouldn't this be 'to' below? Appropriate that this typo occured under ask, ask, ask. Resist the temptation to believe that editors hold the key to some kind of golden domain that very few writers get entrance too.

SirWizard
SirWizard

I've edited documents that other so-called Tech Writers have written. Some of them are indeed dreadful. I used excerpts from one document to create a brief guide showing examples in ten different categories of bad tech writing. Bad writers flood the market and dilute the opportunities for the ones who do create useful manuals. I've been struggling to get work for the past couple years. Fortunately, I'm working at present. I've gotten great feedback from the folks who use my manuals, and they're happy to have them. But I work hard at making manuals that are clear and helpful. And truthful. Do you know why there's often a message on an otherwise blank page? (You probably do, bagby.) It shows that the document isn't misprinted. But, I refuse to use a self-falsifying blank-page message. My end-of-chapter pages state the truthful, "This page concludes [Chapter Name]," suitably formatted. This only helps for printed manuals, which many organizations (especially those who really don't care about their end users) think are passe. Aren't electronic versions just as good, if not better? No! The adjacent pages of a printed manual are seen easily, often to good effect, while adjacent e-pages are rarely visible. It's really hard to thumb through e-pages to scan for other related useful information. Finally, my end users of recent years spend a lot of time behind equipment racks, and they love having a real paper manual while trying to connect or replace complicated hardware. E-books just don't hold a candle (or a Kindle) to paper documentation for much of the real world.

donald.yost
donald.yost

Did you perhaps mean "disingenuous"? :-)