About a year back, I read a post, which shared a train of thought – that technical writers do a lot of stuff that doesn’t count as their part of work, but is still a part of their profiles. In the article, by Anna Parker-Richards, published in TechWhirl, she’s quoted:
“Technical communications overlaps with all the other fields involved in the software development lifecycle and often our job objectives dovetail with the business analysts, interaction designers, software architects, product managers, marketing specialists, and so on. We’ve branded ourselves as Jack of all trades, which is tricky to define, especially when some of us want to drive the user experience as leaders, while others just want to passively contribute. We’re an eclectic bunch.”
I agree with this thought: that as a technical writer I do a bit of everything: testing, support, marketing, implementation, or development. But, this thought raised a few questions in my mind. Who am I? Am I really the Jack of all trades? How do I tell my friends what I do? Can I ever define what I do? And, this is what I’ve found.
Quality assurance is more a promise than a statement. But, for me (as a technical writer), it is a mixture of both. I state what I do. But, first, I do it. I test the features of the product. I test my knowledge and observations about the product. And, I assure my readers with the results only if I have tested the product.
Thus, testing scenarios is not only a part of my daily work, but a qualifying criterion for me. First, I test records, and then I record my tests. This seems to match what Anaïs Nin has quoted, “We write to taste life twice, in the moment and in retrospect.”
In Product Development.
Tech writers can lend the developers with ideas that can bring solutions or workarounds to the issues that business users encounter. In my previous post, Questioning SME: Smart and Meaningful Engagement, I have discussed the techniques that people use to extract meaningful information from the SMEs. Every writer has his own technique; I, per se, use questions. And, my questions help me understand the product in better terms, and at times bring key issues to surface.
In his recent article, Mark Baker distinguishes technical writing as the mortar job from the other brick jobs, because technical writing does not have a well-defined structure. The job changes based on circumstances and offers freedom and flexibility. Again, the basic idea for any writing-related job, is that it overlaps/connects with the other jobs, and helps in developing the structure. And, I gleaned that when I had well-defined guidelines, the documentation was easier, useful, and consistent.
In Product Marketing.
Documentation speak a lot; especially about its company. Documents provide information about the product even before one begins the support function. As a writer, I try to know the product the way its developers know it.
In my current company as well as my previous stints, I have written the product documentation as well as the related blogs/social interaction, and it has helped the company a great deal; one: the information is consistent and accurate in both the places; and two: the time taken to create the documents is reduced considerably. Additionally, when the documentation guidelines are standardized, the content looks more organized and compact.
But, it is not necessary that if this technique suited me or my company, it will suit you. Also, whether a technical writer should look into the creative side of content is a topic worth debate. I think I will talk about it in my next posts.
A Support professional.
An access to the support tickets/calls/incidents can indicate you what is important for which customer. And, any module-specific documentation, which contains probable cause or possible solution of such incidents (For example, a troubleshooting guide contains details pertaining to probable cause and possible solution/workaround.) is of high-value for your customers and the Support staff.
In one of my previous stints, the writers would either interact directly with customers or access the ticketing system to get information about issues. Later, we would prepare the troubleshooting guide. We would talk about how they handled the screens and options, which would help us in getting the issues documented. Although it is true that no two people operate the same software in the same way, the issues they encounter can still be broadly categorized, which makes troubleshooting guides an easy way to resolve issues in the Support tickets. Our Support staff used those documents quite frequently to help customers get around, which reduced their service time considerably.
So, who am I?
We have seen that writers help the other jobs in getting the right information across. But, I agree that the larger part of us – as it appears – will still be only as good as the Jack of all trades. Although, deep down, as a technical writer, I aim to know as much as an SME knows.
Good writing in the words of George Orwell, is “like a windowpane.” Perhaps, the bigger picture of our profile, which is visible only from that ‘windowpane’, is that doing a bit of everything brings a great deal of advantage to us.
Like achieving long-term objectives, good documentation too is a team effort, which requires cross-departmental collaboration. This collaboration, in the form of information exchange, is in itself the most critical task. And, as a technical writer, I am happy to be the catalyst in that exchange.