Communications from DMN

You're Not Just a "Technical Writer" - January 8, 2007

	This is Communications from DMN for for the week of January 8, 2007.
Aaron	I'm Aaron Davis.
Scott	And I'm Scott Nesbitt. Thanks for joining us.
Aaron	If you tuned into last week's podcast you'll remember that we spent a lot of time discussing the changing role of the technical communicator. This week, we'll be taking that a little further and look at other roles that technical communicators can play within an organization. Scott, why don't you start us off?
Scott	Thanks, Aaron. In some ways, being a technical communicator is like being an actor: it's easy for you to get typecast. But instead of always playing a heavy or the best friend, you're generally viewed as someone who creates manuals and help files. And nothing more. Many of us can write, and write more than just documentation. We can do many of these tasks very well. Unfortunately, in many cases this flexibility is overlooked or blatantly ignored. A good technical communicator is an asset to any development organization. By tapping the abilities and potential that most technical communicators possess, organizations can add considerable value to their products and services.
Aaron	And that value can be quantified -- increased sales, fewer support calls, greater customer satisfaction, are just a few examples. What other roles can a technical communicator play within an organization? You may be surprised. Here's a list of a few of the jobs that a good technical communicator can tackle: Policies and procedures. There's no reason why you can't adapt your technical writing experience to producing these kinds of documents. The principles are similar to those for developing manuals. Presentation scripts. Even if you're not much of a speaker, you undoubtedly know enough about rhetoric and narrative structure to write at least the outline of a presentation. Training materials. In many ways, your documentation is teaching people. Why not go one step further and help build training materials? If you have a flair for narrative, you can combine that with your skills at writing procedures to create effective tutorials. Case studies and white papers. If you have a background or training in journalism, then these documents are right up your alley. Case studies and white papers tell a true story -- for example, how a customer saved money using your firm's products or services. Web site content. Just about every company has a Web site these days. There's no reason why you can't contribute content to it.
Scott	That's a great list, Aaron. And it only breaks the surface. At the risk of sounding vain, I'll offer DMN Communications up as a prime example of how technical communicators with strong writing abilities can fill numerous roles and produce various types of writing. In addition to documentation, we've written articles, reports, and white papers; developed how-to and tutorial content; and maintained knowledge bases and support documents. We've even written marketing collateral. We've been able to do this not simply because we can write. Aaron and I have created or seized opportunities that we've noticed or which been presented to us. Our flexibility gave us the confidence to tackle each of those assignments. Our technical and product knowledge, along with our writing skills, enabled us to author accurate documents that had punch. We've explained what you can do. The question now is "how can I move into those areas?"
Aaron	That's a good question. For better or for worse, you're going to need buy-in from management. And that can be difficult. It's important to remember that technical communicators inhabit a unique niche within an organization. We straddle the worlds of the developer and the user. We know the products, but we also understand what users want, as well as their frustrations when using a product. Your product knowledge, along with an affinity for users (whether current or potential), should be your main selling point when approaching management. Of course, your writing ability will be another major selling point. If you have examples of the types of writing you'd like to do -- whether from your current job or from a previous one -- show them to management as part of your pitch.
Scott	Sort of like a magazine writer presenting published clips to an editor. That's a good strategy.
Aaron	It definitely is. But don't go in there with the attitude that you're the authority on writing and that no one else in the organization has a clue. In most cases, that's not only a false assumption but you're bound to offend more than one person. Your work will undoubtedly be open to greater scrutiny and all it will take is one mistake for your sojourn outside the land of documentation to come to a quick end. You need to be careful, as well, of stepping on other peoples' toes. It's human nature to be territorial -- imagine how you'd feel if someone from the finance department jumped in and started writing your online help content. You'll have to reassure people that you're not trying to replace them. Instead, play up your expertise and convince them that by working together, you're making your company's offerings more appealing. I've said this time and again: demonstrate that you're adding value to the organization. If you can, put a dollar value on it for maximum impact.
Scott	That said, it's harder to make the kinds of transitions that we've mentioned in a large organization. Some positions, technical writing in particular, are quite ossified in the overall hierarchy. There's less chance of the kind of cross pollination between the documentation team and other departments. In smaller organizations, where your one of a handful writers (or even the sole writer), then it's easier. You're bound to be a writer of all documents. People will come to you either for help with what they're writing or to write something for them. What happens, though, if you're a contractor?
Aaron	That's a tough one. A contractor is never really around long enough to be able to tackle multiple assignments within an organization. On the other hand, the flexibility of the freelancer can be a major advantage. For one thing, in your off project time you have the opportunity to do other writing. Other writing? What a concept! For example, you could write articles -- both how-to and narrative. You could write reports. You could blog in the field of your expertise, whether it's telecom, banking, biotech, or whatever it may be. Blogging is a great way to increase your exposure and become recognized as an expert in your field. You could develop software tutorials aimed at other technical communicators or just the average person. Take this one step further and try to write a book. If you can't get a contract with a publisher -- a daunting task for most writers -- then turn your idea into an eBook and sell it online. Any of these can not only position you as an expert, but they can open doors for you in other areas. When Scott started in the business 11 years ago, he got one of his first tech writing jobs on the strength of several articles he wrote for computer publications.
Scott	Thanks for reminding me of my age, Aaron ... Now it's time for our Pick of the Week. Each week we choose a book, Web site, or blog that we find interesting and useful and hope that you will, too. This week's pick ties directly into the topic of this podcast. It's the book Writing White Papers by Michael Stelzner.
Aaron	We bought Writing White Papers shortly after it came out, and it did not disappoint. This book, more than any other that we've read, really explains the art of writing white papers. And make no mistake, it is an art. Stelzner, who's no slouch in this area (having written over 100 white papers) starts out by explaining what white papers are and why they're important. Then, he walks you through the entire process of writing a white paper from creating the needs assessment to outlining to doing interviews and research. But it's Stelzner's description of the white paper writing process that really impressed both Scott and myself. He spends a considerable number of pages discussing writing the first page of the white paper and creating a compelling title. These are what pull the reader in and, as Stelzner says, can make or break the document. If the first page or title don't grab readers, then they're not going to go any further.
Scott	That said, Stelzner's chapters (eight through 10) on writing and formatting a white paper are really what make the book. I found myself writing notes after reading each page. Stelzner packs the book with information on finding the right market driver, framing a problem that the white paper will solve, and how to develop the "benefits" section of a white paper. Stelzner really makes writing white papers look easy. It's not, of course, but the book can definitely help you improve your white paper authoring skills. It's definitely worth the $25 price tag of the eBook edition; $34.95 for the hardcover version.
Aaron	You can learn more about this great book at www.writingwhitepapers.com/book. That's all we have for this edition of Communications from DMN. Join us next week when we discuss the pros and cons of Open Source tools for technical writing.
	Thanks for listening. If you have any questions, comments, or suggestions for future podcasts drop us a line at podcast@dmncommunications.com. And don't forget to visit our Web site (www.dmncommunications.com) and our blog (www.dmncommunications.com/weblog). Have a good week.