It happens.
Sometimes technical writers don’t do the job they are supposed to do. Failure can come from many different directions. Sometimes it is because a technical writer doesn’t have the right background. There is a whole debate, for example, about how technical a technical writer has to be. From my experience, the main limitation is not really the technical writer’s background so much as the technical writer’s ability to gather information and translate it to the user’s level.
Sometimes it is very beneficial to have  a very technical technical writer – and sometimes that can actually compound the communication problem between the technical experts of the product and the end-users. The answer is usually, “it depends.”
I have written and continue to write programmer’s documentation. I am not a programmer. I am not an engineer. I succeed, thankfully, because I learn very quickly and I listen very well. Engineers understand that they may have to explain something to me that they would not have to explain to a more technical writer…once. I catch on fast and when I do, I can usually write it more clearly and more accurately than most.
Another reason a technical writer fails is because they don’t listen to their “inner voice.” That’s that thing inside of you that wants to structure a document a certain way because you are sure it will be more clear; it’s that part of you that wants to argue with the product manager or even your documentation manager but you surrender to the opinion of others.
Other fail points include:
- Not acknowledging the impossibility of a deadline at the start of the project: sometimes a company will ask for the impossible. A lot of times, technical writers beat the odds and make the impossible possible. Sometimes, though, we are doomed from the start. No, we cannot create a 300 page document in one week, thanks for asking. No. By acknowledging the impossibility at the start, the employer or client understands that you’ll do your best, but…
- The changing tide – technical writers live in a world of shifting sand. A moving target. When we are lucky, we get information in enough time to shift with the product. Sometimes, we get the unpleasant news that…”oh, we decided not to include that feature in this release,” and “we actually only thought that with this minor modification, the product would be so much better. Sorry we forgot to tell you.” Great…doomed again.
There are so many other places where a technical writer can fail, but what I really wanted to write about is what happens after the failure. How you handle it defines who you are and your professionalism much more than the failure itself. Yes, it might be your fault and it might be the client/employer’s fault. But  at the deadline, you can save or lose so much.
One of our writers wasn’t working out. She wanted something other than what we could offer and, quite honestly, wasn’t really disciplined enough to work outside the structured environment of a technical writing team and full time manager. We knew this; she knew this and we agreed it was best for everyone if she moved on.
She found a job, but one of our clients really wanted us to have her finish something before our new replacement writer took over. They wanted; she agreed. Where was the failure?
She actually turned us down for the update and we were preparing how we could compensate the client. We had already offered to “swallow” the learning curve for the next project and more. Apparently, they called the previous tech writer and, upon hearing the request from our client, she agreed to do the work.
One of the reasons why we were happy she moved on was because, as I said, she wasn’t very reliable. The deadline came and went and she didn’t deliver the document. The client released the product with the old version; we sent in our new writer. And then, at the end of the month, the previous writer sent us a bill for 10 hours of work.
She sent us the updated manual she had done – we paid her on time…and then the client complained about her work and refused to pay. Long ago, I accepted that WritePoint is in it for the long term. We accepted the loss as gracefully as we could. The client is happy – our new writer is one of the very technical technical writers around and will likely complete the document in less time (and he actually is happy to work full time and meet the deadlines).
When the technical writer fails – someone has to deal with it. Sometimes it is the  technical writer…sometimes it is the technical writing company…sometimes it is the employer. The one important thing here is that it should never be the end-user.