TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
After you have tried by yourself to reason with the developer, used all
kinds of psychology, etc., this is what I would do:
Document explicitly all your interactions with this developer for a certain
period of time. Every time you ask him (or her) to supply you with
something, or review something, MARK IT DOWN, and DATE and TIME stamp it.
Also, every time you ask the developer to prepare something for you, or to
get back to you with something, ask them for a date and/or time when they
will. I feel you must insist on that point, and bug them until you can have
some kind of commitment as to WHEN you "should" get the information, even if
this is 3 weeks down the line. MARK THIS DOWN and put it in your agenda so
you won't forget it.
When the marked deadlines come (if the material has not come to you yet), go
back to the developer, remind him or her of this commitment, and ask again
WHEN you can expect to have the material. MARK THIS DOWN AGAIN. Document
everything.
When this has gone on for a couple of weeks, and you are armed with a couple
of "fully documented" broken promises and faced with an indubitably (Wow!
where did that one come from??) uncooperative developer, go and see your
Project Manager (or Project Leader, or anyone else who you report to on this
project). Literally "dump" the problem in his or her lap. Don't complain
about the situation! Just state the fact that you have tried unsuccessfully
by several means to remedy the situation. You certainly don't have the
authority to "force" the developer to give you the material, but if this
continues, the deadline will be affected.
This method has worked for me in the past. My Project Leader was very
supportive, and could well understand my predicament. Using every ounce of
psychology, I then asked him that I didn't want to start a feud between the
developer and myself, and that the reason the developer wasn't getting back
to me was "probably" that he was overworked, or had higher priorities. My
Project Leader thus knew exactly what to do, and temporarily relieved the
developer of a couple of obligations, and asked him to spend a bit of time
helping me out. Everyone came out of this quite satisfied.
Fabien Vais
phantoms -at- accent -dot- net
At 09:00 AM 7/16/97 -0400, you wrote:
>Hello Fellow Technical Communicators:
>
>I'm working with my Human Resources Dept. to create a course in Human Relations
>designed specifically for the tech writers on our staff.
>
>As in most software companies, we work with a mix of programmers and
>developers, some of whom are quite helpful and understand the value-added that
>tech writers bring to a project. Others are more reluctant to share information
>or can't see that cooperation with a tech writer produces a win-win situation.
>You know the story.
>
>To help the writers on my staff work with these more difficult types of
>individuals, I am soliciting ideas, tips, success stories from you. What are
>some specific successful ways you have found to deal with programmers /
>developers who are difficult, reluctant, uncooperative, overly-cautious, or
>too-busy-for-mere-tech-writers?
>
>The more specific examples you can provide, the better. Most likely, the types
>of situations you have encountered and your solutions will have application to
>our situation as well. Your examples will help me show the writers on staff
>here that the difficulties they are encountering are not unique. Also, I think
>that third-party examples will carry more weight with the staff here than, say,
> suggestions that come strictly from my own personal examples or from our HR
>dept. alone.
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html