The technical writing profession has been battered for several years – often perceived as a “nice-to-have” item with a product, rather than a “must-have”, product developers and manufacturers sometimes give short shrift to comprehensive and accurate documentation. The move to online documentation, done for a variety of reasons, including cuts to product cost, added to the problem — why have technical writers? Let’s have the developer write the documentation! Not all companies are guilty of this; many do provide quite nice printed or online documentation with their products. But I perceive that some of the issue has been created by the approach taken by some practitioners: the view that I’m here to write the manual for the XYZ product using the ABC tool.

It’s the sort of heads-down, focused approach that turns out lots of stuff. Great productivity! Or is it? What’s the answer to the larger question of the right supporting information for this product? How do we provide the optimal combination of documents, online help file, webinar, training courses, FAQs, and so on, that meet the customer’s need at the right time?

This issue is not confined to technical writing, by the way. It applies to other areas where we practice. Consider the project manager who is obsessed with updating the project schedule, but will not address the fact that the product solution doesn’t really address the customer’s needs. Or, the proposal developer who assembles answers to an RFP (request for proposal) from a database, without considering whether those answers really address the background and specifics of the customer’s question.

I want to go one step further and say that this ability to look at the larger picture, and participate in global problem solving, is key to an individual’s ability to find and keep good positions. We certainly try very hard to find people who are good creative problem solvers, and can participate actively in executing the solutions.

Solve the problem.