John from Delaware, who has a job in technical support, asked my advice about whether he should become a technical writer. He expressed some concern about the field, explaining that since almost everyone can write, the skill of technical writing must be decreasing in value. For example, technical writing can be easily outsourced. In an economy of doing more with less, is it really a good idea to base your career in a skill that is increasingly done by others who are not technical writers?
A graphical representation of John's question might look like this:
Even though an engineer may be able to write well, there's a lot of supporting tasks one must do prior to writing so that the content will be worthwhile. It's not just composing a graceful e-mail and clicking send. You have to metaphorically build a foundation and erect the walls before you can finally put the roof (the writing) on.
To be more specific, Shanghai Tech Writer says she spends just 10% of her time actually writing. This disproportion surprises most people. If only 10% of your time is taken up with writing, what happens to the other 90%? Your other time is consumed with the following:
Sometime during all of this, you actually get a few minutes to write the help text.
It takes 90% of your time to do all of these other tasks. These tasks are necessary for your writing to be relevant, accurate, attractive, organized, and so on. For example, unless you know your help authoring tool and company style and how the application is supposed to work, you can't write intelligently about it. Unless someone has time to do an extra job -- namely all the tasks in the bullets listed above -- most likely he or she won't be writing help content that approximates the quality of your own.
You may find someone willing to pitch in 10% of his or her time to do some technical writing, but not someone willing and able to complete the other 90% while also doing his or her regular job. Technical writing is a time commitment that takes nearly all your time to do it well.
Beyond time, though, explaining some technical concepts does require above-average literary skill. If the product you're documenting is complicated (for example, if you're trying to explain how a storage array functions for a non-engineer), it will require exceptional writing skills to communicate it clearly.
Not everyone possesses these skills, and the majority of writing from engineers I've seen reinforces this point. Being clear can require you to supplement your explanations with visual diagrams; it requires you to simplify your sentences, dumb-down your vocabulary, and spin the topic so it makes sense from the reader's point of view. Few people have the skill and patience for this.
Finally, many non-technical writers doing technical writing have illusions about the standards for help. The technical writing profession has been black-eyed by all the less-than-literate developers attempting to write help, which then appears to lower the standard for help content overall. User manuals have an incontrovertibly infamous reputation for sucking. As such, it shouldn't come as much surprise to find engineers or interns who feel confident they can at least match, if not do better than, the last user manual they read.
Reversing that assumption is nearly possible. Even half-way decent manuals still fail. Overall, help just needs to be better -- it needs to be more user friendly, more accurate, more relevant, and more convenient. It needs to be context-sensitive, full of visual illustrations, broken down into simple steps, accompanied by video tutorials, and more. If help were at the standard it should be, you wouldn't find so many people convinced that they can create help content.
To conclude, don't let the idea that “anyone can write help” deter you from the profession. Almost no one has time to write help while fulfilling his or her regular responsibilities. If people do have time, they often lack the talent to communicate clearly. And if they feel they have talent, show them an example of good help (rather than their VCR manual), and let them compare.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.