The first skill a technical writer should have, of course, is writing. You should be able to write in a clear, concise manner. Technical writing is not poetry or prose. Depending on where you work, you may or may not be able to add some stylistic flair. Either way, your job is to clearly tell your audience exactly what they need to know, and everything they need to know.

The second skill you should have is knowledge of a technical subject. My emphasis has always been in the field of computers, which is probably the largest segment of the technical writing market. Your knowledge can be in many other areas, however, such as science, medicine, engineering, mechanics, or law.

No matter what your area of knowledge, you will need computer skills, especially desktop publishing skills. At minimum, you should know the Microsoft Office suite of applications, especially Microsoft Word. Beyond Office, there is Adobe FrameMaker, which is used in many technical-writing environments. Other publishing packages such as PageMaker, Quark Express, and Interleaf can also be useful. In addition, online documentation tools such as RoboHelp, Doc-to-Help and Lotus Notes are great applications to have on your resume, as are HTML and other Internet skills.

In addition, you should try to develop interviewing skills, because you will probably find yourself interviewing technical people to get the information you need for your documents. Often, they will have no idea how to tell you what you need to know, so it is up to you to figure out how to draw the information out of them.

How do I become a technical writer?

This is my most frequently asked question, and a difficult one to answer. I can only tell you how I got into it. I have spent my entire adult life (and a good deal of my youth) as a writer of some form or another. When I entered college, I became first a reporter for and eventually the editor of my college newspaper. It was exciting, interesting, and very stressful. When I chose a major in college, I finally settled on creative writing, with a minor in English. I took very few technical courses in college and I have never taken a course in technical writing.

What I did do was work with computers, constantly. I got my first computer when I was 13 years old and I have never been without one since. In high school and at the beginning of college, I took some programming classes, but only about three of them. The rest of my computer skills I acquired either at home or on the job. When I transferred from my community college to the University of Arizona, I got a job in their computer department in the ‘Courseware Library for Instructional Computing’. There, I was exposed to just about every micro platform available at the time (IBM, Apple/Macintosh, Next, Commodore) and hundreds of software programs. I enjoyed it and I eventually began to teach seminars in Macintosh computing to the faculty and staff. While doing so, I wrote some short manuals and performed other various desktop publishing functions. After college, I had a series of jobs, all of them either computer, publishing, or writing related, until I eventually found myself out of work and needing a career path. I had done some technical writing as part of my past jobs, and I decided that I should dedicate my efforts towards building a career there.

Despite being broke, I managed to acquire my own copy of FrameMaker, and train myself on the package, adding that to my skills in PageMaker. I also taught myself HTML programming and learned to read C and other languages that I had not visited in many years. I sent out over 300 resumes and refused to settle for less than what I wanted. I used up all of my unemployment and dug myself deeply into debt.

Then, I received two job offers. The first one was to work as an Internet content developer for my local newspaper. It paid eight dollars an hour for 30 hours a week of work. I was willing to take it, and would have, but right as I was about to I got a call from a contract agency I had sent my resume to. Another local company was looking for a technical writer for a six-month contract. It paid $20.00 an hour, but much of that got sucked up when I opted for salary and benefits such as medical and dental insurance, holidays, sick days and vacation days. In the end, I started at $29,000 a year and after 6 months I renegotiated to $35,000. As my experience has grown, so has my pay.

What should I take in college?

As an undergraduate, I focused on creative writing and English. If I had gone to college with the goal of being a technical writer, I would still have majored in English or Creative Writing, but I would have minored in a technical subject such as computers or one of the sciences. For some, engineering may be a better choice than science. Even if you are a college graduate, you should consider supplementing your education. An associates degree in computers or another technical subject will prove you have learned the basics.

For graduate studies, more and more colleges are offering Technical Writing or Professional communications degrees. I recently went back to school to get a degree in professional communications.

I’m just out of college, and I want to be a technical writer, but I have no experience, how do I get my first job?

The first technical writing job is difficult to get, especially if you were a writing major and did not major (or even minor) in a technical subject. The first thing you need to do is prove you can write. This involves creating a sample of your work, which is not easy to do without having a specific project. What many people do is try to find a short, badly written manual (There are thousands) and re-write it. The other approach is to write a manual about something you know. The key is to have proof you can do the work.

Do I need a sample?

Yes. Prospective employers often ask for a sample of your technical writing. This can be a problem because these same employers are likely to tell you that what you write for them is confidential. For this reason, I use a ‘fictionalized’ sample. It is based on a short manual I wrote for one company, but I have gone out of my way to change any company-specific information. This was not fun, but it was the best compromise I could come up with. My sample is about 15 pages long. I keep it this short because the employers often want to keep it or review it, and they are not that cheap to reproduce, especially because I have my sample vellum bound with a transparent plastic cover. I also include an explanation of what publishing package I used and what the requirements and restrictions of the project were.

What is the best way to look for a job?

The Internet is a great way to look for work, and even better if you are willing to move around. I especially recommend indeed.com, which searches severl employment sites at once. I also try to hit all the local technical employment agencies. The easy way to do this is check the Sunday paper of the town you are interested in and look in the computer or technical employment sections. Look for agencies advertising several jobs and get either their fax numbers or e-mail addresses. They do not have to be advertising technical writing jobs. If they place technical jobs, then it is worth the time to get your resume and cover letter to them.

There has also been a growth in resume distribution services. These companies claim to send your resume to thousands of recruiters. I haven’t tried this approach, but if you are interested try: EmailMyResume.com, ResumeZapper.com, and ResumeXposure.com.

What should my resume look like?

Emphasize your technical skills. If you know a software package or computer platform or if you have a scientific background, make sure you supply details. I am a strong believer that good writing skills are far more important than knowledge of a specific subject or program, but the reality out there is that if you know the programs or subjects they’re looking for, then you have the distinct edge in getting the job. Writing skill is far down the list of what they take into account. I have gotten two jobs without even providing a sample of my writing. If you would like to have a professional work on your resume, try: Employment911.com or A and A Resume.

What kind of cover letter should I use?

If you are contacting an agent and not responding to a specific job request, then simply indicate a few basics about yourself. indicate you consider to be your strongest and most relevant skills. Don’t make it long and don’t go out of your way to provide details. If they want to know more, they will ask. Keep it short and simple.

On the other hand, if you are responding to a specific job description, especially if you are responding directly to the employer, then a careful cover letter should be written. Analyze the job description, and in your cover letter state specifically how you qualify for as much of that description as possible. Make them believe that you are exactly what they are looking for. Paraphrase their description as much as possible.

What should I ask for in negotiations?

Negotiations are a difficult process. Most agencies work on the “What pay range are you looking for?” system. This is a tricky system, but one that can be beaten. The key is to ask for more than you expect to get. Do this every time, and by at lease five dollars an hour. I give this advice for an important reason. If you are dealing with an agency and you under-price yourself, you are at their mercy. They will either give you what you ask for, or whatever the minimum in their range is. That is it. End of story.

However, if you ask for more than what their range is, they will then proceed to tell you what the range is. Remember, you aren’t dealing with the employer, you are dealing with the agent, and they know what the job will be bid at. When they tell you your rate is too high, ask what the range is and tell them that whatever the high number is will be good enough. It is possible to price yourself out of a job, but frankly, I’m willing to accept that risk. If you aren’t, then follow your own instincts.

If you are dealing directly with an employer, negotiations are more difficult. The key here is to wait until they are ready to extend an offer. If they ask early on what you want, tell them that you will be happy to listen to whatever their offer is, once they have one to make. If they get adamant about it, then you’ll have to name your figure and take your chances. Again, I recommend starting on the high side, but it depends on your instincts and whether you are willing to risk not getting the job in order to get what you want. I have been lucky enough to be pursued by more than one company at a time, and I have been willing to play the two off each other in order to get what I wanted. There is also a big advantage to already having a job when you look for your next job. You have the luxury of saying no.

The one most annoying question an employer can ask me is my past salary history. This has happened a few times, and I have refused to tell them on some occasions and I have told them on others. In both situations, I never got the job, so I can’t say which practice works best. I always take the question as a bad sign, however. Any company interested in this is not likely to treat their employees well, in my opinion.

What is a good technical writing rate?

There is, of course, no clear-cut answer to this. Rates vary according to geography, experience, benefits, and the current job market. As I write this, the market has been slow for a three years but is now starting to pick up. There are still more writers than jobs, but the numbers are evening out.

If money is a prime concern, then you need to be in a major market. I am currently working in Phoenix. Phoenix is a good market because there are several major technology firms (Motorola, Intel, AT&T, American Express, etc.) and there are quite a few smaller companies that employ technical writers. California in general and the San Francisco Bay area (also known as Silicon Valley) specifically are the largest markets, though they have also been the hardest hit by the slowdown in the technical industries. Dallas, Denver, New York, Atlanta, North Carolina and Washington State are also good markets. In those places, contract technical writers commonly make from $15-60 an hour. Salaried employment ranges from $30,000-90,000 a year. There have been more jobs in the lower part of this range during the slump, but compensation is also picking up.

Is it better to take a permanent job or a contract?

This depends on the job, of course. I originally chose to go the contract route because I knew that with a couple more years of experience under my belt, I would be able to command much more money than I would when I began, far more than I would be able to count on through raises. I also had no family to support, so I had a certain freedom to move around and to take risks. I did take a permanent position once, but permanence in this industry is an illusion. I have continued to take contract work and I prefer it.

If you do contract, you will find that you are generally treated differently from regular employees. This will vary widely from company to company, but you may or may not find yourself with a little less respect and acceptance, especially as a technical writer. You are disposable. Also, you will be expected to do your own training. Rarely will companies finance training for contractors.

On the up side, you generally attend fewer meetings and deal with less company politics. Also, I have always tried to get my training on the job. Moving from company to company has given me the opportunity to learn a variety of applications that I would be ignorant of if I had only been at a single company all this time.

To me the key difference between contracting and regular employment is one of attitude toward the company. When I am contracting I consider the company to be a client. I probably work harder to give them what they want, but I have less personal interest in the outcome. Even if I feel the project is flawed, I do what they ask because they are a client and that is my responsibility to them. As an employee, I get much more caught up in the reasons for projects. I am more likely to object to a course of action I don’t feel helps me or the company because I feel it is our mutual responsibility to succeed. I am more invested in the outcome and less concerned with pleasing the company. This may be different for other people, but I think it accurately reflects my past attitudes.

Why are there more contract/consultant jobs then there are permanent jobs?

The hard fact is that most companies do not value technical writing. They bring in writers to fill a specific need, often because they have been required to provide documentation for a project. Many companies bring writers in at the end of a project to document what has already been created rather than include writers in the full product cycle.

Why don’t more companies value technical writing?

Much more emphasis is put on the programming side of products than on usability and documentation because these are viewed as secondary issues. I strongly feel this has helped lead the technical industry into its current down cycle.

Technical writers are viewed as a luxury. As valuable as I feel my skills are, and can be to a company, the company can still function without me. If the programs or systems are undocumented, or if they are poorly documented by programmers or analysts, it will not damage the company as obviously as if the program fails to get developed. I happen to feel that a company that spends money on good technical writers will get a very high return for its investment, in more satisfied customers, smoother processes and greater institutional memory. I believe that dollar-wise this can make money for the company, but those are categories that are difficult to measure and often hard for management to comprehend.

Also, some companies do not understand what a technical writer does. Some consider writers to be glorified secretaries, and do such things as give them notes to type up or even have them take minutes at meetings. Part of the problem is that secretaries and administrative assistants have also become a thinning breed, and management (not the upper management, who have secretaries, but the lower management and team members) are desperate for anyone who can make a document look good. I once found myself at a company that constantly asked me to attend meetings simply to record the minutes. I comforted myself with the fact that I was paid $36 an hour to do it, but I also started looking for my next job,

What types of documents do technical writers create?

The range of writing a technical writer performs varies widely. Much is dependent on the technical specialty of the writer and of the needs of the company. You may find yourself a part of one large project, or overseeing dozens of smaller projects. You might write manuals, articles, proposals, white papers, product descriptions or any of a hundred other types of documents.

My specialty is writing manuals, especially user manuals and programmer manuals for specific software applications. This is the technical writing I enjoy most, because for me it involves solving problems and figuring out puzzles. To write a user manual, I need to think like the people using the program and try to tell them what they need to know, rather than what I would need to know or what the programmer would need to know. For me, this is a lot of fun and very fulfilling.

There are dozens of different types of writing that come under the banner of technical writing, however. Many people document processes. Processes can be just about any system by which something gets done. For example, in order for a company to generate a payroll, certain actions must be taken, such as logging hours and generating checks. All of those steps are part of a process, and intelligent companies document those processes so that, if an employee leaves or a system goes down, they have something to consult in order to get themselves on track. One name for this type of document is SOP (Standard Operating Procedure).

Another type of documentation is SLA (Service Level Agreement). The SLA describes exactly what a provider (company or department) will do for a customer (another company, another department, or an individual). These can be highly technical documents or busywork, depending on the service and the company.

Proposals, often written in response to an RFP (Request For Proposal) document are much like SLAs. They describe what work will be done, but they require more writing finesse because they are also pitching the service. The company is proposing to sell a service. I have written several proposals, and depending on the request and the company, they can be quite interesting or more busywork.

These are just a few examples of the types of work technical writers perform.

Hire John Hewitt - Writing Content and Web Consulting

There are a growing number of technical writing degree programs. These programs focus on the creation of technical and educational documents as well as technical editing, usability testing and organizational communication. In the United States, there are technical writing or technical communication degree programs at colleges such as the University of Washington, Bowling Green State University, Texas Tech, and Carnegie Melon. Most technical writers have bachelor degrees. A few of us have advanced degrees. Although it is rare, I have met technical writers without college degrees.

My college degrees consist of an Associate’s Degree in General Studies, A Bachelor’s Degree in Creative Writing and a Master’s Degree in English with a Professional Writing Certification. I began my career in technical writing long before I had the master’s degree. I had worked in my University’s computer department as an undergrad. It gave me the opportunity work with many different computer systems and applications. I also had the opportunity to work as a computer trainer during and after college. That eventually led to a writing and database development position. From there I got into technical writing. Almost all of my employment history for the past fourteen years has consisted of technical writing or information development jobs.

Hire John Hewitt - Writing Content and Web Consulting

You are working as a technical writer on a project that has gone horribly and quite predictably wrong. The original sizing for the project was for five technical writers. Your project was given three. One of the three was fired and the other one quit. You are now all that’s left and the project is overdue. Whose fault is this? It’s yours of course! You’re the lead technical writer. You weren’t the lead originally, that was the guy who quit, but you are “in charge” now and that makes everything your fault – right? Well, it is if you’ve got an insane moron for a project manager. Here are a few more signs that you’ve got an insane moron for a project manager.

• The PM holds a weekly status report meeting, and then emails you the next day to check on your status.
• The PM likes to play motivational music at the beginning of the status meeting – either Eye of the Tiger or The Final Countdown, depending on the project status.
• The PM asks you to take the meeting minutes because, “You’re the writer.”
• The PM constantly repeats the mantra “faster, better, cheaper” but has never heard of the book.
• The PM asks, “All you have to do is write stuff down. Why does that take so long?”
• When you tell the PM that the project can’t be done with the available resources the PM says, “I need you to be a team player on this.”
• When your co-workers quit, the PM assigns their tasks to the next person on the Excel spreadsheet.
• When the project that doesn’t have enough resources goes into Red Status, the PM asks, “What can we do to fix this?” When you tell them that you need more resources the PM asks, “Isn’t there something else we can do?”
• The PM assigns you two tasks with the same deadline and tells you that Task One is the highest priority – then calls you every day to check on Task Two.
• The PM schedules you for three meetings the day before your deadline.
• The PM schedules user testing for two weeks after the documentation is due. Doesn’t understand why you would want that sort of thing in advance.
• The PM urges you to think outside the box. He then demonstrates by getting into and out of a box.
• The PM “stops by” at five minutes to five, “Just to check on how things are going.” He proceeds to stick around for an hour looking for signs that you were actually thinking of going home.
• The PM disappears for a week without notice, then comes back feeling “rested” only to disappear again the next day – never to be seen again.

Hire John Hewitt - Writing Content and Web Consulting

Option Paralysis

The saying goes, you can’t get what you want if you don’t know what you want. That is a problem that I’ve been struggling with for quite some time. I have spent the past several years settling for what I can stand, rather than what I truly enjoy. In a way, I have been challenging to see just how much I can put up with and still function. I would commute for two hours a day to work for eight hours a day and then come home and write / work on my blog for another three to four hours a day.  Last winter, after two years of keeping up this grueling schedule, I gave up on my blogging. This is unfortunate because writing this blog was by far the most enjoyable of the tasks that were in front of me.

I have been a technical writer for fifteen years. On my best days, I am great at this job. When the challenge is right and my interest is peaked, I can work magic. Unfortunately, the opportunity to work magic comes up only on occasion. Last summer and fall was one of those times. I was working with a talented and energetic partner, and we did some great work. For a period of over three months, I actually looked forward to getting up in the morning and doing what I was good at. Eventually though, the situation changed and I went back to forcing myself to go to work every day. In June though, I got lucky. I lost my job.

I had lost a lucrative job and all of the security that comes with it. The job market was terrible so my prospects seemed weak. I had mortgage payments, car payments, student loan payments, utilities and a grocery bill to worry about. On occasion, I was scared out of my skull. Most of the time, however, I was happy. I had lost a job, but I had gained ten to eleven hours of my day. My stress level dropped. I stopped having to drink Coffee and Monster energy drinks just to get through the day.

I even managed to keep making money. That was the strangest part of all. The Internet took a shine to me. I found that magic money making formula that Tim Ferris and all of those ads on Facebook claim to have. I figured it out myself though, and unlike them I’m not telling anyone what it is. My site has never been about getting rich on the Internet and it never will be. Sorry.

The upshot of all this is that I have freedom for the first time in a long time. I can do what I want to do. I can write what I want to write. I can pick any direction I please. This has brought on a case of option paralysis. Do I return to blogging? Do I look for that “perfect” technical writing job? Do I pick a new career path?

I am free. Now what?

Hire John Hewitt - Writing Content and Web Consulting

Put the past behind you

Projects create things like paper files, computer files, sticky notes, white board entries and the like. When you are starting a new project, you want to put any dead projects behind you. Whether you throw your old files away or just put them aside for safe keeping, now is the time to purge. You’ll want plenty of space (physical and mental) for the new project to occupy. This is also a good time to remind yourself that any personal conflicts you had in the past with potential teammates and other working relationships need to be put in the past. A fresh project needs a fresh outlook.

Create a project file

A new project requires new files, whether they are on your computer or in your file cabinet. Create a space to store all of the documents that inevitably come in as a project moves forward. This includes previous documentation attempts, specifications and business reviews, emails, notes, project tracking, graphics and anything else that needs to be captured.

Set up a tracking system

There are more ways to track a project than you can count. People use to-do lists, milestones, Gantt charts, daily calendars, workweek calendars, personal organizers, Blackberries, Microsoft Outlook, Lotus Notes, color coding, severity levels, Harvey Balls and a variety of other systems. Use what your company wants or whatever works for you, but take the time to track your progress on the project. Not knowing where you are makes it hard to decide where you are going.

Make a contact list

New projects often come with new people. You need to remember who does what and how to contact people when you need to. Even if you are working with the same group you always work with, it doesn’t hurt to make sure everyone has the same email addresses, phone numbers and job roles that you think you remember. Additionally, you need to record information about file locations, websites, logins, teleconference phone numbers, meeting room phone numbers and any other key information that you’ll need at your fingertips. I recommend programming this information into your mobile phone so that it is with you all the time, but make sure you have another version you can access from your computer.

Remind yourself to relax

New projects can be tense, especially at the beginning and near the end. At the beginning people are struggling to find their roles and define their needs. Towards the end people are under the pressure of deadlines, especially if a project has fallen behind. It is easy to get overstressed. When you feel yourself starting to lose perspective and get tense, find a way to relax. Tense people tend to make bad decisions, and then they have to scramble even more to correct them. Find a way to constructively release the pressure. Tools include meditation, stretching, walks or other exercise, and friends. Take the time to deal with your stress and relax. In the long run you will be more effective.

Hire John Hewitt - Writing Content and Web Consulting

One of the great things about blogging is that, for the most part, there is little lead time. You write something and then you publish it. If you’re lucky, you get feedback and if it is particularly good you get repeat visitors. You might write ahead, gathering several days or even weeks worth of posts in advance, but for the most part you are writing as you go.

In the world of technical writing, you are often assigned to projects that last for months or even years, and in many cases the material you write today may not be read for a long time. Occasionally, it won’t get read at all, at least not by the people you intended it for. This has been a fairly regular occurrence in my career. My first major project lasted a year. At the end of that year, the company was part of a merger and moved to the other company’s software platform, negating all of my work.

Later on in my career, I documented what was expected to be a major product for a very large hardware/software company.  Because of the lead time for localization, I had to complete the documentation two months before the product was to be released. I had just finished up and sent off my work to the translators when word came down that the project was being scrapped due to a poor business case. Poor business case was code for, “our competitors decided to include this tool for free in their new operating system”.

My most recent bout of deadprojectitis hasn’t been quite as severe. The product I have been working on for the past two years was released and most of my documentation is at least available to customers. Nonetheless, the product is on its way out. It won’t be gone today or tomorrow, but it is being replaced by something newer and shinier and almost certainly better. The change came suddenly. Just a month ago, it looked like the product would be getting a major overhaul that would have me up to my armpits in documentation for the next six months, but things change.

In all of these cases, far more than my own efforts were negated. There were programmers, engineers, project managers, product managers, business analysts and a host of other people who had their efforts negated. These things happen. Companies change direction, market forces change people’s needs, competitors beat you. This is the world of business and it is frustrating. In some cases people don’t just see their hard work pushed aside, they actually lose their jobs. There isn’t always another project waiting around the corner. These are the realities of the business world. In the current economy, it is something you’ll see more and more of. Companies will be cutting expenses, and often that comes in the area of new development, or the elimination of existing products.

There is no magic solution to this problem. It helps if you can be assigned to more than one project, so that you aren’t defined by a single product, but those choices aren’t always your to make. This is the business world. When things do wrong you pick yourself back up, dust yourself off and get back in the game.

Hire John Hewitt - Writing Content and Web Consulting

The recession is starting to get painful

I know that there are some people out there who don’t think that we’re in a recession. Some of those same people believe that a 700 billion dollar bailout of the financial caretakers who made bad bets with our money is a good idea. What I know is that my 401k is down 18% over the past year and it wasn’t due to me taking a whole bunch of chances. I chose the most conservative portfolio my company offered. I know that my company’s stock value, despite the company making its financial projections, is down by half. There haven’t been any layoffs in the past year, but hiring at the company has become anemic. They aren’t replacing the people who leave unless the absolutely have to.

As a person who posts job openings across the writing industry on my site, I know that it is getting harder for me to find good jobs to post.  I know that at least one writing career path, newspaper reporting, is experiencing a record number of layoffs. Take all that together and we’ve got trouble. If you don’t want to call it a recession, or a “slowdown”, feel free to call it “that lack of jobs thing” or something else that makes you comfortable.

Whatever the case, it is time to look at where the jobs are and where they aren’t, at least from what I have observed so far. Let me clarify that I base my opinion on three things: articles I am reading, trends I have observed as someone who posts jobs, and conversations I have had with other writers. This is not a newspaper report, it is my view of the situation. Call me a pundit, if you will.

Newspapers are doing badly

Newspapers, of course, are the hardest hit employers of writers. Their industry-wide payrolls were declining even before the general economy went into the tank. Newspaper circulations have been down for years. People don’t read the newspapers as much as they used to, and when they do, they generally read them online where revenue is tough to come by. Poor circulation reduces both newsstand income and advertising revenue. Now that the economy is bad, advertising income is dropping even more sharply as companies cut their advertising budgets. In the United States, the election season is helping offset some of those losses, but after the first weekend in November, that income will dry up. This is a terrible time to be looking for a newspaper job, there’s no way around that. Other media outlets such as television and radio stations are also feeling the pinch, but to a lesser extent. Their markets aren’t on the ropes the way the newspaper market is, but they are experiencing the same downturn in advertising as the newspaper industry is.

Copywriting isn’t too strong either

The copywriting industry is experiencing the slowdown as well. When companies cut their advertising budgets, it hits the people who create the advertising. There are some layoffs and a significant reduction in hiring. I’ve noticed a definite drop in the number of positions being advertised in this field. The only area that seems unaffected so far is direct mail, which still seems to advertise for writers at about the same clip as they have for the past three or four years.

Technical writing is still holding up

Technical writing and information development positions have stayed relatively stable so far. While there are technology companies that have had to cut their budgets over the past year, I am still seeing plenty of new positions opening up and no reports of layoffs. If the recession gets worse, which I suspect it will, then you can expect that this field will dry up too. Most companies view documentation as a “nice to have” rather than a “must have”, so if the cuts start to get severe, you’ll see this job market go down as well. For now though, it is healthy.

Proofreaders and editors have their own problems

Proofreaders and editors are facing hiring slowdowns as well. Magazines have been failing frequently over the past year, due in equal parts to reductions in advertising and increases in both paper costs and mailing costs. On the plus side, many of them are converting to web publications, but that generally means lower paying jobs for writer, proofreaders and editors alike. Medical and legal proofreaders are still getting steady work because neither of these areas has been hit by the recession yet and there is no major expectation that they will be hit.

There are some bright spots

If you are looking for some bright spots, resume writing is always a good place to find work during a recession. More and more people need good resumes as they look for work and if you know how to write resumes, you can be very helpful either as a freelancer or working for an employment agency.

In general, because it is such a low-paying industry, finding work writing for web sites isn’t difficult if you know what you are doing, it just doesn’t pay very well. Freelance copywriting is also still providing steady work as companies look to bypass agencies or internal writers and find lower-priced options for their copywriting needs. In general, freelancers tend to do well during a recession because many companies need things done but don’t want to hire someone permanently or go through a high-priced agency. The down side is that as people lose their jobs, more and more of them turn to freelancing so you competition increases.

Bad but not terrible, yet

So far, most of the writing fields are feeling the slowdown, but only newspaper writers are at a crisis point. The next year may lead to more widespread problems. The economy isn’t going to magically turn around any time soon. Next time, I’ll discuss some strategies for surviving as a writer in a down economy.

Hire John Hewitt - Writing Content and Web Consulting

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

Hire John Hewitt - Writing Content and Web Consulting

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

Hire John Hewitt - Writing Content and Web Consulting

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

Hire John Hewitt - Writing Content and Web Consulting