The business of technical communication
By default, managers and executives see technical communication as a cost center, similar to a QA department or a Human Resources group.
“Necessary evil” is not where you want to be for great career success.
You want to be “indispensable.” And you want to be indispensable in ways that are financially compelling. For example, you might:
- Introduce minimalism principles, which reduce the total amount of content and therefore localization expenses by 20 percent.
- Reduce the amount of time that content creators spend on formatting by improving templates and therefore formatting automation, thus saving the organization hundreds of hours per product release.
- Find a workaround for [some nasty technical problem], which cut document production time from 5 days to 3 hours.
- Use search engine optimization techniques to improve your content’s Google results, increasing page views and therefore visibility of your content. (For bonus points, show a correlation between increased web site traffic and reduced technical support calls.)
By now, you’ve probably noticed that “write great content” isn’t on my list. This is because of the following factors:
- The hackneyed “anyone can write” makes it difficult to sell “I’m a great writer.”
- Most technical communication doesn’t require great writing. It requires “good enough” writing.
- In many organizations, management is either incapable of differentiating between good and bad writing, or simply does not see the value of better writing. (See: “necessary evil”)
For technical communicators and consultants, these are the implications. You must:
- Demonstrate sufficient competence as a writer to get hired. In most cases, an adequate writer who produces content quickly will be preferred over a great writer who works more slowly.
- Produce content that conforms to established style guidelines, templates, and other corporate standards. (Clean content is more valuable than messy content.)
- Look for ways to improve productivity and drive down the cost of supporting content development.
- Develop innovative new ways to create and deliver content, such as increased community participation.
To succeed, technical communicators need to focus more on the process of efficient technical communication and less on the art of writing.
About the author
Kristy Lantz Astry
I still find that employers are focusing on tools rather than ability (“Do you know the XYZ CMS? If not, we’re not going to hire you”). I list the tools I use in a sidebar on my resume, so that my res will get hits, but I don’t emphasize the tools. Instead, I focus on how I can relieve the employers’ pain points by creating useful and usable content that meets their audiences’ needs.
Larry Kunz
Yes! Or to put it another way: Technical communicators need to focus more on what’s good for business and less on the art of writing.
Marijana
I’d like to add: “To succed technical communicators must not forget to produce helpful content in their efficient tech comm process.”
I totally agree that a tech communicator needs to know how to produce content in an efficient way. But just as Kristy said there is a big tendency to focus on tools and processes much more than on the actual end result. A tech communicator who knows DITA tags can still produce un-useful content -> he might be a efficient writer but he’s definitely a bad help producer.
Ben M
It’s hard to convince the world that not everyone can right, but even if we could, you’ve hit on an important point when you say that “good enough” is good enough for most companies.
Some articles have been published online recently that talk about how tech comm deliverables can actually help profits. I don’t know if it’s enough to say that we’ve managed to cut the costs of our own products by 20% because management may still say, “You cost us money.” Saving support costs helps some, and if you work for a nonprofit org like I do then saving money in any way is great; but if in commercial areas we can show a correlation between providing docs and training (and good content in general) and increased profits, then we become a money maker instead of a money drainer. That’s something we can wave in front of executives’ noses that will catch their attention.
Vishnu
“Develop innovative new ways to create and deliver content, such as increased community participation.”
This does not apply to products that require some kind of confidentiality such as financial products. I do not understand what the author means by “community participation”. If it is social media, then I would says it is not a substitite for “well-written” user documentation. A user manual can aid in selling a product and it is written for the “customer” and not for the management, which cannot differentiate between bad and good writing.
In technical writing, there is no need for a “good” versus “great” writing. Good technical writing will be great if it serves the purpose of the user. Measuring technical communication with sales and support costs saved is plain ridiculous.
Rachel
Great points! I think you’re also hitting on another important point – make yourself valuable to the team. Providing templates is one way to help team members, but also things like setting up guides to help others take more efficient meeting notes or to run a meeting more efficiently; jumping in when QA needs help; working with the ux team on usability testing or reviewing their designs; etc. I’ve done all of these things at previous jobs, and it’s helped me become more than “just the writer.”
Michael Müller-Hillebrand
Sarah, you hit the spot, again. I’ll recommend your post in my blog tomorrow.
Ben M
I disagree with Vishu’s “plain ridiculous” judgment. In my version of a perfect world, business executives and project managers would see the inherent necessity and benefits of technical communication as it helps users reach their goals, and maybe then it would in fact be ridiculous to talk about sales. However, the execs and managers think in terms of profits, costs, and savings, so it’s to our benefit to be able to speak to them in the terms they understand.
I do agree that community participation probably doesn’t apply in situations where the docs are sensitive or confidential. However, community participation was only an example. Thinking of new and better ways to create and deliver content in general applies in all tech comm situations, I think.
Sarah O'Keefe
Wow, lots of great comments.
@Kristy: When hiring, I either want the right tools or proof that you can learn the tools, especially for a short-term contract. I think your sidebar list approach is the perfect way to address this—you’re saying to potential employers, “Yes, I know this tool — or lots of related ones — so let’s move on and talk about something more interesting.”
@Larry: To quote Orson Welles…I would have made it shorter if I had more time.
@Marijana: I am hoping that once we reach some sort of plateau with tools, we can turn our attention back to content creation issues. I am, however, not holding my breath.
@Ben: I agree, but I think just showing efficiency is a step in the right direction.
@Vishnu: Actually, there’s community participation in some pretty unusual places. For example, the US intelligence community has something called Intellipedia. I haven’t seen it (for obvious reasons), but there is an example where the community is not “the general public.” You may not feel that content written by non-writers can substitute for “well-written user documentation,” but that is in fact exactly what is happening in a lot of places. I am suggesting that technical communicators need to develop much better skills in understanding how their content fits into the overall corporate strategy.
Paul K. Sholar
I don’t totally buy this argument. It is an argument spouted by management and by those who wish to add further (sometimes forced) automation inside an organization. Is online help an optional component of software products? If not, then why are the writers of help not seen as producers of the product, just as software developers? Is documentation of a complex product an optional component of the delivered product? Not so for many customers: read a software license contract. If documentation is not optional, then why would management see technical writers as merely a cost center? Until software products (and many other kinds of products) are so intelligent as to no longer need documentation and text-based user assistance, then the technical writing task is part of the cost of producing products, just like other product developers on the team.
Paul K. Sholar
Edit: … spouted by those in management focused primarily on cost-cutting …
Vishnu
I agree with Paul.
Sarah, I am not against “community participation”. I repeat that this community participation is not possible everywhere. Just because it “…is happening in a lot of places…” does not mean it is effective, worthwhile, and profitable. If you have come across studies that point in this direction, please share.
When companies can stretch development and testing budgets and tolerate bad practices or non-adherence to coding and testing guidelines and inefficient implementation, why should “documentation” strive hard to convince the management, who, in most cases, do not understand what documentation is? Do you think that we are in a career that requires us to convince or struggle throughout our careers to make the management understand our value and skills? Isn’t that pathetic? What a career!
Jim Collins
Well, actually Vishnu, I’m afraid that the answer to this many times is “yes” IMO.
Whether we like it or not, management at most companies does view technical communication as an expense, not something that adds to the company’s bottom line. I think Sarah’s article does a great job of pointing out areas where technical communicators can improve their performance to help combat (but never totally eliminate, I’m afraid) this viewpoint.
I say this not based on my own “vast” experience (I’ve only been officially working as a technical communicator for about 6 years now – 3 as an employee and 3 as an independent contractor), but based more on all the other articles and discussions I’ve heard within the STC community.
For Paul, I totally agree that management should realize that since a complex product cannot be sold without the necessary technical documentation, it becomes a necessary part of the package and, therefore, a profit maker. However, I’m afraid this is not the case with the majority of companies. They just don’t think that way. Part of it may be that only a very small number of people determine which particular brand product they will buy based on the quality of its documentation. The product’s capabilities, bells & whistles, and appearance are all more important for most consumers.
FWIW, I think one reason so many hiring folks look first at what tools we know is because they view that knowledge as essential to “efficiency” and, therefore, your having a particular tool skill will cost them less money than if you need to spend a “lot” (a very vague term that even they use) of time to come up to speed. It’s also a much easier metric to track and evaluate than the very subjective “how well you write.” And, let’s face it, a whole lot of hiring managers have absolutely no idea what a technical communicator does anyway, so counting tools becomes an easy for them to evaluate people. Now that may be overly simplistic in some ways and certainly I believe they consider the other things, but if they already believe that “anyone can write,” looking at the tools becomes a bigger factor.
Jim Collins
Sorry, my first sentence is in response to Vishnu saying “Do you think that we are in a career that requires us to convince or struggle throughout our careers to make the management understand our value and skills?”
Vishnu
I feel the issue is with corporate thinking, which views “writing” as a soft skill (inferior skill) and not as an essential skill. Management seems to be a bit apprehensive about “writers”. Writers are seen as rebellious souls, as seen in creative writing or journalism. Coding is everything, and others are outcasts.
Corporate culture wants a sort of “confirmatory” behaviour to which other groups such as developers and testers are ready to succumb to. The publishing industry, for example, has a better understanding of what their employees do, so the efforts of resources are much appreciated. Software industry does not seem to understand the roles of the “content” team, and it is their drawback.
The reason why tools are asked is the hiring team employ the same recruiting standards to tech writers, as they do for developers and testers.
Craig
Part of the “problem” may be that there is one way, or a few ways, to write code to solve a business problem. There are, however, many ways to describe how an interface functions. Some employers may be afraid that writers are frustrated artists who are trying to write the Great American Novel in their user manuals. I may write a sentence one way on Monday, and another way on Tuesday. That said, I also worked in newspapers, where you publish or perish, do or die. I learned to write it, do the best I can at that moment, and kick it out the door. I make sure I mention that to people. People don’t want great writing. People want the writing DONE.
Vishnu
Timeless Skills for Technical Writers
http://newsletter.stc-carolina.org/tiki-index.php?page=Timeless+Skills+for+Technical+Writers