Option Paralysis and the Technical Writer

Option Paralysis: The tendency, when given unlimited choices, to make none. – Douglas Coupland

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?

What major/degree is required to become a Technical Writer?

There are no specific degree requirements for a position in technical writing. Many technical writers have writing-related degrees such as English, creative writing or journalism. Others have degrees in fields that employ technical writers such as engineering, chemistry, computer science, aerospace, or biology. Some technical writers have completely unrelated degrees. These writers get into the business either by being promoted within the same company or hired because of industry knowledge gained on another job. Writing skill, industry knowledge and tools knowledge are what counts in a technical writing job search.

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.

Starting a New Technical Writing Project

They picked you. You get to be on the new documentation project. You might even be leading it. This may be a new duty at an existing job or a whole new job. You need to get up and running and prove that they made the right choice when they decided on you. Here are a few things that you should do at the beginning to make the rest of the project easier.

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.

I See Dead Projects

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.

Next Page »