I often tell my students that as technical communicators, we are professional gadflies. It is our job to buzz persistently, and bite when necessary, to get certain things done. We cannot move forward with documentation on a product that is languishing, so we interact with the developers to see how things are going. We ask for prototypes and working versions. We query them about deadlines, especially “When’s code freeze?”.
We often become de facto project managers on the projects to which we’re assigned. In managing our documentation projects, we encourage, inspire, assist, and even require others to meet their production and development deadlines so we can take that deliverable and add its information to our documentation. Another rule of our craft is that a product never, never, never is delayed for release because of documentation. When that product is ready to go, so is the documentation, and often it’s that the docs are done and just waiting on the final touches to the product. (Cleanup, not changes.)
Another way we exhibit the traits of a gadfly is that we never give up on trying to make products better. An organization I’m involved with recently suffered a significant data loss from their enterprise software. This was not human error but an inherent flaw in the system. No program should ever, EVER allow such a data loss without making the humans work really hard to achieve it. Sure, there are situations one can envision, such as fiddling with a directory on the server, that could make a lot of data disappear quickly. But in this case it was an attempt to perform a task with the product that the developers had not anticipated.
For a technical communicator, that sets off warning bells right away. Task-centered (i.e., user-centered) design of products and software requires that all the possible tasks a user might want to accomplish have been addressed by the product’s design and interface. With our user focus, technical communicators analyze user tasks to ensure that our documentation covers everything the user wants to do. Inevitably, we discover tasks that may not have been included in the specifications and design, so we lobby to have them covered. Unless, and until, the product meets user needs, we don’t give up.
I also liken what we do to fire prevention. Fires are costly. Much better to prevent them in the first place. If you find you’re putting out too many fires in your company, maybe you need to hire more technical communicators. Just a thought.