During the past few months in my current position, I have begun to think differently about what it means to be a technical communicator. Initially, I worked solely with development teams and subject matter experts using an Agile methodology, documenting product enhancements and features, and ensuring that the documentation was ready in time for release.

I was a technical writer.

Transition from writing to communicating

Recently, I’ve been working towards becoming a technical communicator – which is a broader role with varied responsibilities. I communicate with development teams and subject matter experts, and update the documentation accordingly, but I also work with different customer-facing teams, and support both internal and external communications regarding product updates.

I’m a technical communicator.

Connect with different teams

Often, technical communicators work closely with designers, software engineers, developers, and subject matter experts, but rarely do we get to communicate with sales, marketing, or customer success teams.

Sometimes, the people we work with is entirely based on the hierarchical structure of the company, including who we report to, and what teams we tend to support the most.

I encourage you to connect with different departments – particularly the departments that you normally do not have a connection with.

Some ways of connecting with different teams include:

• Working with design and development teams to help shape the product and provide feedback for messaging within the product.
• Working with marketing teams to streamline external communications to customers, including emails, portfolio updates, and in-app messages.
• Working with customer-facing teams to provide information on upcoming features, targeted release dates, and documentation resources – if possible, before the feature is released!

Gain different perspectives

As technical communicators, we tend to develop core product knowledge and some domain knowledge. However, by working with customer-facing teams, we can also get answers to the following questions:

• What are common questions that customers have about the product?
• How are customers using the product?
• Are there specific use case scenarios that should be included in the documentation?
• Is there missing information within the documentation?
• How are customers accessing help information?

Knowing the answers to these questions enables us to improve how we communicate information within the company – and externally to customers.

Streamline communications

In large companies, it’s challenging to ensure that everyone is getting the resources and information they need to do their job. Often, teams are only aware of what they are doing, and have little understanding of the work that goes on in other departments.

One way you can streamline internal communications is to set up a company-wide page for providing product updates.

At the company I work for, we have set up a release notes page on Confluence, which offers information on upcoming product enhancements, targeted release dates, and documentation links. This is a key place for ensuring that everyone is receiving the information and resources they need to complete their work. The page also fosters collaboration and interaction between several different teams.

Leverage the Agile methodology in everything you do

Agile methodology is not just a workflow and philosophy reserved for design and development teams. You can apply the Agile methodology for communicating internally with different teams.

Some ways to leverage Agile methodology:

• Promote face-to-face interactions and collaboration over processes and tools
• Capture requirements at a high level
• Develop small, incremental changes and reiterate
• Complete one task before moving on to the next

Be a technical communicator

You have an amazing role in your company. You have the ability to impact how your company obtains and uses information.

You have the power to communicate.

Michelle Vinci