Written a while back, but I have nowhere to put it right now...
I don’t mean to be alarmist, and I have no interest in being branded a Chicken Little (unless it increases my standing with my children, who have seen the eponymous movie). However, I need to call it as I see it. I’ve was involved in Technical Writing for over 10 years and I have had times where I was a member of the professional society for technical writers and attended seminars and conferences devoted to the profession. I haven’t been around forever, but I’m certainly not new to the game. After a great deal of study and though where I have watched the trends and analyzed what is really going on out there, I have concluded that Technical Writing as a profession in and of itself is now dead. I won’t even say that it is soon to be dead because that’s not true either. It’s dead now, Game Over.
That’s not to say that there aren’t people today making an excellent living and good reputations that have the title of Technical Writer. Even more importantly, I wouldn’t say that the skill set isn’t needed more than ever. I’d liken it to something like the advent of the word processor. When the first electronic word processors came along, it wasn’t that people no longer needed to know how to type, it’s just that no one needed typists any more. To say “I am a technical writer” today screams out to others that you are a one-trick pony. You are lumped in with typists, coopers and blacksmiths.
At one time, it was common for an English major to pick up a bit of lingo and some geek credentials and to embark upon a successful career as a technical writer. I’m sure there’s still a place for people like this, but today you are much more likely to find yourself a successful career if you’ve got extremely strong, specific domain knowledge in a particular area. For example, if you are a Java developer who also happens to be one of the very few developers who can also communicate well in writing, you might be the ideal candidate for developer documentation. Or maybe a networking professional that has some history of writing well and has honed their skill blogging might move into writing about a networking product full time.
A common model for technical writing as a profession pictures a really good writer sitting down with a really anti-social engineer and interviewing them as a Subject Matter Expert (SME). This model assumes that the engineer knows more about the technology than the writer, and assumes that the engineer can’t write. This is an expensive and inefficient way to do things because both the engineer and the writer must sit down together and consume 2x resources to get something done. We all know that our companies aren’t looking for us to spend more resources than we need!
Another problem with the common model for technical documentation is the assumption that our products will be very complex, very costly to purchase and use, and will therefore be used in their current state for a long time. For this reason, we create thorough, exhaustive documentation and put it through editing and production phases that make sure we don’t put out mistakes in documentation in print that will be used by a technician for 15 years to come. For the vast majority of technical documentation, this is no longer necessary. We’re working on products that will be completely out of date, or completely revised within the next couple of years. We aren’t going to print our documentation (and our customers don’t want us to!) and nobody particularly cares about our typographical conventions or our proper use of serial commas. They want accurate information on how to solve their daily problems, and they want it NOW. Two years from now, no one will ever read today’s information again. So why should we spend huge resources making this stuff perfect? We shouldn’t! Of course our company still needs branding and needs a good image of quality, but strictly perfect delineation between the usage of ‘may’ and ‘might’ is mostly lost on our customers as an aspect of quality even though it might affect how easy it is to understand what we say.