In his controversial post, The Myth of Single Sourcing, Michael Hiatt explains:

Single-source publishing is a zombie idea that revives itself periodically and refuses to stay dead. Its zombie supporters chant its purported benefits as a “write once, publish to many” promise and ploddingly follow it as their ultimate goal for mechanized authoring and machine translation. As an object-oriented writing methodology, it is as human as present-day robot technology—good only for conveyor belt assembly or specialized tasks, and always very expensive to implement. Single-source publishing lacks purpose in today’s world of information turnover and the dynamic nature of the Web 2.0 moving to Web 3.0 landscape.

In other words, single sourcing your content across the enterprise is an idea that simply doesn’t work. I responded to the post and had a lively exchange in the comments, so I decided to interview Michael for a podcast.

In this podcast I talk with Michael about single sourcing, collaborative authoring, mashups, help authoring trends, and other topics. You can follow Michael’s blog at Mashstream.com.

(Note: We had a brief Skype issue at the start. The audio gets noticeably better at around the 5 minute mark. It’s actually a great example of the clarity that the double-ender recording technique provides instead of just using Skype to record.)

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

1. Technical writing is boring.

Generally True: 7%
Sometimes True, Sometimes False: 46%
Generally False: 47%

2. Technical writing stifles your creativity.

Generally True: 10%
Sometimes True, Sometimes False: 32%
Generally False: 58%

3. You do a lot of writing as a technical writer.

Generally True: 12%
Sometimes True, Sometimes False: 47%
Generally False: 41%

4. You need a job in technical communication to get a job in technical communication.

Generally True: 23%
Sometimes True, Sometimes False: 41%
Generally False: 36%

5. Technical writers are second-class citizens in IT departments.

Generally True: 28%
Sometimes True, Sometimes False: 47%
Generally False: 25%

6. Technical writers feel as if they’ve sold out.

Generally True: 6%
Sometimes True, Sometimes False: 23%
Generally False: 71%

7. You can easily support a family with other writing careers outside of technical writing.

Generally True: 17%
Sometimes True, Sometimes False: 41%
Generally False: 42%

8. You have to know a lot of tools to break into technical communication.

Generally True: 26%
Sometimes True, Sometimes False: 43%
Generally False: 31%

9. Technical writers are introverted, isolated, boring geeks.

Generally True: 7%
Sometimes True, Sometimes False: 38%
Generally False: 55%

10. Because IT technologies change so frequently, you have to spend large amounts of your spare time just keeping up with what’s new.

Generally True: 16%
Sometimes True, Sometimes False: 35%
Generally False: 48%

I’ve listed Ten Technical Writing Stereotypes — tell me if the stereotypes hold generally true for you or not. You can take the survey here: http://www.surveygizmo.com/s/70615/stereotypes. Additionally, you can respond in the comments below this post.

Update: You can view the Survey Results here.

1. Technical writing is boring.

Technical writing is a generally boring activity, involving repetitive, structured writing that requires the same types of sentences over and over (click this, select that, choose this, press that). You spend a good part of your day yawning, editing the same lifeless instructional material while looking out your window and yearning for something more. True or False?

2. Technical writing stifles your creativity.

Because you spend all day immersed in writing instructional text, your own sense of creativity declines. You feel fewer flashes of inspiration and generally have less creative drive and desire. You even find yourself adopting the same techniques of writing short, clear, dry, humorless sentences in your email and journal. True or False?

3. You do a lot of writing as a technical writer.

Although your day is punctuated by a meeting here and there, you spend the majority of your day in writing mode — writing how to use a particular product, or editing what you’ve written. After a full day at work, your fingerpads are often sore from so much typing! True or False?

4. You need a job in technical communication to get a job in technical communication.

Breaking into the field of technical communication is a Catch 22: You need a job in technical communication to get a job in technical communication. Sometimes a degree, certificate, or internship in technical writing can make up for a lack of job experience, but generally breaking into technical communication requires job experience in the same field, making it nearly impossible to get in. True or False?

5. Technical writers are second-class citizens in IT departments.

As a technical writer, you’re generally treated poorly in IT departments — ignored in meetings, put in your place when you speak up, avoided by subject matter experts, excluded from decision-making processes, and sometimes given demeaning secretarial tasks. True or False?

6. Technical writers feel as if they’ve sold out.

You once aspired to write a novel or go into publishing, but due to financial obstacles, you had to embrace technical writing to meet your monthly bills. You often feel as if you’re expending your talents in the wrong direction. You’ve given up on your literary publishing dreams and have resorted to manual-writing as almost your exclusive writing activity. As a writer who once turned heads with your creative prose, you now feel as if you’ve sold out. True or False?

7. You can easily support a family with other writing careers outside of technical writing.

You could pursue a variety of careers in writing to support your family in a comfortable way. Whether working as an editor in a publishing house, a journalist at a newspaper, a staff writer for a magazine, a proofreader for a journal, a writing teacher at a university or high school, you can make enough to be the sole breadwinner of your family. True or False?

8. You have to know a lot of tools to break into technical communication.

To be a competitive applicant for a technical communication job, you need to know a plethora of tools — RoboHelp, Flare, Framemaker, AuthorIt, InDesign, Visio, Dreamweaver, Photoshop, Paint Shop Pro, Camtasia, Captivate, Word, and a handful of others. You also often have to be familiar with various technologies — HTML, XML, DITA, Javascript, CSS, RSS, Java, and C++. The tool/technical knowledge for entry can be formidable. True or False?

9. Technical writers are introverted, isolated, boring geeks.

As a technical writer, you have a generally introverted personality. You keep to yourself most of the day, don’t enjoy large social gatherings, and spend half your day practically mute. You work in your cube or designated area, typing away solemnly at your computer while others interact around you. You tend to have a lot of arcane, geeky knowledge about things no one else cares about. True or False?

10. Because IT technologies change so frequently, you have to spend large amounts of your spare time just keeping up with what’s new.

Your workday ends at 5 p.m., but since the field of IT is moving so quickly, with new sites, applications, and technologies emerging almost daily, you have to spend a good chunk of your spare time at home just keeping up. At times you can feel as if you’re drowning in new knowledge, barely keeping your head above water. You have little time for anything else. True or False?

Note: This article was originally published in the Sept 2008 (Fall) issue of the TechCraft newsletter.

1. The GlueText Myth
2. The Stem Sentences Myth
3. The Front-Matter Page-Numbering Myth
4. The Callouts on Graphics Myth

You’ll have to read the original for the details. The debunking of these myths is supposed to help you embrace a structured authoring methodology like DITA. The myths are genuinely insightful, and it got me thinking about myths in a larger sense.

In part, I’m reflecting on myths because I was recently invited to speak to students at a professional writing conference at BYU Idaho in the fall with the topic, “Three Myths About Technical Writers.”

Apparently, many students pursing English degrees assume technical writers have “sold out.” They think technical writing is a “fallback” career. It’s something you can do if you’re starving and don’t have any other options. Oh, the financial naivete and idealism …

I’m not sure what will convince people immersed in Charles Dickens and Edgar Allen Poe and Chaucer and Emily Dickinson, who are writing about deconstructionism and feminism and the intersection of Shakespearian influences on postmodern authors, etc., that technical writing is more than just “press this button here to program your VCR…”

It will be a challenge, but one worth taking. When I was a student at BYU, I held these same biases against technical writing. I acquired the myths from one presentation by a teacher who represented the English faculty on technical writing. In a nutshell, compared to the other English professors, she was the most boring of any I’ve ever met — by a long shot. She talked about formatting phone books. I whispered a silent vow to myself that I would never, never become like her.  While she spoke of layout and design for banal texts, other professors ignited us with literary ideas.

I now have a personal vow to make technical writing look like one of the most appealing careers one could possibly pursue.

In addition to myths about technical writing as a sellout and fallback career, I can think of at least 10 other commonly held myths surrounding the field of technical communication. I offer them below.

1. Technical writers spend most of their time writing.

Totally untrue. Most tech writers spend about 10% of their time writing. The rest of their time they spend learning applications, noting bugs, providing usability feedback, structuring their content, setting up styles for their help files, troubleshooting their tools, strategizing help deliverables, training new users, formatting and laying out their content, updating existing content, meeting with project team members, and occasionally playing ping pong.

2. You can’t get a job in technical writing unless you have technical writing samples; but you won’t have samples until you have a job in technical writing.

Don’t believe this for an instant. You’re surrounded by technology — your iPod, computer, DVD player, microwave, cell phone, BlackBerry, and everything else. Download a trial version of some help authoring tool, or even just open up Microsoft Word. Write instructions for something. Find an open source application with poor instructions and rewrite them. You don’t have to create an entire user manual. Just give your potential employer some evidence of your capability.

3. A technical writer who has years of experience is more knowledgeable than one with fewer years of experience.

This myth is turning into my pet peeve. How many bios have you seen that begin, “Joe has 15 years of experience …” or “Kate has over 20 years of experience as a technical writer….” Experience means nothing unless learning is taking place. I can go to my same job for 15 years, do the exact same tasks, use the exact same tools, never taking any creative risks or moving into new territory, just doing what I’m told, or what I’ve read, for my entire life. The pace of learning can be compressed into a very short time period, or it can drawn out over a life time. The time (years of experience) does not matter as much as the learning that takes place. (See this related post, MySQL CEO Says, “It is dangerous to hire someone with too much experience.”)

4. The tools you know are more important than your industry knowledge.

Many job ads say you have to know RoboHelp, Photoshop, CSS, HTML, Javascript, C Sharp, InDesign, Dreamweaver, DITA, XML, XHTML, and so on. But really, if you have strong domain knowledge about an industry, that knowledge can be a lot more powerful than a specific tool. For example, if you work in the financial industry, a Series 7 license (which allows you to communicate with investors) is a lot more important than RoboHelp. It can take months of study to get your Series 7, and only a few weeks to pick up a tool. (See this related post, Doug Davis on the Job Side of Technical Writing — Location, Industry Experience, and Salary.”)

5. Be careful about having a blog, because all employers google you and will find it.

When I hear this, I cringe. The discussion always comes up among non-bloggers who think blogs are a wart you need to hide. Sure if you have an embarrassing MySpace page where you mix profanity with vulgarity and other shady content, that’s a site you need to obliterate. But a professional blog demonstrating your knowledge of technical communication can be a powerful tool for getting an edge on other job candidates. It can also serve as a tool for professional development and keep you enthusiastic about your career.

6. Technical writing academics are disconnected with the profession and only have a tenuous idea about the actual practice of technical writing.

Many academics started out as technical writers and worked for years doing the same things we did. Are we practitioners so vain that we think the industry is rapidly changing from year to year, so much so that intelligent people who spend years immersed in texts, studies, journals, and experiments have no idea what our jobs involve? Academics may not be totally fluent with the latest tools, but that doesn’t mean they’re disconnected with technical writing practices and challenges. (See this related post, “Reflections on Allison Reynold’s Talk on Job Skills for the Workplace.”)

7. You can’t have voice or style in technical writing. It has to be objective. And the fewer contractions, the better.

All writing has voice. You don’t have to remove all sense of humanity from your writing. A writer who uses contractions, moves toward conversational style, and truly has voice will provide a better experience for the frustrated user who seeks human help rather than cold robotic formalese. The talk that changed me forever was this keynote by Kathy Sierra at SXSW, where she explains the need for human qualities in help material when users, in desperate frustration, finally click the help button. If you want to sound like a robot, eliminate all contractions from your writing. What tone do you think users respond better to?

8. Technical writers aren’t allowed to contact users directly. They should get their information through the product manager, customer support, and marketing.

Here we see yet another wrong idea that will only put up roadblocks for worthwhile help. Joe Sokohl clarified this principle at Doc Train West 2008, calling it the Kobayashi Maru principle (a reference from Star Trek). He says you have to throw aside the idea that you can’t contact users. Without this contact and the information you can gather from users, you’re hopelessly doomed to write instructional material they don’t want.

9. You can single source your material into all the formats your audience needs, if you just learn the right tool or technology.

When you learn to structure your content with DITA, you can magically transform all your content into every format your users need. NOT. The type of instructions you write for a one page quick reference guide varies from the kind of style you need for an iPhone or for a long manual. While I agree that you can single source online help to a software manual, the idea gets taken too far. (See this related post by Gordon McLean, “DITA Is Not the Answer.”)

10. You have to be quite tech-savvy to be a good technical writer.

Actually, when you become so tech savvy that you can’t imagine users not understanding how to disable a popup blocker or not knowing how to do a simple task, when you are stunned at users who double-click when they should single-click, or who single-click when they should double-click, at this point, you lose some ability to write for the lowest common denominator. It’s not such a bad thing if you’re technically challenged. So are most of your users! You’ll be on a level playing field and will probably write a help manual that actually speaks their language. (See this related post, “The Curse of Knowledge — The More You Know, the Worse You Become at Communicating that Knowledge.”)