Angst and authority
Clay Shirky has a fascinating post on the concept of algorithmic authority; the idea that large systems, such as Google PageRank or Wikipedia have authority (that is, credibility) because of the way that the system works. In other words, a page that is returned first in a Google search is assumed by the searcher to be more credible because it is ranked first.
That made me think about authority in technical content.
As an in-house technical writer, your words have authority and your content carries the corporate logo. But although this should theoretically increase your credibility, it seems that the reverse is true. Consider, for instance, the following hypothetical book titles:
- XYZ User’s Guide—This document, produced by the makers of XYZ, is shipped in the product box (or downloaded as a PDF with the software)
- XYZ Classroom in a Book—This document is available in bookstores and is produced by XYZ Press
- XYZ: The Complete Reference*—This document is available in bookstores and is produced by a third-party publisher
Which of these books would you turn to for help? What are your expectations of each document?
I believe that credibility and thus authority increases with distance from the product’s maker. In other words, the third-party book has more authority than either of the other two. Credibility is compromised by close association with the organization that makes the product.
When we apply this concept to information on the web, the implications are troubling for professional content creators who work inside corporations. If corporate authorship decreases authority, we get this result:
online help < user forums on corporate site < user forums on third-party site
Will people looking for user assistance gravitate toward independent third-party sites? What does that mean for in-house authors? How can you increase your credibility as a corporate technical communicator?
* Feel free to substitute your favorite book series title: XYZ for Dummies, XYZ: The Missing Manual, The Complete Idiot’s Guide to XYZ, XYZ Annoyances, …. I should probably also mention that I have written both a Dummies book and a Complete Reference.
About the author
Larry Kunz
You’re on to something, Sarah. As you point out, the Dummies book increasingly is regarded as having more authority than the company-produced manual.
Yet if I wanted to look up the product’s technical specifications — speeds and feeds, data that’s not open to interpretation or shades of gray — I think I’d still trust the manual. The writer who works for the company is more likely to know that stuff, and to cover it more thoroughly, than the writer of the Dummies book.
So when do I go to the Dummies book? When I want to use the product to do an actual task. I think that’s because I feel a greater affinity with the Dummies writer. He or she understands my world and thinks like me. Perhaps adding to that, I think, is the stereotype of the technical writer: introverted, a bit of a propellerhead, and definitely not thinking like me.
Now that we have tools like wikis and customer-feedback loops, I (as a user) sense an ever expanding community of people who think like me. The company writer is pushed ever closer to the edge of irrelevance. I haven’t really thought about what that means to us and our profession, but it’s intriguing.
Paul K. Sholar
I can’t agree with your idea for several reasons. Credibility as to technical information is based on its mundane correctness and its applicability to my needs. The writer for the creator of the product has little excuse *not* to produce product documentation that is both comprehensive and correct at the mundane level (that is, the product’s specific behaviors). Where the in-house writer can be at a disadvantage relative to a third-party writer is when the former is not allowed by the employer to become a true expert in using the product. That would mean that the in-house writer develops a strong facility at applying the tool for all/most of the specific uses that fall within the product’s intended area of applicability. The in-house writer might have an advantage over the third-party writer in having access to proprietary information about the design of the product and, with that knowledge in hand, being able to readily identify both the most compelling usage scenarios and the product’s key features that productively exploit that scenario.
But the in-house writer probably has other products to document and in most cases does not have the time develop the same degree of expertise in applying the product to real-world usage scenarios that a third-party writer can.
So I’m saying that “credibility” in technical communication lies both in describing the tool’s features correctly and in detail but also in demonstrating a representative sample of realistic usage scenarios to which the product can be fruitfully applied.
mike
Not sure I buy the initial premise, but do believe that organizations can lose authority by being perceived as lazy, arrogant, full of it, or even incompetent. As in: “These guys are too clever to work at my level, too far up themselves to know what I want, provide endless cr*p, and can’t meet a specification to save their lives”.
Also, laudible decisions can have unintended consequences. For example, if an organization ‘elects to eat its own dogfood’ and then discovers that none of its tools are remotely suitable for genererating end-user collateral of the quality required, it can create a whole third-party cottage industry without really trying.
Let’s imagine you work for, or consult to, a really-clever-but-mostly-insufferable organization of the kind described. Do you run? Or is there a stategy that has some chance?
Sarah O'Keefe
@Larry: Yes, I agree that for specs and other factual information, the corporate version should win. Very good point.
@Paul: I don’t think I’m arguing that the in-house writer lacks expertise, although it could be another interesting facet of the problem. My argument is that the in-house writer may not be permitted to apply that expertise because the organization’s agenda (sell stuff and make money) is not always compatible with producing excellent documentation. If the organization can get away with bad doc and still make money, then why bother?
@mike: Running sounds appealing. Let’s assume that running away is not an option, or at least not immediately. I would probably look into automating as much as possible WITHOUT TELLING ANYONE. Thus, if management “knows” that producing a document takes 40 hours, but you can do it in 20 because of the automation you secretly introduced, you gain some additional hours to do a better job.
mike
Good, but ‘better job’ probably translates to thankless labor. How about using the time to subvert the third-party effort by, for example, beginning to curate the ‘conversation’? If Corporate Marketing are already on the case then you KNOW it’s time to run! [Compare and contrast each group’s audience, and relationship to that audience].