Advent of Technical Writing: Facilitating Ideas

This is the thirteenth post in the Advent of Technical Writing series, wherein I will share something I have learned from my experience as a technical writer. My experience is primarily in software technical writing, but what you read may apply to different fields, too. View all posts in the series.

I want to talk about three parts of facilitating ideas that come up in my role as a technical writer: ideating, prioritising, and not filling your plate too much.

Ideating

A significant portion of the ideas on which I work come from discussion with the rest of our marketing team.

We regularly check in on updates in the computer vision industry in which we work. This is essential because the industry is changing week-by-week. Sometimes our priorities can be shifted for a week so that we have time to create content on new topics that would be relevant to our audience of people -- students, customers, enterprises -- who turn to us to learn about the latest in computer vision.

We also discuss what is going on within the organization. Indeed, a technical writer should be integrated into as many parts of an organization as possible. The more I know about what other teams are working on, the more effective I can be at supporting the broader organization's goals

For example, last week our team spent time on producing content on a new product, Video Inference. The more content we have on the product, the more resoucres we have that can be sent directly to customers who may benefit and promoted.

Although the marketing team comes up with a lot of ideas, in many cases ideas on what to write come from other departments. Sales. Customer support. Senior leadership. Product. Field engineering.

I recommend that technical writers make themselves as known to an organization as possible. Position yourself as a resource; be there to support, advise. Invite people to contribute blog posts. Offer to write blog posts about topics that other people are interested in. Everyone who works at your business may have ideas on what content would be useful to customers, users, and other stakeholders.

For example, we recently finished a long-running technical content marketing initiative with various industry partners. This idea initially came from senior leadership, then I discussed the idea with our marketing lead (head of department). We noted some content ideas and over time I contributed content to the initiative. I ended up writing several blog posts that integrated directly with a core product.

Last week, I wrote a guide on deploying vision models offline. The idea was recommended by the head of one of our product lines who noticed we didn't have content. We published a guide on quality assurance, using skateboards as an example. This was written by a new team member who used his years of experience in manufacturing to inform the post direction.

Ideas come from everywhere.

Prioritising

We have a Miro board at work on which we take notes for potential content ideas. Miro is effective because it is visual and interactive. You can arrange tasks however you want. Our marketing team doesn't assign deadlines for topics, rather expectations that certain content should be completed in a given week, or may be worth exploring at a future date.

To prioritise work, we ask a few questions:

1. What content will help stakeholders solve problems?
2. What content have team members suggested we produce?
3. Are there gaps in our current documentation that need filled?
4. Is there feedback that we need to act on?

From there, we come up with themes for a week. Last week's theme was Video Inference, a new product, as well as wrapping up some content marketing with industry partners. This week's theme is multimodality, a concept that refers to machine learning models that can work with images and text to solve problems, as well as general documentation cleanup.

I recommend working across themes in your team to avoid context shifting. Set goals around a specific product or an initiative that your team -- and other stakeholders -- collectively agree is a priority. I rely a lot on our marketing lead to help steward prioritisation discussions but I always provide insights to help us agree on priority. Indeed, prioritising should be a conversation.

Most of our work is prioritised a few days or weeks in advance, depending on the task. However, we always have room for content that pops up that requires immediate attention. For example, we respond to fixes suggested by other departments in a timely manner. We cover industry trends with new technical content. We lend an insight into how we should position a piece of software while there are still active product discussions going on.

Plates: Don't fill them too much

Every week, you should work toward defining a clear scope of work that you think is achievable. Don't fill your plate too much. What constitutes "achieveable" will be based on all of your past experience, as well as the information you have about the initiative on which you are working. This is a muscle that you will exercise every week.

When I see priorities of the week, I take notes of what I think I can do and suggest some content that I think will be difficult to fit in the week. I also think about balance. If I have had a week of writing a lot of content, I may ask to focus on other tasks, like contributing features to our open source software based that are open and do not have an owner.

Writing documentation is a long-term game. Split large projects into smaller, achievable tasks. While the prospects of a new project may be exciting, it is important to set realistic expectations for what you can work on and by when. Anticipate that other tasks will come up and use that to inform to what you can commit. Someone may ask for your support editing a blog post, you may be asked to sit in on a few product calls, you may see an opportunity for learning about something new that you want to seize. You want to be able to be present.

For example, a documentation overhaul project in which I participated earlier this year took around a month to be considered complete. We allocated a week for internal feedback, a week for talking with customers and synthesizing feedback into action items, then two weeks (with room for more) to act on feedback. This was a marathon, not a sprint. In the end, the project came out really well, but I needed all the time I had to deliver on the task.

Being explicit about what you can do each week is helpful to everyone. Your manager will have more information to evaluate how much work they can assign. You can better plan what content everyone on the team will write. You can more confidently say that certain projects that have external stakeholders will be delivered on time. Expect your motivation to flux. We can't write words all day, every day. But that's okay! For, as I have documented, the role of a technical writer is about so much more than words.

That's it for today's technical writing tip! Join me tomorrow for a new tip!