I came across a commentary from Alan Pringle on a discussion regarding style guides and whether their value, and the value of those who adhere to them, is dated. Alan’s commentary piqued my interest of course and I found myself witness to an epic discussion between notable content strategists and technical communicators. The discussion began with a simple question regarding style guide use and eventually encompassed the very nature of the value of technical writers within organizations.
I chose to post my response here instead of in the comments section of the original discussion because at over 900 words, I didn’t want to seem as though I was offering the last word.
There seems to be a lot of talk lately regarding technology, tools, and how technical communicators will fit into this as I found in Ugur Akinci’s blog post today as well. I thought that all four of these posts, including mine, offer a well-rounded perspective on this topic. I recommend reading them in this order:
- 5 Things That Will Never Change Despite Technological Changes in Technical Writing
- The latest style for tech comm: adding value
- What does a style guide do? What should a style guide do?
- Article Comment: I’m on team technical writer
Let me start by identifying my position: I disagree with Scott; I mostly agree with Julio; I sympathize with Larry; Alan Pringle makes some good points; Ugur is on the right track; and I like where Mark is going.
Paying editors to enforce style guide rules is a huge waste of time and money. It’s time organizations automate enforcement.
I couldn’t quite see what was wrong with this maxim but as I continued reading, I found it. The organizations that are in the position to automate enforcement are, according to the post, IBM and “three of the top ten technology firms, and two of the top software firms…” I think that keeping this in mind really puts this conversation into perspective.
The scope of my network is limited; however, I do know a fellow technical communication student who also works for IBM in the usability lab. That’s great, you say, but what does that have to do with operational efficiencies? Well, that it would be great to visit the usability lab someday—maybe I can arrange for all of my fellow technical communication friends to take a field trip. You see, that is as close to a usability lab that we’ll ever come. The same is true for most of the content strategy that is talked about lately and specifically (in this case) to “automating terminology.” The problem is that it’s just not realistic.
IBM is number 18 on the list of 2011 Fortune 500 companies. Why is this distinction important to note? Because the following list is a much larger one: How many small businesses are there? There are over 26 million small businesses (less than 500 employees) in the United States. Frankly, if you walked into any of these businesses with this idea, you would be laughed out of the office. Will it cost more than $10, take more than 10 minutes to implement, and require more than 1 person to train (part of the original $10 and 10 minutes)? For instance, I just had to fill out a 6 page form and submit a written justification to receive approval for the $12 fee to attend an STC workshop next week on TCS3 (approval pending; keep your fingers crossed!).
Implementing such a strategy within small businesses that employ 1-? technical writers isn’t a luxury that small businesses can afford.
I echo Larry’s question regarding how to implement enforcement across all of technical communication and wonder if the melding of commercialism/technology (e.g., the tool that remains unnamed) and STC’s new certification program will have some slippery slope technical communication standard mandated by a newly formed technical communication board. Who will create the style guidelines and terminology rules? Are we just replacing the traditional style guidelines with new ones?
I’d love to hear reasons why having computer programs help us enforce rules, become more efficient, and therefore, more productive and less prone to errors and inconsistencies is a BAD thing, sans robots as writers, of course.
I am all for new technology but the practical, real-world side of me must file this idea in the “theory” category of my brain until such a time that the technology is available. We have to look at the real-world costs (of course) as well as the harder-to-determine ROI that content, and content writers, provide. Even if the tool is IBM’s Watson, we’ll be losing the innovation and creativity that a technical writer contributes because AI such as Watson’s is still unable to create the initial rules and to know when to break them. If it were possible, wouldn’t we just be trading a human style guide for a robot style guide? I suppose that the operational efficiencies will come from the lower cost of maintaining the robot?
There are many tools that exist within Knowledge Management Systems that are at the technical writer’s disposal such as content templates and tokens for commonly used terminology . The difference between these and automating terminology altogether is that the former are employed by the writer as needed/required and the latter is imposed on the writer. However, as it’s true for all technology, each organization has to decide what level of automation and control is right for them.
From an operations standpoint, there are always two things to consider; that is, two things that should be weighed in every decision—effectiveness (quality) and efficiency (productivity). If the quality of existing work is not in question, then productivity must be the issue. So what’s the problem in the technical writing industry?
This is a great discussion and I look forward to reading and discussing it further. I look forward to your poking holes in my position so we can get to the crux of this topic and how it will affect all technical communicators.