First off, hire a technical writer. And do so as fast as you can.
Of course, there are some problems with this statement, the first being that the technical writing industry itself hasn't the first clue what it should really be doing.
Maybe I should say, instead, hire a good technical writer. What makes a good technical writer, you say?
A good technical writer:
Is fast.
Produces concise, clear, and elegant prose
Has a background in the same technologies you use regularly
Can read code without help
Can take input in any form, including a three-second coredump, and parse it without asking stupid questions (what's a UNIX?)
Can use CVS or other version control software
Can think and act like a programmer
Comes to every single development meeting, and understands the product cycle from the first scribbled napkin to its present form
Makes maximum use of documentation technologies (such as FrameMaker+SGML) to reduce wasted and redundant work
Applies procedures to their work which require minimal additional procedural silliness from you.
That's the short list. Far, far too many technical writers fall into the trap promulgated by the TW industry as a whole, which appears to be:
Stultifying bureaucracy is the key to successful technical writing.
I consistently encounter "technical writers" who seem to think that what worked in their Master's dissertation at UC-Berkeley is what will work in this industry. You can easily identify bad technical writers by the fact that they're slow (1 week or more to produce a document), mistake bureaucracy for procedure (a good procedure is minimally invasive, and works around the expensive folks like programmers rather than the writer), and, for some reason, can never quite get things done on time because it's too complicated.
It's also entirely unnecessary for your technical writer to have a degree or certificate of any kind, regardless of the (again) technical writing industry's opinions. What matters is what they can produce. The questions you should be asking of any prospective technical writer are (among the usual for any new employee):
May we see writing samples from your most recent job?
How rapidly were you required to produce these writing samples?
How quickly are you used to creating documentation? Do you have any problems with working faster? If so, what are they?
Do you use document templates? If so, do you build them so that there's no additional hand-tweaking required? If not, why not?
What strategies do you use to manage your time?
How are you going to simultaneously Hoover out the brains of my engineers and preserve their highly valuable time?
You get the idea.
When you interview a technical writer, submit them to a simple test, which should be most of the interview in a nutshell.
Make them write something for you. Put them with your most turbopowered supergeek for an hour, have your supergeek describe one of your company's product components to them, and have the writer document what they hear.
Any competent writer should give you something concise, clear, and reasonably elegant within a day or two, no longer. If they can't, you should seriously question whether they're worth hiring.
My $.02 as a technical writer who is, apparently, unqualified in the eyes of the TW industry to hold either my current job or my last five jobs,
Slashdot Mirror
First off, hire a technical writer. And do so as fast as you can.
Of course, there are some problems with this statement, the first being that the technical writing industry itself hasn't the first clue what it should really be doing.
Maybe I should say, instead, hire a good technical writer. What makes a good technical writer, you say?
A good technical writer:
That's the short list. Far, far too many technical writers fall into the trap promulgated by the TW industry as a whole, which appears to be:
I consistently encounter "technical writers" who seem to think that what worked in their Master's dissertation at UC-Berkeley is what will work in this industry. You can easily identify bad technical writers by the fact that they're slow (1 week or more to produce a document), mistake bureaucracy for procedure (a good procedure is minimally invasive, and works around the expensive folks like programmers rather than the writer), and, for some reason, can never quite get things done on time because it's too complicated.
It's also entirely unnecessary for your technical writer to have a degree or certificate of any kind, regardless of the (again) technical writing industry's opinions. What matters is what they can produce. The questions you should be asking of any prospective technical writer are (among the usual for any new employee):
You get the idea.
When you interview a technical writer, submit them to a simple test, which should be most of the interview in a nutshell.
Make them write something for you. Put them with your most turbopowered supergeek for an hour, have your supergeek describe one of your company's product components to them, and have the writer document what they hear.
Any competent writer should give you something concise, clear, and reasonably elegant within a day or two, no longer. If they can't, you should seriously question whether they're worth hiring.
My $.02 as a technical writer who is, apparently, unqualified in the eyes of the TW industry to hold either my current job or my last five jobs,