Technical writers – a necessary evil
August 18, 2006 • Glenn Murray
Technical writers are necessary because someone has to write the user doco. The programmers and managers sure as hell don’t want to. This is actually part of the reason that you’re evil, too. In my experience, most programmers and managers think that they could write the manuals if they wanted to… they just don’t want to. They might not write all “flowery” like the technical writers, but what they write is correct.
Unfortunately, that’s quite often all that’s important to programmers and managers.
There is a feeling within the software environment that accuracy = quality. Audience analysis, doco readability, consistency, usability, active and passive voice, commas in a list of three or more items… All of these things are relatively unimportant to everyone but the technical writer. Oh… and the user.
In a world where accuracy is all important, a lot goes over the head of the dummy. I don’t know if it’s intellectual snobbery, but programmers and managers seem to think that if they understand it, so should the user. It doesn’t matter whether or not they do… they SHOULD! Stupid users! Maybe it’s the geek’s ultimate revenge…
Your document can be 100% accurate, but if the audience can’t read it, you’ve wasted your time.
So why doesn’t anyone acknowledge this? They do! That’s the weird part. In theory, everyone agrees with you, it’s just in practice that you find yourself out in the cold. I don’t know why this happens. Maybe it’s because most of these guys have never done technical writing.
So technical writers spend too long worrying about unimportant things. And they bother programmers and managers with unimportant things. But they’re necessary things. Otherwise why would you be employed. Maybe the absence of simple logic short circuits their brains. Who knows?
What we can get out of this is that there’s a feeling that technical writers waste time, and as a result, they’re pretty much at the bottom of the heap in the software world. I think a good analogy is the way some rich see the poor. Dirty little creatures… if only we could do without them…
But there is an up-side. I don’t want you thinking it’s all bad.
Being at the bottom of the heap has its advantages. You can go unnoticed for years if you want. If you haven’t seen the movie, Office Space, you should hire it. There’s a little ferrety bloke in that who was “let go” years ago. Problem is, no one ever told him, and because of a glitch in payroll he still got paid. No one ever noticed.
Being a technical writer’s a bit like that.
When I was managing doco teams, my favourite saying was “All we have to do is manage their expectations and our commitments”. Because programmers and managers resign themselves to the fact that they don’t know what’s going on in the doco team, there’s sometimes a temptation to slacken off. Don’t give in to this temptation!!! If you ever get caught, doing it, it’ll be like the boy who cried wolf – they’ll never believe your estimates again!
The other risk is that you’ll lose your sense of urgency. And that’s a big part of what makes a good worker. You should be very strict about managing your commitments. This requires discipline, because sometimes it seems you’re the only one that cares, but you have to do it.
One thing you should be aware of though, is that your average technical writer in software spends only about 50% of his or her time writing. The rest of your time is spent planning, problem solving, fixing your computer, researching, interviewing the programmers, writing work pracs…
I always found it was a good balance, though.
It was when I started managing teams that the bottom really fell out. Then the percentage dropped to about 10-20%. There were times when I’d go months without writing any help at all. That can be very frustrating, especially if you don’t particularly like managing.
Now managing technical writers in software is an interesting thing. As with most technology management positions, you kinda fall into it, because you’re the most senior/experienced person in the company. Unfortunately, that doesn’t qualify you to be a manager. Software companies are renowned for dumping people into management roles without any real training or support.
I don’t really have any advice for you here. If it’s gonna happen, it’ll happen. Just be aware of it, and know that if you fall into a management role, it’s gonna be difficult. (That’s not to say that it can’t be rewarding though…)
The ironic thing is that the most difficult aspect of it is that your staff are screaming at you to change the system. “The programmers don’t answer our questions!” “None of my work has been reviewed for the last 2 months!” “The project manager just told me to forget about quality!”
Unfortunately, the inexperienced technical writer is often naïve enough to think they can change the system. Once you become a manager, you know you can’t. Hold on a minute… Maybe apathy is what qualifies you to be a manager… Hmmmm.
In any case, my advice is not to push too hard. You’ll make life hard for your manager, and give yourself a bad reputation. Recognise you’re a necessary evil, and work within those constraints.
Technical writing can be a lot of fun. And don’t let anyone tell you it’s not creative. Trying to think of a way to describe what goes in the Name field without just saying “Enter the name” is a real mind-boggler!