Four years in technical writing

This month marks four years since I began my first technical writing job.

I have learned many, many things since accepting my first technical writing job in 2019. Here are four notable observations:

You are the user advocate. Advocate!

As technical writers, it’s so important that we step in our users' shoes, think about our users' problems, and try to anticipate our users' needs. As you review UX mockups or build TOCs for your content, you need to keep your users in mind. What does the user need to know to successfully complete their task? Does the button text clearly indicate what action users need to take? How can you help your users find the answer to their problem?

If you’re confused, your users might be, too. Speak up and reach out to UX, engineering, or your support team, present your case, and discuss ways to improve the user experience.

Prioritize, prioritize, prioritize

Knowing how to triage documentation requests is an essential skill for a technical writer to have. Some documentation requests have higher priority than others. It’s important to define priority levels for you and for your team. This will help you decide what tasks you need to take on now versus the tasks to take on later.

If you’re a lone writer, defining priority levels for documentation requests can help to protect your bandwidth, too.

Everyone defines priority levels differently. Make sure that you discuss priority levels for documentation requests with your team.

Product managers are your friend

Product managers (PMs) are usually out there talking to customers. They identify customer needs and wants and prioritize what features to develop.

As a technical writer, it’s important to build and maintain good working relationships with PMs because:

1. They know what’s on the product roadmap. Why is this useful? Well, it can help you plan your documentation work. For example, imagine that it’s March, and your PM tells you that there are two, highly requested features they’d like to deliver in December. Because PM shared this with you months in advance, you can start researching and planning now.
2. They have valuable insight into what customers need or want in the documentation. I’ve worked with some great PMs who are willing to share customer feedback about product documentation. For example, if PM shares that customers are struggling to complete a certain task, perhaps you can collaborate with PM and UX to do some user testing.

This is a very short list. PMs can help advocate for the documentation, share valuable information, and keep technical writers in the loop about any upcoming features or bugs. They’re just great folks.

Learning to code has its benefits

When I started at my first technical writing job, I only knew a little bit of Git. After a few months in the role, I realized that although I didn’t need to learn how to code, if I wanted to do my best work, I probably should. I spent some time learning C#, SQL, and a bit about front-end web development.

Knowing how to code increased my confidence as a technical writer. It felt great to speak the same language as the developers. I also felt like I could contribute a bit more to the team.

Create templates when you can

Templates help to save time, money, and resources. For example, imagine that you’re tasked with creating three new tutorials for three different features. It would take a lot of time to create a new tutorial for each feature.

Instead, you can work with stakeholders to create a tutorial template that you can use each time you need to create a tutorial. As a team, you can identify any common elements you want tutorials to have, such as a prerequisites section, links to other parts of the documentation, or a feedback plugin.

Using templates has definitely helped me as a technical writer. I use templates for the documentation plans I create at work or for task topics.

It’s been a great four years so far. I’m looking forward to year five!