You are here

Finding My Voice as a Technical Writer

This past week marked my two-month anniversary at Canary Systems, in New Hampshire. During that time, I had to quickly learn their in-house software and update the content so that the help files and user's guide were current with latest features of the programs. In addition, I am in the process of helping them catch up with their 2014 and 2015 documentation by updating the user's guide to instruct readers how to use the software and some of its newest features. Soon, I will also update their help files, so that they give the users descriptions of what each form does in a particular program.

My biggest challenge, however, has been finding my voice as a technical writer. During my studies at the University of Massachusetts Dartmouth, I was ambitious and would sometimes flaunt my work's quality to my professors, colleagues, and fellow students, and their positive feedback reinforced in my mind that I was capable of any technical communication challenge. I became confident that I could use the skills I honed in graduate school in the workforce and I would enjoy doing it.

However, I found that the real world was not what I thought it would be. I was confident that I would be able to update the documents so that they'd be usable for the intended audience, and that they were current, with the approval of the president, software engineers, marketing, and information technology (IT), and I would be able to get started updating their documentation for the 2015 release. I found that what was acceptable by the head of IT was not acceptable with the software engineers who designed the program, and the marketing director also had issues understanding the instructions.

I was taken aback. I thought this would be a relatively easy process: I would update the document, send it to various employees for review, and they would give me timely feedback on it so I could finalize the document for upload onto our company website. Instead, I found that I had to work hard to find out what was missing from a document, go back and update it, so that it was complete and current to everyone's standards. As a result my original estimates for completion fell further and further behind. I'm a new employee, so there is some learning curve and adjustment period, but I felt that I should have finished old documents and started on new ones within a month of employment.

Later in August, two of our corporate trainers visited the office in New Hampshire. When I heard them voice user frustrations at a development meeting, I instantly become interested in what they had to say. After the meeting, I met up with them and we discussed usability issues users have with our software. They told me that our products are very capable, but those capabilities need to be shown to users in the best way. I also discussed how frustrating it was to receive feedback in an inconsistent manner, which they agreed with. I told them that I wanted to use their feedback in the future.

So I resumed my work, using my newfound inspiration from the corporate trainers. My next obstacle was establishing my voice to get the employees to sit down and review my work so that we could finally be current with our 2014 documentation. However, some information was still not correct, and one of the software engineers expressed frustration that I was doing more work than was necessary to update the files. I was working on the 2014 editions and some 2015 editions of the software's documentation. My boss, the company president, thought at least one of the 2015 user's guides would have been done by now. However, my delays with the 2014 documentation held me back.

I knew I had to do something to establish a base on how to move forward with the documentation. After I attended an STC New England Chapter event this past week, I found that "shotgunning" documents for review is not a good tactic. There needs to be a documentation cycle in place so that all parties involved know what the process is, and when they can expect a document to come their way for review. Inspired by this, I created a documentation cycle and a style guide to codify our document's appearances. I presented these in a conference call to the company president, one of the software engineers, and the head of marketing. They agreed that this is a good strategy to use going forward and if I can implement it, they will follow it, because they agreed that playing catch-up like the way we have for the past two months is not a viable long-term strategy. I found my confidence to take responsibility for my actions for the past two months, and foster a can-do attitude going forward to accomplish company goals. With that, I resumed work on the 2015 documentation and the first guide will be ready for final review next Friday, after working on it since late July.

In the end, I found my voice as an implementer. I had to channel the frustrations I had with my work and what I had with the documentation into a positive outcome. I effected change with my co-workers by calling for a conference call, where I presented the documentation cycle plan and style guide. When both are fully implemented, I expect updating the user's guide and help files will be a much smoother affair. I will also benefit from user feedback, as I want to include our corporate trainers in the review process, so I can take the documentation to the next level. Being assertive and voicing one's concerns to the right people is the best way to achieve that rhetorical situation that was the foundation of my graduate studies at the University of Massachusetts Dartmouth. I just had to find it deep down and bring it forward to change my work habits and attitude on the job into a positive one, rather than drowning in the negatives.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer