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.
Subject:Re: Document relevance problem From:John Bell <jbell -at- PARAGREN -dot- COM> Date:Fri, 12 Dec 1997 09:34:40 -0500
Dear Frog;
If you want the developers to review your documentation, you have
to give them an incentive. Traditionally the incentive is to make it part
of their job duties, but it sounds like you don't have the pull to get that
included.
So, on to Plan B.
To make a develop WANT to review your work, point out what's in it for her/him.
I tell developers that I am the cheerleader who takes the genius of what they do
and explains it to the world. (Flattery will get you anywhere!) Now if they would
be so kind as to look over what I've written so we can both make sure that I'm
telling the fans the right information.
Bring the message to your developers that they ARE doing something special.
YOU want the customers to know exactly what that something special is, and how
to get the most out of it. If properly explained, the customers will be very appreciative
of what YOU the developer has built for them. If they don't know what's in the product,
how can they possibly be happy with it?
In other words, play on their pride. Everyone wants to be proud of what they do for
work, and by positioning yourself as the cheerleader, you become the good guy. You
are the one who is championing their work, their efforts... promoting them to the
public in a manner they might be too shy to do themselves.
If they still refuse, you can semi-shame them into cooperating by asking "What? Don't
you think your work is important enough? Don't you think they need to know about it?
I think it's important!"
Once you get enough developers accepting this you can then push for it to be a standard
part of their job duties and written into their job descriptions. You do this by pointing out
that if they're already doing this, they should at least get credit for it in the eyes of management.
Bring it up at a team meeting and ask how many developers feel reviews are part of their
normal, expected job functions. If you can get the developers to support it, you'll have
little problem getting their managers to add it to the formal list of job duties. Volunteer
privately to the managers that when it comes time for performance reviews you'll provide
them with information on each developers cooperation with reviews. This reminds the managers
that official job duties have to be part of the formal performance review process. Once it is
part of performance reviews, cooperation will increase.
Enjoy!
--- John Bell
jbell -at- paragren -dot- com