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.

Technical Writer as a User

The name technical writer suggests about a person who writes the technical documents for the user, which helps them using the product. More often than not, when the user struggles to find out the answers of their problem in using the product, they seek the help from the support group. Obviously, users don’t find the answer of their problems in the documents, which were shipped to them along with the product.

The standard procedure followed to analyse the user’s problem and leading them to learn the product to use are not based on the realistic approach. Neither feedback system revamps the standard procedure in the next revision of the documents. The revision only includes the recent addition in the features and functionality. But most of the time even users also do not like to send their feedback on the documents. May be because of the perceived idea that their feedback will not be taken care or the life cycle of the product is so short that they understand that revamps are not possible.

In any case, it does not help documentation to improve. Therefore, sometimes technical writers, who are to be blamed for the sub-standard documentation, finds even user responsible for this cause. In a normal scenario, a technical writer assumes to be a user and interprets the knowledge transfer in a best suitable way they can. But, that may not be the simple way of translating the knowledge what user would have liked to be. I really bet, the understanding level and approach of different users differ immensely. That is how, even the understanding and use of an authoring tool widely differs among the technical writers too. Some are easily able to use the tool, whereas some takes time to learn and use.

I can understand that each one of us has different learning curves and that reflects while even using an authoring tool. Nevertheless, when a technical writer struggles to learn the tool using the Help or the User manual and finds it tough to get their answers, even then they would not like to send the feedback to the corresponding writers group. If they do so, hopefully, it might help improve adding those points in the next version of the product that could help another writer avoid rigors of tough learning.

Ideally, it could be better to list down the questions, which could be included in the User Manual or in the Help and send across to the product company as feedback. And I suppose during the next version as an update even these new answers could feature into the document. Therefore, as a user, it’s a best way to help our fellow writers and help improve even the documentation on the community level. Otherwise, we will continue writing the documents as we usually do and get overwhelmed thinking that we have produced the best. But, in reality, we will not be serving the user, for which we are paid for. Its time we don the role of a writer when we are writing the manual and take the role of a user when we use a product. At the end of the day we should not forget to send and receive feedback which would lead us to help and get help on our documents.