Do not let yourself be a pushover!

-

    To not let oneself be a pushover is one of the biggest concerns while being a Technical Writer. There are very few people of your tribe in the company, and you may be the only Technical Writer when it comes to your project. People around do not have much understanding of the work you do. You are not as experienced with the product compared with most other people on the team. Technical Writer is not required to stick to a single product or domain. And these are the reasons that can make you a pushover too. Sometimes you may encounter negative attitudes of the people who think Technical Writing is easy.

We have the responsibility to assert the importance of Technical Writing. Convince people that you have a keen interest in the product and the domain. It is impossible to pretend this, and you need a keen interest in the product for others to see it. Your ability to understand people and the products is more important than the writing itself. You have to be the go-to guy if you intend not to be a pushover. Accept challenging work and try not to be someone who will require supervision. The most important thing is to get acquainted with the product and the people working on the product. Then study the current status of existing documentation and the tools used for creating and maintaining the same. Your immediate priority is to clean up any of the piled-up mess before considering any improvements to it. The results must show quickly for the people to start taking you seriously.

How to interview people and get information is one of the biggest challenges of our job. Join the project meetings, and get acquainted with the process followed for creating the product, and find out how to derive inputs from the same. For example, look into JIRA and Confluence and gather information from the same if the product team follows Agile methodology. Insist on having first-hand knowledge of the product as far as possible. It is good if you can install and play with the product to understand its features. There are some circumstances when it is difficult for a writer to have first-hand knowledge of the product, and the Technical Writer will have to rely on the information provided by the product team. The Technical Writer must analyze the information thoroughly without blindly accepting it. Verify if the developers' understanding and your understanding are mirroring each other. There are multiple ways to gather information, and the Technical Writer must explore all possible options and connect the dots to piece out the whole thing. You will not get all the information in one place. I sometimes look into external sources to understand the concepts and terminology. I search different topics on the net and gather ideas. 

Beware that you will impress when you do things that others can not. A project manager requests your help with the marketing whitepaper for a new feature, and you pleasantly surprise the team with the first draft in a quick time. They want someone who can design the landing page for the product, and you readily pitch in for the same. You impressed people by writing a whole new set of guides. You can design logos and graphics. Someone comes to you saying they do not know how to manipulate a PDF document and attach a file, and you quickly show how to do it. You make yourself a go-to person for the project with persistent effort, commitment, and willingness to help people. Like every other human being, you may err occasionally, but you have demonstrated enough skills and agility to be allowed a great degree of autonomy in your work.

I aim to style Technical Writing into an organization in itself, even if I am the only Technical Writer in the company. You love your profession irrespective of whether it happened by choice or chance. Technical Writers must have their pride of place in a company. Be your charming self. Be assertive and also be empathetic. And be dependable for people to come to you. Software and hardware products need Technical Writers to explain them to the users, and we are a crucial link in the product delivery chain.

Related articles:

The ability to learn is the key to survival. We can learn faster by learning from each other.

Comments

Post a Comment

Popular posts from this blog

YAML front matter in Typora

-
Image
     I was looking for ways to add a cover page, header, and footer in Markdown and just figured out how we do it in Typora Markdown editor. It is easy. Set the header and footer using YAML Front Matter. The YAML front matter must be the first thing in the file and must be valid YAML, set between triple-dashed lines.  Source: https://support.typora.io/ The following is an example for setting the document title, header, and footer using YAML: --- title: Agile Technical Documentation header: A Quick Guide for Agile Technical Documentation footer: ${pageNo} --- Apart from this, you need to make a few PDF export settings. Select File > Preferences > Export > PDF and select the checkbox for Read and overwrite export settings from YAMAL front matters . Now, the document exported into PDF will have A Quick Guide for Agile Technical Documentation in its header and page number in its footer. If you need a cover page as well for the PDF export, paste the following content in the Ap
Read more

Technical Writing essentials

-
Image
     I want to share some of my learnings starting from the beginning days of my Technical Writing career. Everyone in the project must have a cursory understanding of the following, and the Technical Writer must understand it in detail: Language standards Learn the style guides. MSTP (Microsoft Manual of Style - currently called Microsoft Style Guide) is among the most widely followed style guides. You can access it online for free and even download the PDF for offline reference. See https://docs.microsoft.com/en-us/style-guide/welcome/ There are several other style guides, but it is mostly enough to refer only to Microsoft Style Guide. The following are some of the key takeaways: Avoid passive voice - sentences in passive voice are generally longer and harder to read. Use only the simple and easy words understood by the global audience with varying degrees of English knowledge. Your writing must have the same meaning for all people from different geographies and cultures. Never use a
Read more

Apply Goldilocks principle

-
Image
     There is one thing universal about successful managers. They keep increasing the performance benchmark every time. It applies to an athletic coach who wants to make his trainee globally competitive. I have worked under cruelly kind managers who are very ruthless in getting the tasks done. They push you to improve your competency and skills every day. You may have had a tough time working under this manager, and still, it is not something to be resented. Weathers the pressures work? We start looking for ways to do things better when the competitive edge is so narrow, and even a marginal improvement in something will give you an edge over your competitors. I had my dilemmas over if harsh managers are good or bad. A good manager sets difficult but attainable benchmarks and allows members to execute tasks with relative autonomy. There is no use flogging a dead horse. Spend time grooming the people who are motivated to do their best. I have spent time with people who do not have enough
Read more