The future of Technical Writing

Tue Jul 7, 2015

There’s this website that will tell you what the odds are of your job being automated in the future. The data for the estimate is derived from an academic paper where the researchers, I’m sure, are smug in the knowledge that robots will never replace university professors. Technical writers, however, will apparently not fare so well:

But then again, most technical writers seem to be the self-deprecating sort who suspect that their profession is perpetually sliding from obscurity into obsolescence anyway. Obscure, you say? Let’s not kid ourselves. Even our job title has been co-opted by the so called “tech writer”, who is actually not a technical writer at all, but a journalist who covers technology. We may casually call ourselves tech writers, but in the public parlance, tech writers are widely known as those guys who write at The Verge and Gizmodo.

This cartoon neatly sums up our awkward collective identity crisis:

Yes, we’re a humble lot - with a career that is not as “important” as being a doctor/lawyer/, and certainly not as lucrative, we’re not surprised nobody has heard of us, or even knows exactly what we do. Even our employers often see technical writers as nothing more than a necessary evil in the product development process, and there isn’t any career advancement ladder to speak of. So, we just naturally assume that the demise of technical writing is inevitable. As a case in point, see Neal Kaplan’s post: The death of technical writing.

I do agree with most of Neal’s points. Mobile software development will continue to erode the need for end user documentation, except for enterprise software and in highly specialized, regulated industries. And all the years of discourse focused on DITA at the expense of a proper business case was a waste of time.

If the definition of a traditional technical writer is just the person who writes the user manual, then, yes, I definitely agree that technical writing is on it’s way out. But Neal said it himself - he’s not just a technical writer, he’s a content engineer, customer support agent, information architect, content strategist, web designer, and technical trainer too.

Perhaps that is why we have an identity crisis - because there is no all encompassing job description that fits us all.

In any discussion on technical writing, somebody inevitably brings up ROI - how we can demonstrate value to the company, etc. I instinctively dislike this train of thought because I don’t understand why we have to justify our existence at all. Nobody questions the value of a software developer or product manager, they just hire them to do the job. The onus should not be on us to prove how our documentation process or single sourcing or whatever is saving the company money.

Indeed, no hiring manager would invite you in for an interview to pitch the case to create a technical writer position at a company. At least, I haven’t heard of such a ghastly thing happening. But sometimes, once the manual is done, the project ends, and the work of a technical writer is done. Unless the company requires constant maintenance of their legacy documentation - a position that is definitely becoming rarer these days. But all the same, lean and cost-effective content management will not save you if the work has run dry - it is you that will save you.

There is a lot of behind-the-scenes magic that most people don’t know about. Technical writers love to mull over things like the merits of the Oxford Comma or how well their writing fairs in the Flesch–Kincaid readability index. But although grammatical consistency and readability and so on help the end user consume information more easily, such benefits are accrued with a deft but invisible hand. It is hard to translate readability into cost effectiveness, or easily convince others of the importance of a well-placed semicolon.

But is is hard to deny that technical writers don’t play a multi-faceted and invaluable role within an organization when we end up taking on content marketing, product management, and user interface design. When we definitively save the company money by writing SRED reports. When we put the user experience first and advocate for the user both early in the software development process, and at the project’s end with ongoing customer training and support. Technical writers who aren’t afraid to embed themselves within niche areas and apply their expertise wherever it is fitting become so much more than mere writers - yes, they defy easy definition, but they certainly aren’t let go when the manual is done.

And the key skill that all technical writers possess can absolutely never be automated or easily dismissed: communication. I’ll be brutally honest: Communication is sorely lacking at most high-tech companies. You know that cliche of the quiet, socially inept software developer geek that is more comfortable talking to a machine than to people? Well, let’s just say that most cliches are based in reality. With our contribution to various parts of the product timeline, technical writers always have the big picture in mind, not just one line of code. A technical writer is the bridge between disparate departments; we facilitate, educate, and moderate. Here are some examples of where we can bridge communication between two parties:

1. Company → User (end user documentation, product training)
2. We can play a role in the reverse too: User → Company (product support)
3. Product Management → Developer (requirements definition)
4. Developer → Developer (API documentation - Tom Johnson believes this is where technical writing is heading)
5. Engineering → Marketing (use cases, white papers, spec sheets, etc.)

There will always be a need to good technical communicators to tailor information for a specific audience, and in doing so, bring an end to the broken telephones game that so many organizations like to play, and which often devolves into finger pointing when things go wrong due to poor communication. There will always be a need for a person who loves to soak up knowledge and learn, but remain an outsider who won’t resort to acronyms and techno-jargon when pressed for a simple and clear explanation of how something works. In these respects, I think the future for technical writing is looking bright, but at the same time, we must evolve.

I don’t want to remain stuck in the past, clinging onto old paradigms of what a technical writer should be. After all, I’m a user too. Who wants to read the manual before using a product? I don’t. I will freely admit that if a product is unintuitive or the user interface cryptic, then the product has failed. User documentation should be a resource to solve problems encountered after using the product. It should stop the user from reaching for the telephone in anger and dialing that customer support hotline.

I love the trend toward mobility and simplicity. I wouldn’t want to go back to the old days. Technical writing has a place in a future where usability and great design trumps complexity. And when you boil it down to its essence, technical writing is simply about relationships between people. About understanding people and communicating appropriately. It is a very nuanced, human skill and no robot will be up to the task anytime soon.