I’m often asked why I chose project management after 15 years as a technical writer. While one reason was definitely the increased earning potential, the deciding factor was how well key skills translated to my new role.

Here’s a short list of the technical writing skills that I use every day as a project manager:

  1. Organization
  2. Work breakdown
  3. Comfort with picking up new software
  4. Interviewing/listening


Documentation is often the proverbial ‘end of the whip’ – it’s the last deliverable to be completed and it’s moving the fastest. A technical writer, especially a solo writer, needs to be able to plan for when a feature can be documented. They need to perform their tasks in time for any translation/localization and approvals ahead of general availability. I’ve worked in environments in which I managed release notes, end user docs, and developer documentation for multiple software streams with overlapping 6- and 18-month release schedules. Organization was absolutely key.

This skill translates directly to project management/scrum. You must be able to not only help the team arrive at a vision of when products can be delivered, but in what order, and what would constitute an increment of value. A PM also needs to be able to keep track of multiple threads of discussion and prompt follow ups when necessary. Understanding and tracking dependencies between your team and others will also be critical.

Work Breakdown

Work breakdown means something very specific in project management, and we’ll get to that in a moment. Speaking as a tech writer, it means breaking down an end user’s process into steps that make sense and that can be described in the format in which you’re working. There’s some analysis, some guesswork, and in the best shops there’s user research to infirm the information design.

For a scrum master/project manager, the term refers to breaking your team’s work down into manageable chunks that deliver a useful piece of functionality when complete. The team, with the help of the scrum master, take one big problem to be solved or feature to be delivered and break it down into baby steps. It involves some analysis and some guesswork (though that guesswork gets more accurate with time). Teams should consider feature development from the point of view of specific end users.

While the two processes are merely analogous, there are enough similarities to give a new scrum master a leg up in helping their teams arrive at completable stories.

Comfort with Approaching New Software

As a technical writer, each release and each product to be documented is something new. It’s common for writers to strike out on their own to click through new software, to read a pile of code, or to interview a Subject Matter Expert.

Wherever you go, there will be a system for organizing/measuring team progress. As a scum master or PM, your ability to extract the data you need to coach your team requires that you first understand all of that software’s features. Further, if you are working with a development team, it is highly beneficial to understand the work that team does as much as possible.


Whether it is interviewing an SME to understand a product or interviewing end users to understand their pain points, technical writers must be able to elicit the information they need as efficiently as possible. Successful technical writers practice active listening in order to ‘hear’ beyond the subject’s words to what they mean. They use follow up questions to probe deeper into a topic for greater clarity.

As a project manager or scrum master, these interviewing skills will help you in facilitating meetings and discussions. If team members are at an impasse on how to approach a problem or dependency, use open-ended questions to see if the team can make new connections or brainstorm novel solutions. The practice of targeted discussions with SMEs who often have little time to spare will help as you facilitate meetings and keep discussions on target.