Re: Employment Interview

[Mark Baker <mbaker -at- OMNIMARK -dot- COM>]

Karen Kay wrote


>I recently had an interview in which I was asked about conflicts and I
>really had nothing to say. I've never had a serious conflict w/ an
>SME. ...
>So is this chance, or am I doing something right? I'd like to think
>the latter of course. But I didn't get the job, for the very reason
>you give:  I wasn't experienced enough in conflict w/ SMEs. This makes
>no sense to me.


and Dick Gaskill wrote

>"Quality documentation is defined as accurate, appropriate, predictable,
>readable, complete, usable, effective, and timely."
>
>accurate = the information is technically correct

Which brings me to the reason you have to argue with SME's. The reason is
<pause while I don asbestos underpants>: technical accuracy is irrelevant.

User documentation is performance support material. Its purpose is to get
users to act correctly. Whatever gets users to act correctly in as short a
time as possible is what you should write **whether it is technically
accurate or not**.

Or, if you like, think of it as the distinction between functional accuracy
(that which leads to correct action) and philosophical accuracy (that which
leads to correct understanding). Philosophically accurate description of a
complex product is usually dense and complex. If the product is well
designed, a functionally accurate description is usually simple.

Writers of user guides are in the business of functional truth. Engineers
are in the business of philosophical truth. If you get your engineers to
read your documents (argument # 1: they don't want to read them), they will
not like them because they are not philosophically accurate (argument #2:
they don't think they are accurate or complete).

While some engineers can and do appreciate the need for functionally
accurate docs, the majority don't get it unless you explain it (argument
#3), and some don't get it even then. The stumbling block is that for most
engineers there is no delta between philosophically accurate and
functionally accurate (that's what makes them engineers).

So, if you have never argued with an engineer, it has to be because you have
been incredibly lucky with the engineers you have had to deal with, or
because they have never read your documents, or because you have failed to
create documents which are functionally accurate.

Unfortunately, despite our increased emphasis on task based documentation,
all too many tech writers still translate the spec into English, rather than
describe the users task. Many still implement task based documentation by
reordering material by task without actually changing it from describing the
product to describing the task.

Bottom line: your job is to make users act correctly, not to describe the
product. Engineers don't like this and will argue with you. You have to win
the argument or your users will suffer.

---
Mark Baker
Manager, Corporate Communications
OmniMark Technologies Corporation
1400 Blair Place
Gloucester, Ontario
Canada, K1J 9B8
Phone: 613-745-4242
Fax: 613-745-5560
Email mbaker -at- omnimark -dot- com