Collaborative Writing and Reviewing

I follow Tom Johnson’s blog “I would rather be writing”. Tom points out quite correctly that one of the emerging trends in technical writing is collaborative writing and reviewing. It seems logically correct that when the turn around time for any software development is short, there are various writers who work on the same projects or rather write the same manual in parts. There may be several agile methodologies followed for the same project and one individual writer would be associated with one or more team to write about the features their team develops in due course of time. The writer’s job is to write the procedures and instructions involved with the features and finally that gets integrated in the final drafts when the software is getting released. But much before that the written contents pass through the technical reviews and the peer reviews.

One of the major factors I have observed is the process of reviews and the mindsets of the reviewers which differ from person to person. Believe it or not, in our settings the personal competence of the individual writer and reviewer differs immensely. The years of experience spent in the company does make you a senior writer or reviewer but that does not guarantee you to be the real senior in terms of your writing capability or reviewing acumen.

The similar temperaments are quite common among the developers and the testers who instead of validating the technical stuff encroach in the languages sphere, which at time becomes quite annoying. They would come forward bravely and suggest the sentences to be written the way they want. They feel that the way they understand even the common user would be able to comprehend. However, the interpretation of their own ability of the language comprehension is misbelieved and based on the misconception they carry in their mind. Their misconception is also supported by their own misguided belief that they understand the software or hardware to be developed much better than any technical writers. Undoubtedly the understanding of the technical nuances would be any day far more superior to any of the technical writers. Over and above they are the one on whom we depend to get the knowledge to write for the users to be educated.

This superior understanding of them does lead to form a basis of misconception which in reality is not helping the documentation. There are instances when the developers competence in language are far more superior than most of the technical writers. They are welcome to have their suggestions but should avoid verifying that their suggestions are implemented by the writers or not. After all it’s the writers’ choice, wish, and above all, the guiding principles of technical writing and style guide which a writer has to adhere to write the technical documentation. The role of developer should be to support the technical writers with technical knowledge transfer and not impose their own knowledge of language. Let the technical writers be their own masters.

Another flip side of the review is the peer review of the document by any of the colleagues or the team leads. Most of the time, the peer reviews are meant to reveal the missing elements in the documents and the suggestion would just say this is right or wrong, no explanation why its right or wrong. The underlying thoughts are to look down upon the fellow writers and not help the documents get value added. Then I really sometimes wonder why we say that technical writing is a team effort. The given instances do not really show any glimpse of team efforts rather it shows the individual perception of self proclamation of greater self. Does this really help the cause of documentation? Does this really serve the purpose of user? A badly written document would really reflect the bad image of the writer as well as the team for which the writer works. So, where is the so called team factor which keeps on going round in the circle? Truly when we say collaborative writing, its absolutely the team effort.

Therefore, to get the collaborative writing successful, a writer and reviewer will have to look beyond the individual goals and think for the common perspective of user interest. If the goal is not achieved then the document would look as if written by several writers as their own novel and compiled together. But the real meaning of collaborative writing is to achieve greater work in limited time period and the role of reviewer is to get the document be synchronize such a way that it should look that perhaps an individual writer has worked on it. It works really well but you got to believe in it and look beyond your self made selfishness tag to work towards bigger goal.

How can a Technical Writer add value to the IT Industry?

This was one of the questions in one of the Technical writing interview I faced in recent past. What should I write the answer? The first and foremost question! When you are pushed to the wall your creativity, competence, and skills play a vital role in salvaging your image of being so called Technical writer. As a common knowledge every technical writer facing such question would answer whatever they have heard from their pals, colleagues, and senior writers during discussion at some point of time. Then what distinction you have from the lot? You ought to be special. You need to think out of the box and answer and that should make you special if you want to be hired.

Out of the box! A really tough challenge to prove yourself that you can make a difference! A really tough proposition to prove your worthiness! The person who administered the test gave me enough of time to think and write my answers. Finally I could collect my thoughts and tried to put down on the paper.

Apart from the usual job of writing user manuals and WebHelp, Technical writers are best suited to help the organization to cut down their cost by means of their writing. How could they do it? When the product is launched in the market, the technical support teams are always available 24x7 to answer queries, questions and doubts of the user of the software and hard ware products. Based on the feedback received by the support team about the usage and difficulties of the users to use the product, they test the particular problem into the environment narrated by the users and try to address the problem and provide a resolution to the users. If the stated problem is inherent with the product, there ought to be numerous other hits by other users too on the same problem. And every time a support person will have answered them with the same resolution. Whereas, an article stating this problem and posted on the organization’s web site would lead users to first seek there resolution from this article rather then directly contacting the support team. In case, even the support team contacted, they will have ready answer to guide the user. The technical writers are best suited to do this job because of their language efficiency guiding the user by the procedures and steps to solve their problems. These knowledge based articles would help user a great deal according my understanding. If a series of problem hindered the users, probably a trouble shooting guide to a better job.

In some other instances, technical writers can be the brand advocates of the product donning the role of bloggers and blogging about the products to the organization’s web site or some other open source site. They can go to the different social networking sites and participate in the discussion and leave a note about the new product for the crowd to discuss. In case there are any doubts, negative impression and competitive issues with other similar products in the market, the technical writers would be in a position to address the issues in their clear and concise narratives.

These are two distinct roles which a technical writer can take up and add value to the IT industry by their worth of being a writer and truly a technical writer. Because whatever they are going to write is all about the technology and it is going to help the technology grow. This is what I thought and scribble in my paper during the written test. Although the exact words and sentences are not the same and I don’t even recall them. Call it my creativity or poor memory, but whenever I would try writing about the same it would be different language. However, it would mean the same.

But to my surprise, these were not the answers what the interviewers were looking from me. As I could see they were looking at same rut repeated hundred times by all the writers. They were not looking for a different answer, a different perspective, or some thing beyond the usual job. I uttered the same usual stuffs during my personal interview and I could see their relieved faces and a victorious smile stating we have nailed you. You have to be the same what we are and think the same what we think.

Little further they started inquiring about my authoring tool knowledge. I told them what all tools I have used so far for the authoring. They kept harping about the tool knowledge what I have not used. As if the tool will do the writing job and not the technical writers. Then what is the fun of interviewing the writers. Better interview the one who is the tool perfect person. A publishing specialist, who would do all the jobs except writing.

I realize that its not the writing or technical writing per se, its the job and the way you look at it. And so far we have been looking at technical writing as the display of authoring tool knowledge and not the writer who knows authoring tools to publish their work without the external help. Perhaps writing is the last thing happens in the technical writing job.

Therefore, if you are a writer and donning a role of a technical writer, think twice how you can add value to the IT industry. I am not sure but perhaps you might have some other way to add value what I failed to understand during the interview.