Technical Writing as a Career

Technical Writing can be a great choice for anyone who has passion for writing and has interest to learn and communicate information of the technical world—General Science, Engineering, Information Technology, Bio-medical industry, Aviation, Pharma & Drug Discovery and others into a structured format for the intended audience.

Technical Writers role existed almost in every product industry where they needed to communicate the product information to its internal stakeholders and customers as well. Everywhere either and an engineer, a product specialist, or a documentation specialist took-up this role.

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 its 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 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, anyone 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.

You are paid for your efforts

Most of us have transitioned into technical writing from a non writing career or from a different writing career. Obviously we try to gauge ourselves as a technical writer based on our English writing skills adhering to the different styles of technical writing. In the course of time we try to compete with our colleagues on better writing skills and try to position ourselves in the team and look for progression in the career.

This holds true if we are treated as a technical writer as an individual contributor. This also requires us to know all the other aspects of technical writing other than writing alone, such as authoring tool proficiency, skills to interact with the subject matter experts, and little bit of knowledge of estimation of the work and planning and meeting delivery schedule. However, having all in a person is quite a challenge at a time.

Technical writers’ jobs do not always require writing only. There are different kinds of documentation need and a technical writer’s work is driven by the requirement. For example, if a document is required to be re-branded, you hardly need to do any writing job. Similarly, if a document is to be updated for the revisions, you just need to write a few sentences or a few paragraphs to add into the documents. If the document is to be created into a different format your job is to use same content into the new format.

You are lucky, if you are associated with writing a new document wherein you can show your writing skills to your fullest capacity. Yet again, the document goes through several reviews for technical accuracies and language hygiene. This is done by other technical experts and fellow technical writer as a reviewer.

Although, the great job of writing of the document is done by a technical writer alone, but is it right to take entire credit for writing the document. For completeness of the document, others too contribute immensely.

Whereas, in a team setup, the competence and skills of all the team members are recognized based on one superior skill and team largely depend on that individual to fulfill that need. May be that person might not be a good writer, but he/she can be a good authoring tool specialist, a good trouble shooter, a good leader, a good technical person or a good graphic designer or a good communicator. Therefore, even for one deliverable, the efforts of all the individuals accounted equally.

Once, one of my colleagues said, “We are paid for our efforts.” As an immediate thought I realized that being a technical writer he is passing the buck and trying to cover for his incompetence in writing. Later, it haunted me loudly and reality seems to be true. The best of the work is achieved by team work and it consists of every team member’s best efforts.

May be, my freelancer friends would have different opinion on this but as a part of the team and working in a corporate setup, this is the reality.

Redundancy in User Documentation

End user documentation in software industry, to me, sometimes looks redundant. I have had the opportunity to work in few of the software companies which develop software application. As a part of the end user documentation, following documents are prepared to ship with the application:

• Release Notes

• Installation

• User Guide

• Web-Help

• Admin Guide

• Tutorials

The release notes specify different features and version of the software in the particular release, whereas the installation guide describes about the system requirements and stepwise installation procedures of the Software. Sometimes, it discusses about the architecture of the software too, for the better understanding of its compatibility with hardware and other software for operational efficiency. These are the useful information contained in these documents.

Admin guide is another document which takes you through the functionality and features that helps in administering the software. Sometimes, you, as an end user can act as an admin too. In another cases, like in enterprises solution software, there are different individuals who would be responsible for acting as admin.

WebHelp is another documents prepared as one of the applications, to be integrated with the software which comes handy to understand the functionality of the software. The content created with this application contains various web pages linked with hyperlinks with each other and can be navigated through a table of contents. In this, the contents are created keeping in mind the task based approach. Even the particular windows of the software can be linked with particular web pages which are called context sensitive. This entire application is integrated with Help menu of the top menu bar of the home page of the software.

Ideally, the user guides are created to take a walk-through of the software with the minute details. The approach is to focus on every bits and pieces of information about the structure and functionality of the software. However, some of the information contained herein are already discussed in the WebHelp. The tutorial again has the mixed contents of WebHelp and user guide.

Therefore, user guide, WebHelp and tutorials contain approximately 50-60% of similar contents. Some of the software application has exactly the same content in user guide as well as in WebHelp. Only the format of display is different. In industry, it is called single sourcing. The idea is to write once and display in different formats.

Can we call it as effective documentation? In my opinion, certainly not! Because end user find almost redundant contents in these document. The time is come to realize this and give the user the documents which is useful for them. Otherwise, tradition will continue as it is said that a user never reads or consult the documents shipped to them along with the software.

Truly, if user does not find the answers he is looking into the document then definitely he would never consult them. This throws open a question on our credibility of being a technical writer asking whether we are doing our job keeping user in mind or not. This also shows that we are writing a document which is not useful for the users. Well, are we only fulfilling a regulatory requirement or ready to help users?

Remember, being a technical writer we are also a user of the documents that we refer in day today life while working with different software applications. Incidentally, how do you feel when some of your questions does not fetch you answer from the integrated help or user guide on that product? You feel even disappointed when the topic is there but if it is not well explain to guide you to complete a task. You definitely blame the technical writers for sloppy job done. This is a great feedback for you to be self motivated to treat your user valuable and think of the documents which will help them. But not load them with unnecessary documents, which will make them dump these without even looking at them.

So, be creative and use your wisdom.

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.