Technical Writer - Part Business Analyst, Part Reporter, Part Translator
To be a good technical writer, you need a variety of skills in your arsenal.
1. Be a good listener. You need to listen to your subject matter experts (SMEs) and your users. I often see folks in meetings playing with phones or checking email. You can't capture information if you aren't paying attention.
2. Be a scribe. At the information-gathering stage, you don't know what information will be valuable. Write down everything. You'll take more notes than you will need, but that is better than having to ask someone for the same information over and over.
3. Be a reporter. Ask questions during the information-gathering session. Make sure that you understand what is being said. Ask for clarifications. Be careful not to derail or take the conversation off-track. Know what can be discussed effectively in the group and what needs to be taken care of outside of the meeting. You don't want to be perceived as wasting the SME's time.
4. Avoid being perceived as a pest. You have a job to do, and you need information from busy people. But you shouldn't dog your SMEs relentlessly. Try to organize your questions. Find the method of communication that works for the current situation. I prefer that folks send me a list of questions by email. I'm able to answer them in between other daily tasks. Others prefer phone calls or instant messaging. Ask your SME. (When I get complaints from SMEs about technical writers, it's usually because the writer is hounding them, and they don't appreciate six phone calls about the same thing in one day.)
5. Be creative. Sometimes, it's hard to get feedback or reviews from SMEs. They're busy, and your request is just one more in the pile. (And documentation is often at the bottom of the pile.) Find out what your SME likes. Sometimes, "bribery" works. (The developers on my last team liked Starbucks, ice cream, and cookies. I'd bring a snack for the group at information-gathering sessions.)
1. Be a good listener. You need to listen to your subject matter experts (SMEs) and your users. I often see folks in meetings playing with phones or checking email. You can't capture information if you aren't paying attention.
2. Be a scribe. At the information-gathering stage, you don't know what information will be valuable. Write down everything. You'll take more notes than you will need, but that is better than having to ask someone for the same information over and over.
3. Be a reporter. Ask questions during the information-gathering session. Make sure that you understand what is being said. Ask for clarifications. Be careful not to derail or take the conversation off-track. Know what can be discussed effectively in the group and what needs to be taken care of outside of the meeting. You don't want to be perceived as wasting the SME's time.
4. Avoid being perceived as a pest. You have a job to do, and you need information from busy people. But you shouldn't dog your SMEs relentlessly. Try to organize your questions. Find the method of communication that works for the current situation. I prefer that folks send me a list of questions by email. I'm able to answer them in between other daily tasks. Others prefer phone calls or instant messaging. Ask your SME. (When I get complaints from SMEs about technical writers, it's usually because the writer is hounding them, and they don't appreciate six phone calls about the same thing in one day.)
5. Be creative. Sometimes, it's hard to get feedback or reviews from SMEs. They're busy, and your request is just one more in the pile. (And documentation is often at the bottom of the pile.) Find out what your SME likes. Sometimes, "bribery" works. (The developers on my last team liked Starbucks, ice cream, and cookies. I'd bring a snack for the group at information-gathering sessions.)
Comments