Over the past two weeks, I reached out to my friends and ex-colleagues (read: non-technical communicators) and asked them the question, “What do you really think of the technical writing tribe?” I prepared myself for a volley of complaints and mails filled with angst against my fellow practitioners in the fine art of technical communications. I admit, I also secretly hoped that at least some of them would have some nice things to say.
Yes, there was the expected outpouring of emotion against our tribe but there was also appreciation. Thanks to all of you who responded (and thanks also to those who did not respond – I will bother you next time around too, without doubt). Yes, we technical writers can be real shameless at times – we refuse to take a hint.
I’ll cover the responses to that question in two blog posts – this one is devoted to the brickbats and the next one will cover the bouquets.
As I mull over writing the next part of this blog – one thing stands out – the list of compliments is shorter!
Yes, there was the expected outpouring of emotion against our tribe but there was also appreciation. Thanks to all of you who responded (and thanks also to those who did not respond – I will bother you next time around too, without doubt). Yes, we technical writers can be real shameless at times – we refuse to take a hint.
I’ll cover the responses to that question in two blog posts – this one is devoted to the brickbats and the next one will cover the bouquets.
- A normal human being and a normal technical writer can never be the same person. (Gulp!)
- There is very little justification to the term Technical in the title Technical Writer. Most of the times, it takes immense effort to help a technical writer understand the technical aspects of a product. (Sheepishly – True. But I have always thought that being non-technical is an advantage for us because that way, we can force all answers in black and white and present all facts in the same colors.)
- We have an attitude that we throw around. (Oops! Sorry. Do we really?) We behave like we are a boon to mankind. (Grinning broadly. Are we not? Even if in a teeny-weeny way?)
- Technical communicators are aliens because of these reasons. They don’t ‘speck’ the product, don’t code it, don’t test it, don’t sell it, don't use it, yet, they are instrumental in the success of the product. (Ahem - thanks but no thanks. It is true that we do not ‘speck’ and we do not code. But we do use the product and test it – we log bugs too. And, to my mind, after product managers, ours is the only group who can demo a product in its entirety – that is selling the product, right? To my mind, all these functions make us instrumental in the success of the product.)
- As a technical writer, when you are tasked with writing a user manual for a product the least you can do is use the product. If that is not possible because of the complexity, at least observe someone using it and ask questions. (And here I am, thinking people always make excuses not to meet us because we ask way too many questions!)
- Technical writers are not involved enough with the product – they don’t take enough ownership of the product. (I daresay, this statement has elements of truth. We are rectifying this anomaly by getting involved in the product development cycle right at the starting line - see earlier post.) The irony of taking ownership is that some people seem to think of us as one more reason for a delayed product release (which is empowering).
- Technical writers tend to think that their job is done once their deliverables (such as online help or user guide) are done. But in fact, a technical communicator must be answerable for far more critical questions – how accessible is the information to a user and is the user getting the help where he needs it. (True. Which is the reason why our deliverables are no longer limited to online help and user guides. We review every word in the English language that is up there on the user interface (page titles, section headers, instruction text, labels, buttons, error messages, and confirmation messages). We consider ourselves to be the first users of the product and point out where help is needed and how we can provide that help (embedded help, in line help, pop-ups).
- Most people do not have the same respect for technical communicators as they do for product engineering teams. This is largely because technical communicators do not understand the product inside-out. (True. But our challenge is not just understanding the product but understanding the developers as well.)
- All teams (read: all product engineering teams) face technical challenges, but the organization expects them to overcome these challenges. But technical writers are given plenty of leeway on this front. (True. And with a reason. If we were that technically savvy, we’d be coding. As writers, we are decoding! Jokes apart. This statement is true and is significant. I guess, it would be an asset for a technical writer to have a decent amount of technical know-how – but it can never be the main skill. The main skill for a technical writer is still his or her ability to communicate well and write well.)
As I mull over writing the next part of this blog – one thing stands out – the list of compliments is shorter!
Urmilla Chandran
The author is co-founder and Director, Content Development at Steta
The author is co-founder and Director, Content Development at Steta
