Five project management responsibilities of senior technical writers
- Background
- 1. Prioritizing work
- 2. Defining doc strategies
- 3. Organizing work among multiple writers
- 4. Reviewing contributions
- 5. Reporting upwards
- Conclusion
Background
Trajectories for technical writing careers are somewhat strange. In my experience, moving from technical writer to senior technical writer came after working only two years in the role. When management wants to promote/reward you, they move you up a level. Throughout my career, I moved back and forth between technical writer and senior technical writer job titles somewhat arbitrarily. However, it wasn’t until many years later that I realized the full scope of expanded responsibilities that align more with a senior or even lead technical writer role.
Also, although there’s a tremendous push in our field to get more technical, especially within API documentation field, in my experience the role I find myself playing isn’t so much immersion in the nitty-gritty technical detail but rather expanding in more of this project/program management role. The following are five characteristics of this more project/program management role:
1. Prioritizing work
One task you have as a senior/lead technical writer is to prioritize the work. There might be 100+ tickets in your backlog, as well as key objectives, requests from others not filed as tickets, your own sense of what should be done, upcoming releases that will need documentation, and more. You have to define all the existing work and prioritize it somehow.
How do you decide what you’ll work on, among a mountain of possible tasks? One strategy would be to identify key stakeholders and have them stack rank the most pressing needs, but often the answers you get about doc priorities depend on the stakeholder you ask. Ask five different stakeholders what the priorities are, and you get five different answers. You have to sort these priorities out and figure out what in fact you should be working on.
In contrast, a more junior level tech writer is merely assigned or handed projects, and told what to work on.
2. Defining doc strategies
Another responsibility is to define strategies for the work. People might not know what work should be done. They might come to you for insight about what’s wrong with the current docs, or what directions should be taken with the site. Upper management will no doubt ask you to define some documentation goals/objectives for the year, and you’ll need to think strategically about what is ultimately deficient in the current solution, why, and how to fix it. If a higher-level manager does indicate a need, such as increasing user satisfaction, making the docs scale, deflecting support costs, or expanding the audience, you’ll work out for yourself how you would go about that.
3. Organizing work among multiple writers
Another task is to organize the work among multiple writers. You might have a number of other writers you’re working with. How do you organize the work so that the different writers have a logical, coherent set of tasks? Usually, you group tickets into different products or components, and then the different writers take on all tickets related to that product or component. This specialization works well if there’s a good balance among tickets but can be tricky when some products/components have lots of tickets, others few.
4. Reviewing contributions
Additionally, one task of a senior/lead technical writer is to review the content that others create and submit (not just other writers, but other non-writer contributors as well). A more junior technical writer is often content to remain in their own silo of content, concerned only about their tickets and submissions and focused on their slice of the doc site. The senior/lead writer needs to have the full picture of the content, to understand what’s being contributed, whether it aligns with other content on the site, whether it meets expectations of the tickets, whether it hits the quality bar, and more. You can’t just silo yourself and be content with components A, B, C but need more familiarity with components A to Z. You have to understand the larger picture.
5. Reporting upwards
Another task is to report upwards to senior stakeholders, providing business metrics about the documentation that align with other kinds of business metrics reported by other groups. For example, you might report on goals around ticket deflection, newly published content, usage metrics, and other goals related to user satisfaction around docs. These metrics are some of the most difficult to define and report on, but communicating them upward helps establish the value of the doc team. This value is crucial for resource allocation and visibility within your organization.
Conclusion
For many years, I thought that the upward progress of tech writers involved becoming more technical and specialized. Technical aptitude is certainly important and can’t be neglected, but the project/program management tasks are just as critical, if not more.
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.