• 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

Putting the “I” in Team

By Laura Dahlinger

Being part of a team can be difficult from the perspective of a lone writer. As a lone writer, where does my responsibility lie for participating in the company or department? How alone am I or should I be? I make suggestions on how to bring the “I” of your lone writing experience to the team environment.

As a lone writer, where does my responsibility lie for participating in the company or department? How alone am I or should I be?

To begin with, no one ever works in a vacuum. There are always outside factors influencing a writer, from the software I use to write my documentation to the type of business I’m writing for. Writing documentation for using hospital equipment is much different from writing video game booklets. How we view the company and business we are involved in has an impact on the documentation we write.

Defining my position at my company was the most difficult part of my job as a lone writer. Sure, I wrote the online help. I also wrote the technical releases to customers, improving the processes for new releases and help for users and administrators. But is that all? I interacted with developers, asking them questions and pushing them for documentation and explanations. I tested software to see what a user would see. How can I use this and just how can I break it? That was always the fun part. I got quite good at it, too, breaking software.

So how can this all lead me to being part of the team? I am put in a job where I’m expected to be good at writing and a bit outside of every other department. Technically, I’m included in a department but I am not doing what everyone else is doing in that department. So I am part of the team, yet outside of the everyday work of the people in my department. Some of them probably don’t even know what I do!

In order to become part of the team, I had to insinuate myself wherever I could. I followed around developers, watching what they did and asking about the software they were creating. I worked with people in other departments whenever they asked me to, within reason. I’m not a secretary so I don’t take dictation or meeting notes unless it’s a meeting that is relevant to my job. I asked my manager how I could expand my role within the company and department, to assist other departments with their documentation needs. I kept the focus on my skills and pushed for more inclusion in different teams, especially the one I was assigned to.

Making contributions to the team could come from something as simple as having the good attitude in a meeting that everyone else is dreading. You know the purpose of the meeting your manager called is to berate everyone into doing a better job. You can come in with questions for the manager, to give details of how things can be approved. Force the manager to give specifics to the people on the team for improving the schedule/product. This may diffuse the tension enough for the meeting to go better without everyone getting defensive. Helping your coworkers survive a meeting by speaking up and asking the questions no one else wants to ask can help you be an integral part of the team.

If you notice any coworkers on your team or in the company having issues with the product, bring up any help files you’ve created to assist them. If you can divert their question to the help file, whether it answers their question or not, you are taking some of the workload off of your coworkers who that person would ask. If the question isn’t answered in the help file, you can investigate for them and include the information in any new version of the help file. In addition, you are teaching them to be self-sufficient—look at the help file first, then go ask someone.

Sometimes being part of a team can lead to unanticipated issues, such as deadlock on how to perform a task because the team can’t agree on how to proceed. As the “I” on the team, you can observe and offer suggestions from the outsider prospective. Frequently, as the lone “layperson” on the development team, I didn’t know what the developers were planning but if I couldn’t understand it, I would ask them questions to make it clearer for them and myself.

Individually you can participate in activities that will enhance your understanding of the product you are documenting. For example, if you are documenting mainframe software, you can take a class on mainframe, read a book on mainframe programming, or attend testing sessions for the software. 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.

There will always be people who assume that writing is easy and that no one needs to be the company technical writer. Nothing you can say will change their minds—only what you do! So bring your skills to the team that is your company or department, present your observations and solutions, and become a part of the team. An indispensable technical writer is needed by their team, no matter what that one person’s opinion!

Laura Dahlinger has been a technical writer for 6 years and has been working as a contractor for the last 1.5 years. She has a Master of Arts in English and a Bachelor of Science in Mathematics. She has been a member of STC for 4 years and has presented at a previous STC conference.