Part VIII: Conclusion
<div class="btn-group"> <button type="button" data-toggle="dropdown" class="btn btn-warning dropdown-toggle">Value arguments for docs and tech comm<span class="caret"></span></button> <ol class="dropdown-menu"> <li> <a href="/2017/12/28/value-of-tech-comm-in-company-part1/">1 </a> </li> <li> <a href="/2017/12/28/value-of-tech-comm-in-company-part2/">2 </a> </li> <li> <a href="/2017/12/28/value-of-tech-comm-in-company-part3/">3 </a> </li> <li> <a href="/2017/12/28/value-of-tech-comm-in-company-part4/">4 </a> </li> <li> <a href="/2017/12/28/value-of-tech-comm-in-company-part5/">5 </a> </li> <li> <a href="/2017/12/28/value-of-tech-comm-in-company-part6/">6 </a> </li> <li class="active">→ </li> </ol> </div>
This essay started out as one post and expanded into seven because I kept searching for what I felt was the right answer. In the end, establishing value doesn’t mean selecting one direction and ignoring the others. All of these directions are complementary and help you increase the value of documentation. Increasing information flow and looking at all content across the customer experience are essential activities to creating documentation that simplifies complexity. You can’t write the kind of genius-level documentation around complex topics that has tremendous value if you operate solely within the boundaries of your own head and context. You have to interact widely with these other groups to gather and evaluate user pain points and needed information. As such, these “extra-curricular” interactions are prerequisites, not options.
Writing this essay helped me evaluate an idea I was struggling against. The idea was this: Technical writers should act as mere facilitators of the writing and publishing process, providing the tools for others in the organization to write and publish technical content. They might review the content to ensure it meets basic standards, but the burden of content development lies with each project team, not the technical writers.
Such an idea severely shortchanges the knowledge value that technical writers can and should play. It perpetuates a secretarial status to technical writers and will lead to a devaluation of our role, not to mention a lowering of the knowledge assets of the company. Writing this essay helped me value the important knowledge contributions that technical writers make and see my effort in the proper light.
Action items and takeaways
Readers will form their own conclusions and takeaways, but because I started this essay by saying I needed to reconcile the value question for myself, I’ll also end it with my own list of takeaways. I have five main takeaways:
- Tech writers provide high corporate value by creating knowledge assets, not by merely editing or publishing information that engineers write. As such, our primary focus should be knowledge creation.
- Tech writers must focus on the complexities (pain points) users face — we can understand these complexities only by interacting with groups across the organization (such as Field Engineering, Support, and Marketing).
- Documentation is an area through which many organizational groups intersect; as such, technical writers can play a pivotal role in improving the entire customer experience. Many groups rely on the knowledge assets we create for their jobs.
- Tech writers should promote their knowledge assets across organizational lines by enabling information flow and by bringing the right people together for conversations. These interactions will also help inform us about needs in the documentation.
- Measuring our value through metrics is impractical and ill-advised; it is better to gather word-of-mouth perceptions of our value from groups that use our documentation.
Carliner, Saul; Qayyum, Adnan; Sanchez-Lozano, Juan Carlos. “What Measures of Productivity and Effectiveness Do Technical Communication Managers Track and Report?” Technical Communication, Volume 61, Number 3, August 2014.
Hoffman, Ari. “Announcing 2017’s TOP 25 Content Experience Influencers and TOP 200 Strategists.” MindTouch.
Hughes, Mike. “Moving from Information Transfer to Knowledge Creation: A New Value Proposition for Technical Communicators.” Technical Communication, Volume 49, Number 3, August 2002.
Kimiz Dalkir. Knowledge Management in Theory and Practice. 2011. MIT Press. Accessed through Google Books, Dec 2017.
M, Lily. “Time to Get Your Tech Writer out of the Closet.” MindTouch.
Martin, Sarah; Carrington, Nicholas; Muncie, Nancy. “Promoting User Advocacy to Shift Technical Communication Identity and Value”. Technical Communication, Volume 64, Number 4, November 2017.
Neilson, Gary; Martin, Karla; Powers, Elizabeth. “The Secrets to Successful Strategy Execution.” Harvard Business Review, June 2008.
O’Keefe, Sarah. “Content strategy for technical communication.” February 2016.
Petersen, Emily January. “Articulating Value Amid Persistent Misconceptions About Technical and Professional Communication in the Workplace.” Technical Communication, Volume 64, Number 3, August 2017.
Rawson, Alex; Duncan, Conor Jones. “The Truth About Customer Experience.”. September 2013.
Redish, Janice (Ginny). “Adding Value as a Professional Technical Communicator.” Technical Communication, Volume 50, Number 4, November 2003.
Watson, Bob. “Measuring the value of technical writing.” August 6, 2017.
About Tom Johnson
I'm a technical writer based in the San Francisco Bay 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.