Understanding engineers

I've known a lot of people who work in the technical documentation business and I've come up with a theory that documentation writers can be divided into two main groups. The first group, "writers who like technology," is composed of those who see themselves primarily as writers--"wordsmiths" is a common self-applied term--who just happen to work in a job where they write documentation. While they enjoy technology, they'd be just as happy writing else, perhaps even their own novel, if they could find a job that paid as well, and as steadily, as technical writing does.

The second group is "technologists who can write." People in this group were drawn to the profession because they're passionate about technology--cars, software, whatever--and somewhere along the line figured out they could write well enough to work in the documentation industry. In my experience, many of them started out in engineering or quality assurance, then migrated to the doc group by talent and circumstance.

It takes both types of writers to staff a good department, and yes these are broad strokes I'm using, but I think nearly everyone can find themselves in one category or the other. Those who self-identify as the first group might find the article Understanding Engineers: Feasiblity useful. If you're meeting with an engineering team and they are discussing new features or changes being made to a product, and these changes will impact your documentation, the information in this article will help you assess the likelihood of them happening. It's also good if you're asking for UI or other changes, in service of the documentation and help, and are being told that what you want is "trivial" to do, yet it seems not to happen. In my experience, the article's discussion of this phrase, and others, is exactly correct.

Posted: August 16, 2007 link to this item, Tweet this item, respond to this item