Part I: Introduction to the series
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.
Argument overview
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)
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.