Article On Getting Cooperation from Resource People

["Jane S. V. Mellin" <Sybilla -at- AOL -dot- COM>]

This article responds to one of your suggested topics.
Handling Uncooperative Engineers or Programmers
by Jane S. V. Mellin (sybilla -at- aol -dot- com)

I have spent 15 years working as a writer and writing manager, and I have
never found an uncooperative technical resource person who couldn't be
handled using one or more of the methods and recommendations discussed in
this article.

Preparation
Before meeting with a new resource person, prepare in these ways:
* While at all times behaving in a humble way, know the subject matter as
well as you can, using whatever resources are at your disposal. Understand
the basics of any hardware, software language, or application you will be
working on. Many uncooperative resource people have been soured by technical
writers who don't do their homework and then ask "stupid questions."
* Find out as much about the person as you can, and find out about the people
who have had problems with this person in the past. Reserve judgement,
however, because your interaction skills will be better than those of others
who have had trouble in the past. I have walked into situations where the
programmer or engineer had authored the previous documentation of the
product. Knowing that in advance was very important!
* If the resource person has written any white papers, specs, or other
materials (even unrelated to your upcoming discussion), read them! Many
engineers and programmers are also writers.
* Have your marketing resources ready. If customers are not satisfied with
the current documentation, you will need something, in writing, to support
this fact. This may be a market survey, responses to a questionnaire that
technical support people or system consultants have completed, or letters
from users. If there is any hard information available, you should be very
familiar with it, even if you don't have to use it.
* Get your ego under control. You are merely a humble writer, but this person
is a creator. Don't forget the respect that you owe them.
Do's and Don'ts
Don't waste the person's time. Have an agenda for your meeting or a list of
questions. Send this to the resource person well in advance of the meeting.
Even if you are only going to speak over the phone, set a start time and an
end time for the meeting.
Do review your queries carefully before submitting them to your resource
person. Is there some other way you could find the answers? Have you
researched carefully?
Do ensure that the resource person feels a sense of ownership. He or she
should see the documentation you are writing as a frame that presents his or
her efforts to the world. It is a part of his or her product. You are a team
member preparing this representation of the resource person's work. As such,
you must portray yourself as the resource person's subordinate, even if you
don't really feel that way. Don't expect respect. You have to earn it.
Do ask for additional resources. Perhaps this subject-matter expert can refer
you to books or articles that will help you.
Do observe and respond to verbal and visual cues, including body language and
technospeak. Respond in a positive way to body language. For example, if his
or her arms are crossed, indicating lack of acceptance, make sure yours
aren't! If you don't understand a term that your resource person uses often,
note it. Later, find out what it means.
Do show enthusiasm and excitement about the opportunity to work with this
person. Make it clear how much you value their input.
Don't beg. You have to stress the benefits that cooperation holds for your
resource person. You are helping present their product in the best of lights.
This means more recognition.
Do stay off your resource person's turf. If you don't like the way the
product works, document the way the product works. When the functionality or
interface is explained clearly, the defects are clearly represented as well.
In time, you will earn the right to comment on the product itself but not
now.
Techniques
Some of these techniques are only for desperate situations, but I've used all
of them at different times.
* Flattery. "I think the product is really great, and I want to show people
what they can do with it." "Gee, your article on Gizmos taught me a lot."
* Appreciation. Make sure your resource person feels that they are doing you
and their product a favor, not merely fulfilling an annoying obligation.
* Yes or no questions. If all else fails, submit a written list of yes or no
questions. For example, write a short paragraph and ask whether it is
correct.
* Use customer input. If necessary, paraphrase any customer input (for
example, questions that users ask frequently or their response to the product
documentation). Do not quote very negative comments literally. It's very hard
for any resource person to discount the opinions of users.
* Refer to other contacts and projects. If some of this person's peers or
superiors have helped you in the past, be sure to let the person know it. If
you have worked on successful documentation projects he or she may be
familiar with, convey that as well.
* If you are working on a product that will be reviewed in the press, cite
the importance of the documentation to that review. Bad docs can make a
product look bad, even if they are trivial to the programmer or engineer.
Some resource people never think of this.
* Ask for writing advice and recommendations about how to present
information. Even if you can't act on the advice, it will tell you something
about the resource person.

Conclusion
Probably the most important factors in your success will be: sound
preparation, humility and respect for your resource person, and efficient use
of his or her time.