Technical Writing and the Domain Knowledge

Technical writers are often been questioned during the interview if they have worked earlier in the same domain or not. Even I have faced the same tune during my interviews on the previous occasions but mostly by those employers who have never shown any interest in my writing ability or my understanding ability of the subjects. For a writer, is it going to make any difference? If at all, it is going to make difference, the question is how much. Is there any one to quantify it? Interviewers possibly know this question much before they come across the candidate. The kind of work they have done previously or the companies they have worked for is enough to know about the domain a candidate has worked so far. Yet, this question is eventually asked.

I have not yet understood the real purpose of this question, may be the interviewers who are very much experience in the technical writing field can throw some light on this. Whereas I understand that technical writers are meant to work in a different setup at different times and they are basically writers who are by default supposed to clear up the mess in the writing and make it simpler and understandable to the readers. What happens if they have Domain Knowledge? Will their work be faster and smoother? I agree to some extent that writers will enjoy the comfort of knowing the subject well, and it will not be demanding either to spend much time in understanding it. But even if you are in the same domain, next time the topic changes, issue changes and the requirement changes. To cope up with all these one will have to spend required amount of time. Above all, can the writer be as knowledgeable as the Subject matter experts. The straight answer can be “no”. Technical writers can learn only some basics of the domain. That can be gathered during due course of time while working on the project.

So, why is this fuss? Is this a limiting factor for any of the technical writers to land up in any technical writing job before having domain knowledge? My answer is, it should not be. If it is so, then I believe subject matter experts will have to be the technical writers. Yes, but technical writers will have to be a fast learner and should have interest in learning things to present it to the audience what they are aiming for. In this perspective, it is right to have knowledge of your domain, which can always help you in understanding. But this is not the core requirement of a technical writer. The more years of work you put in some domain, the more you learn about it. But it should not become a constraint while you make a shift from one domain to another domain.

At the end of the day it is the choice of the technical writers themselves to analyze liking for a domain and if possible stick to that because that will eventually provide them some other opportunity in terms of career growth. Say for example, I have written for Telecommunication domain, Agriculture and now writing for Life Science products. My background is in life science and it gives me upper edge in understanding the business logic of the product but the work what we perform, does not require that much of specialized knowledge. For me this domain could be a liking domain and I may prefer to be in this domain and write about it. Similarly an engineer graduate who is into technical writing might choose to write more about hard core technology, a finance graduate might think of writing in financial product and management graduate can write about ERP and other related domain. It is all about likes and dislikes, which drives you to choose the domain.

This is one of the issues going round in the industry for quite some time and there should be clarity on this. Well, the necessity will definitely bring people to understand it by themselves. I remember there was a time when only engineers were in demand to be in the technical writing. But now the clout is out, writers can be found in any individual and of any background. Therefore, now the technical writers are from different backgrounds. Similarly the dearth of good technical writers will definitely wipe away the hypocrisy of domain knowledge, which some times block your entry into many of the good corporation. Early understanding would be the welcome step towards solving this issue.

Pitfalls of Technical Writing

The documentation need does not always grant good status and valuable position for technical writers in any of the product development company. Most often when you interact with the technical writers, they do not seem to be very much willing to let you know where are they heading towards in their career or they are happy about their role in the organization. The truth is that they themselves do not know what is their fate except the fact that they have a job, which is paying them well presently.

Ask most technical writers about their workplaces and you will likely to hear the same complaints. The developers do not follow any specs and never tell what they are up to. They slip their schedules by months, but the minute they are done, you are supposed to have the docs ready, like by magic. The developers and development team is the hub of activity and the core team in any product company. Obviously, this is. However, it is not only the team in the organization. If so, does organization not need other teams like testing, documentation and SQA team to work simultaneously. So, why is there a bias?

Worst over, most of the developers are bad in their verbal and non-verbal communication. If you learn their English, you forget yours and that is the end of your year’s toil of learning little bit of English. Yet, they will only meet the customer with their lanky, unshaven English language. The scenario is, you keep on changing the job and everywhere you go, you will witness the same thing happening. Moreover, many a times you report to your boss who does not have slightest idea about what you do and what it takes to do such job.

I remember, in my last company, a Software Requirement Specification document was returned to our development team with the comment that it contained 90% language error and it can not be accepted in its present form. We had to do the cleaning and correcting of the entire document to make it presentable. Yet, Technical writers are often struggle to prove their Return On Investment in absence of any established metrics for measuring it. Irony is that technical writers can make difference in any kinds of the document organization produce, be it client serving documents or archival documents, yet their importance is highly misunderstood.

The fact remains unimportant to many of the organization’s biggies that high quality documentation can make a big impact on customer satisfaction. It increases usage, gives more successful implementations, and creates better references and happier customers, which then drive more sales. It is an image-uplifting act which most of the organizations fail to realize. Good documentation can sell even product. You can have competitive advantage over your competitors of having high quality documentation.

Today, the ratio for developers and technical writers are somewhere 20 or 30:1. This is for the obvious reason if the bosses are Technical person they value that art more than anything. That also reflects the poor image one organization has toward it's documentation. Organizational chart does not show a progressive look to the technical writers. Many organizations have typically failed to sustain because of the dearth of enough documented archival knowledge, which helps most of the new employees to understand the background of the product.

Although technical writer’s whole job is about communication, they are sometimes the last to hear about future development plans or last-minute changes to a release. Truth is, Tech writers are good advocates for the user, always thinking about the user's point of view and they can make valuable addition in the development of the product.

Technical writers do tend to be the user's advocate, arguing for clarity and logic in everything from error messages to how features are implemented. But that's hard to do when you never talk to any customers. Even the customer’s feedbacks are shelved with customer support department, leaving technical writers imaginative on their own.

Technical writing is no black magic and if many feel, any one can become, they are wrong. English is no short cut, which can be learnt in a year or two like Java or C++. This field is in nascent stage and growing horizontally in sheer numbers. Today, technical writers are joining the band wagon, but it is not too far that these writers would be evaluating and weighing their career goal in terms of their achievement on vertical ladder. Future will hold the platform where technical writers will make it big or break.