Workflow Collaboration Tips from TechCommDood

workflow collaboration,tech writer,tech writing

While I may have differences of opinion about Adobe’s handling of RoboHelp with Bill Swallow, he’s spot on in his recent post about how to become a better Technical Writer.

Or, in my opinion, how to become a better part of the Workflow.

Quoted from Bill’s blog post waxing techcomm:

If you’re at the end of the information chain, start climbing to the beginning. That is where the action’s at, and that is where you can make your biggest impact. Before specifications are born, before project plans are drafted, there is design work going on.

Get in there and get your hands dirty. As a tech writer, you have a greater likelihood of having a good user-focus than others, because you’re (hopefully) tailoring the documentation to fit the users’ needs.

As features are being dreamed up and initially designed, review them. Provide useful feedback that will improve the implementation and usability of that feature. Take the good ideas and make them better.

Can’t climb to the beginning of the chain? Look for other ways of adding value. Improve a poor process. Improve internal communication. Centralize internal knowledge. These are all quite common problems in an engineering organization.

I think that there are great ways that Technical Communicators can impact the entire workflow. Collaboration with other team elements is critical, and a well-worded support document can radically impact the after-sales support of a product.

Analysis

Bill’s approach about getting in on the beginning should dovetail into working out a workflow collaboration method that the product manager can adopt. If a tech writer can, through the use of a simple devblog, keep everyone informed and stop the email forwarding that plagues software development, all will start off on the right foot. The tech writer becomes the golden child instead of the whipping boy/girl.

Should the PM adopt a method to track changes that is open and viewable to the entire team, everyone benefits from the transparency and ‘everyone gets the memo on the TPS Report.

I worked for a company that was less than functional in obtaining change requests for documentation. Needless to say, creative approaches were critical in getting the information in time for changes to the product to be represented in the documentation, particularly with a single help author / tech writer and eight different product lines!

Here’s some basic information for those of you who may just be starting out, or for engineers who consider DITY technical writing:

The Tech Writer’s Style Guide <- humorous examples of what not to do.

Introduction to Technical Writing/Documentation <- short and sweet.