The only significant innovation for tech comm
When I surfaced the topic of innovation on my blog (in the first post in this series), some people noted that the only really noteworthy innovation to affect technical communication in the past 20 years is the web.
Mark Baker, author of Every Page Is Page One, made one of the most insightful comments. He said that it's a myth to think that the only technical communication that takes place on the web involves professional technical communicators. Every time someone writes a blog post or other article that explains how to do some task, the person is acting as a technical writer.
The disruptive innovation of the web, he says, is that rather than limiting technical communication to a group of privileged insiders who disseminate official product information for their company, the information is now largely being written by the masses, pushed out as little articles of knowledge (rather than entire books), and surfacing in google search results regardless of the person's authority. Search results are determined by content relevance, popularity of inbound links, and other depersonalized algorithms.
...the basic strategy of information finding has changed from first find an authority, then ask your question, to first ask you question, then determine the authority of the answer. Or to put it yet another way: Google first; manual maybe never. Those of us who speak for authority have thus had our place in the tech comm world violently disrupted.
Mark says our status as technical writers is a lowered, since the web enables everyone to be a technical writer. People searching for information don't care who the information comes from, as long as the content answers their question. Mark says the biggest impact of the web on the discipline of tech comm is that technical writers have been displaced (not necessarily replaced -- just as TV didn't replace radio -- but our status and roles have changed).
Mark adds that where possible, technical writers' jobs will involve seeding products with information to get user communities going, to get users helping each other and providing answers/documentation.
Assessing the impact
I think most of us would agree that the web has made everyone a technical writer to some degree. If you've ever tried to build a website, you've undoubtedly searched for answers on google and found information from all walks of people, few of which might be professional writers.
On the other hand, I'm still employed as a technical writer with plenty of projects and work. Keith Schengili-Roberts, who writes a blog called ditawriter.com, even notes that technical writing jobs are on the rise (slightly) in the U.S.. It's not as if you can simply launch a product and expect eager customers to provide all the needed documentation.
So how can the web be so disruptive, yet it has not disrupted me enough to displace my job as a technical writer?
I'd say there are several possibilities:
- The amount of tech that needs documenting is spiraling upward at a rate no one can keep pace with. The only reason there isn't a dramatic spike in the number of technical writing jobs is precisely because there are so many people documenting things for free on the web. Their contributions offset the need, keeping tech writing jobs at a modest rather than exponential curve upward.
- The type of documentation people contribute on the web is incomplete. The posts are often half-intelligible, out of date, inaccurate, and not nearly comprehensive enough to work as product documentation. The hits from people in blogs and forums cover little questions here and there, but if you force people to find information this way, like tracing a pinball bouncing off maze walls, you will drive users crazy. In this sense, documentation on the web is only complementary to official product documentation, not something that replaces it entirely.
- Most of the contributions online relate to general platforms (e.g., Ruby), not to specific, niche products (e.g., how to install specialized financial software used by a small group of analysts). The ad-hoc tech writer phenomenon only happens for products of such high interest that the community levels are massive enough to have someone (like 1 in 500?) creating documentation.
- Much of the documentation that needs to be written isn't on the open web. It's behind firewalls, or locked behind proprietary paywalls. Paid technical writers are often the only resources for getting this documentation written.
- Many products are so poorly designed, it requires an insider to explain the product to the users. Users will not likely figure the product out on their own (unless they are extremely patient), and companies don't want misinformation being generated about their product (not to mention frustrated, angry users who had to puzzle something out).
Still, the disruption is incontrovertible
However much I may quibble or question the disruption, Mark is right -- the web has dramatically transformed the way technical content is written. My favorite example is StackOverflow, which is nearly the equivalent of Wikipedia in scope (but with a much different approach) for technical documentation.
A designer-programmer person explained StackOverflow's model as follows: You search for the answer on Google. If you don't find it, you ask it on StackOverflow so that the next person who searches for it finds the answer.
Here's an example where I (as a professional technical writer) ask a question and get an answer (documentation) from someone in Germany who isn't a technical writer.
Question by question, answer by answer, vote by vote -- StackOverflow has become an indispensable resource for people doing technical tasks on the web (particularly for programmers and designers).
And who is writing all of this helpful documentation? Not professional technical writers, who are busy constructing tables of content in long PDF user guides. Instead, techies drawn to the game of answering questions (and being challenged) are the de facto technical writers providing the most value online.
About Tom Johnson
I'm a technical writer / API doc specialist based in the Seattle area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out simplifying complexity and API documentation for some deep dives into these topics. If you're a technical writer and want to keep on top of the latest trends in the field, be sure to subscribe to email updates. You can also learn more about me or contact me.