No one reads manual

In the thoughtful blog I'd Rather Be Writing, Tom Johnson says:

Not many (technical) writers consider the positive aspects of users not reading the manual. If you do a lousy job on the manual, or if some SME (Subject Matter Expert) discovers typos and inaccuracies, you can just laugh it off by saying no one really reads the manual anyway.

But consider the opposite scenario where everyone reads the manual. Is this a scenario you want? No. Because if everyone has to read the manual to figure out the product, it means the product is so unintuitive and user hostile it’s probably going to tank on the market and you’ll soon be out of a job anyway.

Also, if so many people are consulting the help, you probably aren’t contributing enough on the design/usability side of your technical writing role. Remember that you’re part of a team building a solution to a problem. You want the user interface to be simple and intuitive enough to not require a manual. So if only 10 percent have to consult the manual to figure out the product, that’s a good thing.

It is an eternal dilemma for technical writers. The better we are at our job, we have less to show as the result of our work. How? Let's take a look at the process of writing a user manual for example.

1. Start writing.
2. See potential pitfalls users might fall into.
3. Write about how to avoid them.
   
   That's it, if our job is to "write", it ends here. It's probably 90% of the cases. But as Tom says above, we are part of a team trying to present better "solutions" to the users, right? So if we really care about our goal and users, we should continue our work like this.
   
   
4. Go tell the developer that the product sucks can transform into the next iPhone and you know how.
5. Work with him to fix the product.
6. Product becomes one step closer to iPhone, users have thinner manual, less dead tree consumed.
   

(In reality things go differently, especially when we use the deleted word which is also 90% of the cases, but that's the subject for another entry.)

Sounds like a win-win situation for everybody, except for technical writers. Like any other writers, we want our works to be read. Just look for the technical writer in your office (yes, that grumpy guy that you tried not to notice subconsciously) and tell him that you think he writes really well. You just got a loyal buddy (though it might be a creepy one-way affair, it won't hurt to get one).
Note: yours truly does not fall into this category :) But I appreciate encouragement.

Good technical writers switch their mindset/career so that they become "solution providers" than mere writers - as long as the users are happy, they are happy. Some funnel their creative energy into another media (such as a blog on technical communication :). Some solace themselves by looking up to fellow martyrs; look at the cops, what they try to achieve is a society that does not need them. We constantly battle this internal conflict: no one wants to read what we write, including ourselves.

If there is someone reading this entry considering technical writer as a writing gig, especially a creative one, be ware: you need to redefine your idea of creativity--providing better solution is nothing but creative work, for example. If you think otherwise, name any instruction manual that won a Pulitzer. There are award-winning books that have been used as instruction manuals, such as From Beirut to Jerusalem by Thomas Friedman. But it's not going to work the other way around.