• meetings
• membership
• mentoring
• committees
• get involved
• articles
• about
• home

"Theresa, I got a referral from you last week and I've had a couple other people tell me you referred them to me. I just wanted to say thank you for that. Its very helpful in my line of work and I do appreciate you taking the time to give my name and contact details to people." Lisa Zeller, Spherion Recuiter.

© 2008 DigitalEve Columbus. All rights reserved.

articles

Hats of a Different Color

Lone Writers as Super-Employees
By Laura Dahlinger, with permission of STC Intercom magazine

Life as a lone writer can be intensely busy, wherever you are. You are frequently called on to perform non-writing tasks in order to assist the company in other endeavors. As a lone writer, you sometimes have to be a “jack of all trades” in order to make things happen.

I was a lone writer for four and a half years at a small software company. I got my foot in the door for my first technical writing job and I never looked back. I helped to test the new software, worked on the support phone lines, and generally assisted other employees with software and grammar questions.

The things I learned to perform my secondary jobs allowed me to better communicate about the software and still keep writing as my primary focus. When I started at ABC, I was a novice at technical writing and server systems in general. I had helped others with issues at my previous company but it was mainly about where files were stored and keeping things going with Word. After I started at ABC, I realized that I had a long way to go before I completely understood the software and how technical writing fit in at a small company.

I was put on the support phones within the first year on the job. To do this took a lot of hard work for me because answering phones was very stressful for me. But I did it and I discovered a skill I didn’t know I had—being able to communicate with the customer on a friendly level. At first I was intimidated by the amount I had to learn to be able to troubleshoot software issues. I didn’t understand client-server based software, nor had a clue what that actually meant. I depended heavily on the expertise of the full-time support
person, Todd. He saved my sanity.

My experience as a lone writer performing other tasks within the organization opened my eyes to how I could expand my visibility and value within the company. Here’s a few of the things I learned.

Lessons Learned

Keep the lines of communication open. Always be willing to ask and answer questions.

If you focus on a problem to the exclusion of all else, you tend to get bogged down in that problem and frustrated with it. If you can’t solve a problem within 5/10 minutes, start using your company resources and ask around for help.

Asking for help does not always mean simply saying “I don’t know how to do this.” It can be as simple as that but it can make the other person less able or willing to help you. Instead, consider the issue so far as you understand it, what you’ve already done to try to fix the problem, then go to someone with a specific question. “How do I get the software to link up to the email system through POP3?” will get you on the fast track to an answer.

Support people don’t know all the answers but they sure as heck are a great fountain of knowledge about your product! If you answer the phones and emails every day as part of your job, you run across a lot of issues that you already have researched, at least partially, and have a lot of historical knowledge that can help the writer in a jam. If your developers or SMEs are not helping you understand something, ask a support person!

Developers, as a rule of thumb, do not want to answer questions about their code if you don’t know what you’re asking for. Test the product out, if possible, or at least read their design documents. You will be able to communicate with developers much easier if you do. And they generally don’t mind answering questions about their code, all personality issues aside. You just have to be able to speak on their level, which can be frustrating if you know very little about coding. You need to be able to write about the end result, not to the code itself.

If you don’t have the ability to test the software, get it! I found that testing the software against the design document was invaluable for understanding what new functionality was available. The client-server software I dealt with I could not test, but the internet-based software was readily available. And I tested on my own, as well as participated in QA testing for the software.

Participate in activities that will assist in your understanding of what you document as much as possible. For software, that means testing sessions. For manufacturing, that may mean going to sites and looking at machinery and how it functions. As a lone writer, you have to get hands-on, as much as possible, in order to write about the product so the customer can understand how to use it.

Try to get the best working environment possible. This may mean that you need to communicate more thoroughly with your manager about your needs. You may not have any options currently for that quiet writing area but they may know about a room you can sit in or if there’s a reshuffle of offices in the cards, you may be able to get to somewhere quieter, or be allowed the use of headphones to block out the sound. You may also be surprised how much a decent chair, keyboard, and mouse can help you write more comfortably for longer.

Cultivate good working relationships with other people in the office. You never know when you may need to get information from someone. Occasional gifts of food or even having a bowl of candy at your desk will encourage others to stop by. I would buy office toys about twice a year and get a foam stress ball or something equally fun for everyone on the support team, including the support manager. It was my way of saying thanks for helping me learn. Food is always a bonus.

There are those people who just assume that writing is too easy and no one should be the company technical writer. Nothing you say will change their mind, only what you do. Human resources should know what you do is important. If they don’t, martial the numbers or evidence that you can and bring it to their attention. There could be a manager/co-worker who doesn’t understand what you do. Try to make them aware of your abilities so you can be part of the team.

Choose your direction in the company and go for it! If you want to be more support-oriented, try to help the support people with problems by creating documents of standard issues and fixes for them. If you want to help out marketing, offer to assist them with their press releases by editing or creating them. If you want to work with developers more, learn what you can about the tools they use to write code.

Expand your skillset to match what the company needs in a writer. If your company uses databases, pick up a book at the library on the correct type of database or take a class on it. Even if you don’t finish the book, the information you pick up about servers, databases, whatever it is the company uses/creates, you will be able to improve your documentation because you understand the basics.

Conclusions

Perhaps these seem like obvious things to do but it can be hard to remember what to do since you are alone and very busy writer. You’re frequently going 15 directions at once, helping this department and putting the project together for this manager. As lone writers, we are often called upon to manage our own documentation projects as well as write for other departments and projects. This is all part of the stock and trade of being a lone writer. Learn your resources and use them, including the Lone Writer SIG through STC, an invaluable resource for answers from others in a similar situation. Being a lone writer can be frustrating at times because of the “lone” part of job title, but it also allows us to see the results of our efforts and be able to say “I did that” with pride.

Biographical Information

Laura Dahlinger is a contractor currently working for Quick Solutions, Inc. Previously she was the lone writer for a small software company in the Columbus, OH area, documenting consumer relations management software. She may have moved into a group of writers but she will never forget to appreciate her roots and hopes to someday be a lone writer again.