Kai Weber just posted a cautionary tale about what happens when a company regards technical communication as a task rather than as a profession.

In Kai's tale, programmers and testers are brought in from other parts of the company to help update a software product -- and then they're called on to write the documentation as well. The quality of the doc suffers, and customers complain that much of the doc focuses on features and reference information rather than on how to use the product.

Having given in to the "seduction" of reducing costs in the short term, management now finds that the product's documentation is hard to use and impossible to maintain.

Kai's story is all too true. I've seen it happen. Allow me now to write the next chapter.

After development and test assume the task of producing documentation, the effects move out like ripples in a pond to other parts of the company.

When customers complain that the docs are unusable, management asks the training staff (or a training consultant) to deliver courses for setting up and using the product. The cost of the training is borne by the company, which negates the earlier short-term savings, or it's passed on to the customers, which increases the cost of owning the product and makes the product less attractive in the marketplace.

A culture develops in which customers call on Tech Support to guide them through the setup and configuration workflow. Tech Support costs balloon while customer satisfaction sinks.

Kai's conclusions -- that writing effective documentation requires professional writers, and that "seductive" short-term savings end up costing more in the long run -- are on the money. I would merely add that the costs will end up permeating many different parts of the company and that some costs, like lost market share and diminished customer satisfaction, will go far beyond a simple P&L statement.

Have you ever been part of this story? If so I'd like to hear about it, and about the insights you gained.