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.

Will The Recession Hurt Your Writing Career?

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.

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

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?

A Career in Technical Writing: Bright Lights, Big City

Bullet Points

• Megacorporation is a term popularized by the cyberpunk novels of William Gibson. It denotes a multi-national corporation that has become so large that in many cases it is its own customer or even its own government. Megacorporations often come complete with their own military. These companies are considered to be fictional, but the company I worked at had a U.S. Army base in its parking lot, so I will let you be the judge.
• Cubicle farm is a term popularized by Scott Adams of Dilbert fame. It describes an enormous room partitioned off by low fabric walls that separate workers (but not sound). These cubicles are approximately the same size and dimensions as the stalls that farms use to house large animals. Another farm-related term for a cubicle is veal-fattening pen which was popularized by Douglas Adams in the book Generation X.
• A disaster recovery plan is a plan for resuming key business functions (such as payroll and accounting) after a catastrophic disruption in operations. Such a plan presumes that no specific team member can be reached or contribute to the recovery, so all processes must be independently executable.
• An extended stay hotel caters to business travelers who are in need of short to long-term housing. The rooms tend to come with kitchens, free local phone service, weekly or twice-weekly maid service, and on-site laundry facilities. The better hotels have full cable television, concierge service, a pool and free continental breakfast. I wasn’t at one of the better ones.
• Phoenix, Arizona regularly reaches temperatures above 110 degrees in the summer.

Welcome to the Machine

The branch of the megacorporation that I worked at was housed in a low-slung building that stretched on for at least a quarter-mile. My cubicle was in a warehouse-sized room that seemed to never end. At least 400 of us worked in this vast cubicle farm. My stall was located across the aisle from a flock of customer support personnel who serviced the Asian branches of the company. At any time during the day, I could hear a cacophony of languages that I didn’t understand a word of.

Their customer service work had nothing to do with my job, and not a single person in my row greeted me when I arrived or said anything beyond hello at any point during my stay. The only time I ever heard from any of them was when one of their herd sent an e-mail asking me to stop snapping my gum. I was chewing ginseng gum at the time in an effort to curb hunger pains as part of my most recent ridiculous diet. Apparently none of them were willing to ask me to stop directly. That would have required speaking to me. I was greatly amused to discover that my noise distracted them as much as their noise distracted me. I didn’t stop chewing the gum but I did try to back off on the snapping – a little.

Fly Casual

It turned out that writing service level agreements wasn’t as boring as I thought it was. It was geometrically more boring than I thought it was. I wasn’t even writing the materials. A friendly but bland middle manager wrote them up. All I had to do was read through the documents and fix the grammar, usage and formatting. I then sent the documents back to the friendly but bland middle manager and if he had any questions, he emailed them back to me. We rarely saw each other.

The work itself would have made for a dreadfully dull job, but the real problem was that he only produced something for me to edit about every three weeks. The remaining days were spent trying to look busy without using the Internet. If I didn’t look busy or if people saw me use the Internet, people complained. They didn’t complain to me. They didn’t talk to me at all. They complained to my friendly but bland middle-manager. This would result in an email from him. The friendly but bland middle manager sympathized with my lack of work, and he never seemed angry, but he made it clear that I could only use the Internet “during lunch”. To cope with my boredom, I brought in books on web development and FrameMaker. I also read whatever SAP guides they had lying around. It helped me to look busy, and I did learn a few things, but the days just dragged by.

Summer in the City

In addition to being bored at work, I was also bored when I got off work. I still considered Tucson to be my home, but I needed a place to stay in Phoenix. I rented a room by the week at an extended stay hotel. The room was decent, if ugly. It had a framed picture on the wall that I was sure contained a carpet remnant. It had a kitchen, but I never bothered to cook. I mainly lived off of Subway sandwiches (it worked for Jared) and Gatorade along with a refrigerator shelf full of the Kirkland brand diet drink. I had begun the job in the middle of July and the temperature rarely dipped under 100 degrees even in the middle of the night, so I never felt like going anywhere. For the most part I came home and watched baseball on the television or went for a swim. I scribbled some poetry in my journal then went to bed.

By late September I gave up on living in Phoenix and started driving up from Tucson every day. I did this mainly because it killed time and I could at least see my friends and family for an hour or two. I began listening to books on tape as I drove: A Brief History of Time, The Razor’s Edge, The Lord of the Rings trilogy (plus The Hobbit), the Interview with a Vampire series. Books on tape kept me going. All the driving was exhausting though. By late October the temperature had cooled somewhat, and I spent many of my lunch hours over the fall and winter months sleeping in my car. The office building was under the approach to Sky Harbor Airport. I watched the planes cruise in above me, one every thirty seconds, until I fell asleep. It was just like counting sheep.

Flirtin’ With Disaster

Because I had nothing to do, and therefore no good reason to say no, the bland but friendly middle manager started sending me to meetings to take notes for him. I considered this to be secretarial work, and told him so, but it was still more pleasant than sitting in my cubicle trying to look busy. Most of these meetings were the standard megacorporation time-wasters. A roomful of people would gather to argue over timelines, statuses and budgets.

One group managed to capture my interest — the Disaster Recovery Team (DRT). The DRT (pronounced dirt) met every week to work on a plan for what to do if the central SAP site was destroyed and everyone was either dead or missing. This was a megacorporation, and it had a worldwide organization to run whether we were at the bottom of a smoking crater or not. I volunteered to write the disaster recovery plan. They had set up collocations for the servers in Illinois and an archive storage facility in upstate New York. We put together a plan to reassemble this information if a disaster struck. We all agreed, quite rightly, that the priority would be the payroll department. The processes I documented were dry, but the meetings were fun because we got to spend a lot of time thinking of ways in which the site could be destroyed: earthquakes, fires, riots, chemical attacks, nuclear attacks, even disgruntled workers. We decided that a gun-toting employee did not rise to the level of disaster and was therefore outside of our scope. All of this speculation helped me to pass the days.

Goodbye Stranger

Beyond those moments, the job never did get interesting. After about eight months the friendly but bland middle manager called me in to let me know they were terminating my contract early. They didn’t have anything for me to do. He was nice enough to give me a month’s notice so I didn’t make waves about the “year contract” I had agreed to. Arizona is a right-to-work state, so I really didn’t have any recourse anyway. They could have let me go at any time.

I sent my resume out to the usual suspects, but the month passed without a nibble. To tell the truth, I wasn’t that disappointed. The daily drive and the boredom had left me exhausted and burnt out. I needed a break. The week after the job ended, my health caught up to me. I came down with a severe case of the flu and I barely got out of bed for almost a month. I laid in bed and read, The Girl Who Loved Tom Gordon, about a dozen times. Getting lost in the woods of northern Maine seemed oddly similar to having a never-ending bout with the flu. It was quite a while before I felt like myself again, and by then I was in desperate need of another job. It was right about then that Silicon Valley called and asked me out on a date. Would it be a Love Connection?

Further Reading

• Douglas Coupland’s Generation X Neo-logisms: Coupland provided many terms for corporate culture and job dissatisfaction including Anti-Sabbatical, Consensus Terrorism, McJob, Mid-Twenties Breakdown, Rebellion Postponement, and Sick Building Migration.
• Step by Step Guide for Disaster Recovery Planning: A good introduction to planning and writing a disaster recovery plan.
• Service Level Agreements: An overview of Service Level Agreements from the folks at ZDnet.

Questions

• What experiences have you had with large corporations?
• Have you ever been housed in a cubicle farm?
• What is your ideal (realistic) corporate environment? Do you consider one to be possible?
• Would it be a good idea to create a personal disaster recovery plan?

Next Page »