R-E-S-P-E-C-T (find out what it means to me)

Once again the topic of respect for technical writers appeared on a techcomm-related mailing list. These outbreaks of Rodney Dangerfield syndrome ("I get no respect") happen almost like clockwork. And honestly, I'm getting tired of hearing it.

Respect is never given; it's earned. You can't expect others to respect you for writing a good 600 page manual on deadline, or developing a context-sensitive Help system, or handling all the loose ends in a release notes document. They expect you to do that. It's your job. It's what you're paid to do.

And let's face it, those who aren't technical writers do think that the job is easy. You're not developing a product, you're just writing about it. And if that's all they ever see and experience you doing... well, perception is reality.

So change the perception. You can't TELL them you're good, you need to SHOW them. And they're not going to care that your documentation is grammatically correct, spell-checked 100 times over, and has ample use of white space (I think I heard a few snickers just as I typed "white space"). But they will certainly care if your involvement makes their jobs easier, or if your work truly increases the product's bang for the buck.

The classic, stereotypical model for technical writing as the engineering world knows it is as follows:

1. Engineer gives info to tech writer.
2. Tech writer word-smiths it.
3. Engineer critiques the documentation.
4. Tech writer makes the edits.
5. Documentation seems done.
6. Writer makes it pretty.
7. Product ships.

Now there may be some variations out there, but the gist of it is that the writers are given info in one manner or another.

So from the engineer's perspective, where is the hard work? They designed the product. They made the product. They told you all about the product. You took the information and made it release-ready. In their mind, who's doing all the hard work? Yep, the engineers.

So, you disagree? Good! So do I. But the cold hard fact of the matter is that this model is more the norm in Engineering departments than not. Again, perception is reality, and it's quite easy to fall comfortably into this model. Many do. Just don't complain about lack of respect if you do.

Avoid this model. If you're at the end of the information chain, start climbing to the beginning. That is where the action's at, and that is where you can make your biggest impact. Before specifications are born, before project plans are drafted, there is design work going on. Get in there and get your hands dirty. As a tech writer, you have a greater likelihood of having a good user-focus than others, because you're (hopefully) tailoring the documentation to fit the users' needs.

As features are being dreamed up and initially designed, review them. Provide useful feedback that will improve the implementation and usability of that feature. Take the good ideas and make them better.

Can't climb to the beginning of the chain? Look for other ways of adding value. Improve a poor process. Improve internal communication. Centralize internal knowledge. These are all quite common problems in an engineering organization.

Another common problem is a lack of good specifications at the start of a project. The common reason for this is time - there's no time to write it all down first, because product needs to go out the door. This is a fallacy, because the time "saved" by not documenting the feature work is later lost in a scramble to get the thing tested and documented at the 11th hour. Quality starts at the beginning.

Perhaps your engineers find the spec-writing process to be time consuming and tedious. Would they benefit from using a template or form? Are they unclear as to what information to put into the spec? Are they clear on putting the wrong information into the spec? Simple guidance can go a long way to improve a process in which everyone wins. Testers and writers will no longer be badgering the engineers for details in the final hour, and everyone will have an opportunity to appropriately plan out their work if they have a complete spec to work off from the beginning.

In some manner or another, your organization is likely to be hobbling along on a fractured process. It's painful, and should be fixed. Like any good surgeon would, sometimes the fracture needs to be broken before it can be repaired. And like some patients, some people aren't going to be crazy about that idea. But if the problem is big enough, it needs to be done.

Further, though it might be tough to break the cycle to fix a problem, if done well, not only will that time be made up, but higher levels of management will likely take notice of the improvement. If respect isn't earned immediately at the ground level, it will certainly be won at a higher level.

Whatever the case, you can't expect to be respected for just doing your job. In a perfect world, reliably getting your work done on a consistent basis will win you respect galore. But our world is far from perfect, and the only way to avoid a case of Rodney Dangerfield syndrome is to avoid getting comfortable within the imperfections.