All About 30 Poems in 30 Days

30 Poems in 30 Days is an Internet writing project. It is an attempt by myself, and anyone who wants to play along, to write thirty poems in a month. As part of the project, I will be posting an article about poetry every day. At the end of the article there will be a poetry writing prompt. The prompt is there to help. There is no requirement that you follow the prompt. I may not even follow it myself. The goal is simply to write poetry. This project is similar in some ways to National Novel Writing Month (NANOWRIMO). In fact, this year I have adopted a clever acronym – PD30 (pee-dee-three-oh).

How does PD30 work?

Every day in September I (or a guest writer) will post a short article about a poetic concept, a poem, a poetry form, the poetry world or a poet / group of poets. I will follow that with a poetry writing prompt. The prompt may be related to the subject of the article, but it may not be. As a participant, I would like you to either post a poem or at least post a note saying that you wrote a poem and perhaps include a line or two from the poem. It is also nice to comment on the poems that other participants have written. Additionally, because some writers do not want to post their poems publicly (for a variety of reasons) but still want to participate, I have created a private workshop. To get an idea of how this works, you may want to look as last year’s project.

Do I have to write a poem every day?

No. The goal is 30 Poems in 30 Days. Some people write in batches, other people write every day. As the moderator, I prefer daily postings because it keeps the conversation moving, but I understand that different people have different styles of working.

Do I have to do them all in September?

No. Once the posts are up, they’ll be there for the foreseeable future. You can start and end at any time. Do not expect, however, to have very much feedback after September because most people will have moved on.

I really, really, want feedback. I need to know if I’m any good. Will I get lots of feedback?

First, stop worrying about how good you are and just try to enjoy the assignments. Second, like any group project, the way the project develops depends on the group. If there are people who love to comment, that will be very helpful. I can’t guarantee feedback though, and I can tell you that begging for feedback rarely helps. It tends to annoy people.

How can I access the private workshop?

You can use my contact form to send me a note asking to take part in the PD30 private forum. I will then send you further instructions.

Is the private workshop better than the public posting?

I really have no idea. It is a new experiment this year. It may turn out to be where all the action is or it may be as dead as the careers of VH1 reality show participants. A forum is really only as good as the people who participate in it. There are a few tools in the forum that are nicer than comment tools. There is also less risk of your poem getting caught in the spam filter. Participation is really what will make the difference though.

Can I join the private forum but still post my poems in the comments at poewar.com?

Of course! I would be thrilled to see people participating in both places.

How Technical Writers Gather Information: Going to training sessions / meeting the trainers

If you want help creating documentation, get to know the trainers. I am frequently amazed at how little communication some companies have between the training and the documentation departments. In many cases, the training departments develop their own materials – existing as a completely separate unit. This can be an enormous waste of time and money. More than once I have sweated over creating a procedure, only to find out later that it was already in the training materials.

Trainers not only get to know the company’s products, they get to know the customers. For many (shortsighted) companies, the trainers are the closest thing you have to a usability team. They walk through the product in front of the clients, who inevitably have questions about the process or come up with scenarios that point out the limitations of the product. On the flip side, documentation people frequently have information that trainers can use. I am often in the position of telling a trainer that a change in the product is coming. For those trainers who do create their own materials, I always try to provide any editing or formatting assistance they may need.

I attend as many training sessions as I can fit in my schedule. I rarely turn down an opportunity, even if I have been to the training before. When possible, I record the trainings so that I can listen to them later. In some cases, company rules prevent this, but if you can record a training session, do it. One of the benefits of this is that you capture knowledge that could easily disappear if that trainer leaves the company.

Tips for attending trainings:

• Trainings can be dull. Bring a caffeinated beverage or energy drink, just in case you start to drift off.
• Make sure you keep whatever training materials are given out, and get electronic copies if possible.
• Invest in a digital audio recorder. You can then download audio files of training sessions directly into your computer.
• Know your role. In some training sessions, especially client training sessions, you may need to be a silent observer. In other training sessions you will be able to ask any question you want. Check with the trainer beforehand.
• Some trainers are willing to schedule one-on-one training sessions that you can use to take notes and ask documentation-related questions that might otherwise be distracting in a classroom. This also allows the trainer to practice in a lower-stress environment.
• Share your own information with the trainer. Cooperation will help both groups.

Does anyone else have tips that they would like to add?

Part Four of a Series:

• Part One: How Technical Writers Gather Information: Attending / Holding Meetings
• Part Two: How Technical Writers Gather Information: Interviewing the SMEs
• Part Three: How Technical Writers Gather Information: Using the product

How Technical Writers Gather Information: Using the product

Getting to know a product is one of the keys to documenting that product. You “walk through” the various features and procedures and document them as you go. In some cases this is easy and in other cases it is difficult. Sometimes the product you are documenting does things that are outside of your level of experience or are based on complex sets of data and configurations.

For example, documenting a word processor gives you plenty of opportunities to explore. You can wotk with all of the standard features. Some of the more complex features may require specific information or applications, but every feature and is available (or should be). Additionally, because you are a writer, a word processor has you as one of its target users. Most of the features are ones that you would want to access and understand as an end user and that the applications designers would want you to access and understand.

Some products aren’t as easy to play with. For example, let’s say that you are documenting a program that links merchants, independent sales organizations (ISOs “eyesos”) and banks to a credit card processing system. Because you are a technical writer and thus are not a merchant, ISO, or a bank, this is not a program that has you as a target user. This means that the processes and features are not aimed at your skill set or goals. Much of the information you need to complete the tasks may not be readily available or easily replicated

If an application like this were being used to board an actual merchant, that merchant would have at least one merchant point-of-sale (POS) terminal to add to the system. There are dozens of different POS terminals that a merchant may choose from, and each has different data sets to be loaded. Some users may only be using the system for authorization and capture (front-end processing) while others may also use the program for clearing and settlement (back-end processing). For an extra, added level of difficulty, assume that the merchants, the ISOs and the banks all see a different version of the program, and that each may have any of 31 different configuration options that could change what they see on the screen. Also assume that you cannot use live data because that would give you access to sensitive information about a company’s finances as well as thousands of user’s credit card numbers. All of this, of course, assumes that the program is complete and operational when you are documenting it. Often features only become fully operational a week or two before the product rollout – which is about the time that the documentation is supposed to be available.

As you can see, while using the product is a key way to document the program, it can be difficult. Sometimes you have to use “dummy” or “scrubbed” data that has been designed to simulate the information you might actually use in the program. The problem with this is that dummy information is not real and it is not flexible. It can make accounting for every scenario difficult. In many cases, this is why you see documentation that is general and does not address all of your problems as a user. Often there are just too many scenarios and possible results to document.

Here are some tips to help you walk through a product:

• Get as much information beforehand as possible. You can often access functional designs or testing scripts that provide the process steps for you to work with.
• Consider the different types of users a product has and the different needs those users have.
• Try to simulate the actual user’s experiences and data as closely as possible.
• It is often good to walk through the program with other users or SMEs so that people with the appropriate knowledge or goals are on hand.
• Make mistakes. It is good to know what will happen if the user doesn’t do what they are expected to do.
• Take screen shots of applications while you work with them. You may or may not be able to use them in your documentation, but at minimum you can refer to them at times when you do not have access to the product.
• If something doesn’t function as designed, let the appropriate people know. Different companies have different processes for this, but sharing that information is vital to making the product work.
• Try out similar products if you have access to them. It is good to see how other products work with a user’s needs.

Does anyone else have any tips to add?

Part Three of a Series:

Part One: How Technical Writers Gather Information: Attending / Holding Meetings

Part Two: How Technical Writers Gather Information: Interviewing the SMEs

How Technical Writers Gather Information: Interviewing the SMEs

Subject Matter Experts (SMEs / Smees) are resources who have expertise in the product / subject you are documenting. Many people within a company become SMEs for various reasons. Business analysts, program analysts, engineers and designers are often the people who create the design for a product or request the changes that will be made to a product, so they become SMEs. Programmers write the code that makes a product run, so they become SMEs. Trainers teach people how to use the products, so they become SMEs. Testers make sure the product operates properly, so they become SMEs. Technical support works with people to solve their problems using the product, so they become SMEs. If you spend enough time documenting the same product you may also eventually become a SME.

Most SMEs are technical people, but many of them are not skilled at explaining how things work. That is one of the reasons why technical writers get hired in the first place. Technical writers explain things that other people either haven’t got the skills to explain, or haven’t got the time to explain. That means the technical writer has to talk to these people and get the information out of them. This isn’t always easy, but it is generally necessary.

In many cases, SMEs are very busy. Getting a second meeting with them may be difficult, so prepare as much as possible for the first meeting by getting to know the subject, figuring out what questions to ask and having any necessary materials ready. Here are a few more hints to help you get the most out of a SME.

1. Bring an audio recorder. This doesn’t eliminate the need to take notes, but it does give you a backup. Most people speak far faster than most people write, so having the recorder makes it easier to go back and get information.
2. Ask questions that get the SME to address your needs as a technical writer. Here are a few starters:
   • What does a first time user need to know about this?
   • What does an experienced user need to know about this?
   • What is the process for completing the task?
   • What happens if the user makes a mistake?
   • Are there any other parts of the product/documentation that will need to change because of this?
3. Be courteous even if the SME is not. An angry SME is a real pain in the neck.
4. Bring snacks / bribes.
5. Follow up with an email that restates the information that the SME gave you so that they have a chance to make changes and so that they will not be able to claim they were misunderstood.

Does anyone else have any tips to add?

Part Two of a Series:

Part One: How Technical Writers Gather Information: Attending / Holding Meetings

30 Poems in 30 Days set for September

I have been giving the 30 Poems in 30 Days concept a lot of thought. I’ve have had a moderate number of people say that they are interested, and that is encouraging, but as several people have pointed out, writing form poetry isn’t easy, and to pull off 30 forms in a month is too much to expect from just about anyone.

I have also had a number of people indicate that they would be comfortable following along “at home”, but they aren’t comfortable posting their poetry in a public forum, either because they aren’t confident in their poetry or because they are afraid of theft. I am unafraid of theft or public embarrassment (I sing karaoke) but I can sympathize with those of you who are.

For those reasons, I have decided to go with a more simple structure. I, or a guest writer, will discuss a poetry topic every day. That topic could be a form, a concept, an author or an experience. At the end of the post I will include a writing prompt. The prompt will not be binding. You can choose to follow the prompt or follow a whim. The prompt is just there to help you along.

All I ask is that you do one (or more) of the following in the comments:

• Post to say that you wrote a poem (or didn’t) and perhaps give your opinion of how you did
• Post an excerpt from the poem you wrote (just a few lines to show your approach) so that people can get an impression of your work
• Post your poem in its entirety (for the especially brave)
• Comment on either the topic or on other people’s poems (respectfully)

The point is that this project only works if people participate. Writing 30 poems in 30 days (or writing about poetry for 30 days) isn’t an easy task. I have to accomplish BOTH of those tasks. People (including me) need encouragement. No one expects every poem to be great. The important thing is to try to stretch your abilities as a writer.

So, I will move forward with the project. I hope that people will give it a try. Don’t quit if you get behind, just pick up the next assignment and run with it.

Final Note: For those of you who have volunteered to write a guest post. I am interested, even if I haven’t gotten back to you personally. I will do my best to contact you soon.

A Career in Technical Writing: Amanda

Bullet Points

• Third-party personnel recruiters work with companies that are searching for one or more employees.
• Third-party recruiters work on a commission basis, with the commission typically amounting to about 20 to 25 percent of the employee’s first-year salary.
• Third party recruiters are put in the delicate position of having to reconcile two sets of interests, those of the company and those of the candidate. In most cases, the interests of the company win out because the company is the one that pays the recruiter.
• Third party recruiters often have specialties, such as finding executives or technical employees. They may even specialize in very specific niches such as finding C++ programmers or engineers with government security clearances.
• Never work with an employment agency that charges you a fee.
• The song Amanda, by the band Boston, was their biggest hit. It reached number one on the singles chart in 1986.

The feeling takes so long to grow

After the contract with the megacorporation ended, the job market hit a short-term slump, at least locally. I had only one real suitor for a new position. It was a start-up out of Silicon Valley called eStamp. We had a slow courtship. I heard from them about every two weeks. The first call was from a recruiter, Amanda. Amanda was enthusiastic. She made the job sound fantastic and my chances sound great. The company she represented specialized in online stamp / mailing label sales. They needed a lead technical writer with strong web skills. Amanda liked my resume and my web site, so she decided that I was the perfect fit. The job paid a lot of money, $87,000 a year plus 1000 shares of stock per year for four years. I understood that the Bay Area housing market was pricy, but this seemed like enough money for me to live comfortably on and I liked the idea of moving to the nerve center of the geek universe. I also liked the idea of having a full-time job rather than a contract.

About two weeks passed before I had my first phone interview and another two weeks after that the company called for a follow-up interview. Both interviews went well, so they decided to fly me out to meet the crew for one final round of interviews. The trip took about two weeks to set up, of course. When I got there, everyone seemed enthusiastic and I came away feeling good. After the xenophobic atmosphere of the megacorporation, this little startup seemed downright friendly.

I’m gonna take you by surprise

Once I got home, however, another two weeks passed before I heard from them. Eventually, Amanda called to let me know that they wanted to hire me, but they were dropping their offer to $77,000. They wanted me to prove myself before they made me lead technical writer. It was a bit of a slap in the face. I had never had anyone cut their offer before.

If there had been any other opportunities brewing, I might have turned their offer down, but I needed work. I didn’t have any money left in my account. I told them that if they were going to drop my pay, then I needed a relocation allowance get me out there. At first they didn’t want to give it to me. They didn’t like the idea of laying out any money in advance. The company eventually agreed to give me $2000, but they wanted to put restrictions on it. The main sticking point was that they wanted the money back if I didn’t last at least six months. I was perfectly willing to give the money back if I quit, but I would not agree to repay them if they fired me or if I was laid off. Amanda was unsympathetic. She accused me of plotting to use eStamp to get to California where I could get a better-paying job. I explained to her that I was happy to repay them if I quit, but not if they decided to get rid of me. They were two separate issues. She told me she didn’t see the difference, but she would take my demand to them anyway. It was frustrating, and the days kept passing.

Tomorrow may be too late

I was about to cave in. I needed the job. I began to pack my stuff and I even signed the contract, but I left it on my desk rather than fax it to them. Amanda was supposed to give me eStamp’s final word on my request by the end of the day. I had decided that, no matter what their final offer was, I was going to take it and give the job my best shot.

At about two o’clock that afternoon, I got a phone call from a different recruiter – a local recruiter. This recruiter said she represented a major computer company that needed a new writer by Monday. I told her that was great, but if they wanted me, I needed an answer within three hours because I had another offer I was planning to take. Within ten minutes I was on the phone with the computer company’s technical communications manager and one of their writers. Within an hour my fax machine was spitting out a contract for a brand new job. Instead of heading blindly to Silicon Valley, I would be driving twenty minutes to a research park on the southeast side of Tucson. It was a contract job, and it paid less money, but I wouldn’t have to move.

I don’t wanna lose you

Amanda called at about four o’clock that afternoon. She was abrupt and irritated. She had decided to take a hard line with me. “They aren’t going to give in on this, so I need your answer now, yes or no.”

I took a breath. “I guess this isn’t going to work out then. Thank you for trying.”

“WHAT?”

To say that Amanda was upset would be a gross understatement. Amanda screamed. Amanda pouted. Amanda argued. It got even worse when she realized I was taking a position that paid less than their offer. I explained to her that this job didn’t require me to move. I could keep paying my dirt-cheap Tucson rent, so financially I would be better off. At some point Amanda started to cry. She accused me of leading her on. She called me a liar. She begged me to change my mind.

I stayed calm. I reminded her that eStamp had dragged their feet for almost two months. They had even dropped their offer. Once Amanda realized I wasn’t going to change my mind, she demanded that I call the manager at eStamp myself to tell her I wasn’t taking the job. This is not the sort of thing recruiters make applicants do, ever, but I agreed to do it just to get her off the phone.

There’s something I just have to say

I called the manager and let her know I was taking another job. The manager took it in stride. “This is the Silicon Valley,” the manager said, “it happens all the time. I don’t know why she was so upset.” The manager wished me luck in my new position and that was that. It was a strange day. I was thrilled to have a new job (and a local one at that) but I was also emotionally drained. I had never had a recruiter go through a meltdown before.

I was once again a gainfully employed technical writer. I had gone from a megacorporation to an even larger company. It was a company that had once been fabled for both its size and its culture. Even after ten years of layoffs, it was still one of the largest companies in the world. They were the stuff of legends. The glory days had since passed, but I was still going to be working for The Big Mothership. We’ll call it TBM. Now, the adventure was truly about to begin…

Further Reading

A Boston Technical Recruiters Blog: Even recruiters blog. There is some good advice here.

Deceptive Recruiting: HR’s Last Stand? A discussion of recruiter ethics

Questions

What experiences have you had with recruiters?

What is the longest period you’ve ever had to wait between an interview and a job offer?

Have you ever had to personally turn down an employer?

Next Page »