Value arguments for docs and tech comm — Part I: Introduction
When managers want headcount for a job requisition (whether expanding or backfilling), or when senior execs start rebalancing the workforce, the longstanding, sensitive issue of the tech writer’s value moves back into the spotlight. Should we open another tech writer position? Should we backfill the position? Why? What measurable value do tech writers and documentation provide to the organization? Should tech writers even be writing, or should they just help project teams write and publish their own content?
The value question becomes especially poignant because our very jobs are at stake. It’s not simply a matter of which authoring tool to use. Additionally, the meaningfulness of our work is challenged by these questions. If tech writers are deemed to add little value, it suggests our career is unimportant.
Almost no topic has been discussed more frequently in tech comm (since the beginning) than the tech writer’s value. Given the lengthy period of time this question has been debated, what can I add?
Regardless of whether I add original insights, I hope to make sense of the value debate for myself, for my own role and company dynamics. Conclusions about value inform the tech writing model within a company; they inform my daily activities and focus, how I prioritize and orchestrate my work, how I interact with other groups, how I see my own contributions, and more.
In this essay, I’ll explore these questions:
- What is the value tech writers provide to a company?
- How does this value inform the tech writing model in an organization?
- Why is it so difficult to communicate the value of what we do?
- How should tech writers position their value to senior leaders?
- Should tech writers act as mere supporting editors and publishers to project teams writing their own documentation?
I’ve broken this essay into seven parts to make it more digestible online.
In a nutshell, my argument is as follows:
- Documentation is valuable. It derives this value not from a carefully measured financial ROI, which is impractical to measure, but from the perceived value by many groups within the company that use the documentation. But even though documentation has value from perceived usage, it might not have more value relative to other organizational resources that are also used. As such, arguments about value based on usage fall short. Tech comm must seek for additional forms of value to tip the balance. (Part III)
- Technical writers can add more value by encouraging information flow across disparate groups within an organization (such as Support, Engineering, Marketing, Training, Field Engineering, and more). Encouraging information flow not only empowers these groups with better knowledge, it also encourages them to share feedback and input that dramatically improves the documentation. However, information flow alone is too tenuous of a value to attribute to technical writers and probably applies only to large organizations. (Part IV)
- Content experience — influencing the content across all touchpoints in the customer’s journey — is another area where tech writers can add more value. This roots the tech writer’s contributions in content development activities, not merely information flow. However, given the expanded bandwidth that cross-functional contributions require, these efforts require backing from customer satisfaction groups in the organization. Additionally, despite the good fit of docs to influence the customer experience, companies still primarily want someone to write clear docs, not necessarily someone to address the customer experience. (Part V)
- Technical writers can deepen the value of the documentation they create by focusing on areas of complexity for users (the users’ pain points). Complexity not only involves articulating the “string theory” parts of a system but also formulating the content in a way that users, regardless of their level, can understand. The task of simplifying complexity can only be achieved by leveraging many perspectives across groups; thus, focusing on simplifying complexity will also achieve goals around enabling information flow and improving the customer experience. (Part VI)
I'd Rather Be Writing Newsletter
Get new posts delivered straight to your inbox.
About Tom Johnson
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in simplifying complexity, API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.