Staying Out of Maintenance Mode

by Tom Johnson on Oct 29, 2012
categories: technical-writing

The past few weeks, I have to admit, I've been kind of bored as a technical writer. I even considered switching more into content marketing because it seemed more interesting. (Hence my recent posts on content marketing — The Double-Edged Sword of Hiding Controversial Information, Company Strategies That Avoid Controversy, and Writing in the Trenches.)

Last week I started a new project at work, documenting a mobile app on the Android platform. In writing new documentation, I realized that I'd been in maintenance mode for nearly a year. By maintenance mode, I mean I was mostly updating documentation for products I already knew and had previously documented. Version 2.1 to 2.2, or version 3 to version 4, etc. I've had only one new product to document in the past six months, and it was a simple application.

Working on documentation for the new mobile app was invigorating. I didn't already know how it all worked. I had to figure much of it out. Not only how the application worked, but how to do mobile documentation — how to take screenshots on a Kindle device (my only Android device), how to publish to mobile webhelp, how to get documentation screenshots to display correctly for both tablet and mobile widths, and so on.

As I was going through the app (and its companion web application) to write documentation, I realized how much I enjoyed the activity. I like figuring things out. Of all the things I do in IT, problem solving activities are probably the most rewarding.

In fact, when we say we're "documenting" a product, don't we really just mean we're "figuring it out"? Each help topic we write adds another piece of information to the puzzle we're trying to solve. As we add topic after topic to the help file, we document/conquer/solve the product.

Figuring things out doesn't necessarily involve creative writing skills, but it does call upon creative problem-solving skills. Creativity and problem solving go hand in hand, like two members of the same family. We're coming up with solutions that aren't already known.

The experience of figuring out something new last week made me realize a few things. First, my shift toward content marketing was premature. It was only a direction to satisfy what I incorrectly attributed as boredom with technical writing. Second, now that I know where the sweet spot is with technical writing — figuring things out — I can refocus my efforts in a more engaging way.

Rotating Projects Among Team Members

In a discussion with a colleague the other day, I mentioned the dangers of staying in maintenance mode too long. She reflected on the idea of rotating projects among team members on a regular basis. For example, after six months working on documentation for several projects, I could hand the projects off to one of my colleagues. In turn, the colleague could hand me his or her projects. This would be a way to stay fresh.

This might be an interesting experiment, but I doubt it would work. Once I receive, for example, my colleague Ben's products, I have to start from scratch with the knowledge. Who is the audience? What kind of information do they need? What does the product do? What tasks have already been written? Do I rewrite the help, confirm what's already there, rearrange everything to suit my preferences?

I'm not sure Ben would appreciate me going through his help with a wrecking ball, nor would I appreciate it if he wrecking-balled my help either.

And let's suppose that after three months of immersion, I realize that the help file is surprisingly well-written. My initial changes often lead to reversions back to the initial state as Ben had them. My reorganizations often become re-reorganizations that look almost identical to the initial organization.

In switching projects, more practical issues also arise: billing. If Ben has already billed 90 of the 100 available hours on the project, why would a product manager authorize a new technical writer to start from scratch, billing another 90 hours toward the project and effectively doubling the cost, just so that someone can rewrite the documentation? The work has already been done.

Switching projects probably won't be practical as a way to keep out of maintenance mode.

Ensure a Constant Stream of New Projects

Another solution to avoid maintenance mode would be to make sure you have several projects, and that at least one of the projects is new.

Most of my products are small applications and tools, so it's common to be responsible for half a dozen products. If two-thirds of them are in maintenance mode, that's all right. Having one new project to focus the majority of my attention on seems to cure the stagnation problem.

After all, I can't operate in figure-it-out mode all day. Like writing, I can only sustain this problem-solving level for a certain period of time before I need a break. During those breaks, when I want to give my active mind a rest and let the unconscious side drive on cruise-control for a while, I can turn to my maintenance-mode projects.

To ensure I have a steady stream of new projects, I need to either market my services to new project leaders on a regular basis, or pursue some other plan to get new projects. I'll have to call up project managers and stay aware of products on the horizon.

Adopt a Problem-Solving Mindset

I can't always control what projects I get to work on. So let's say that, whether I like or not, I'm stuck in maintenance mode working on projects I'm all too familiar with, updating projects I've documented months or years ago and are simply stuck with. In this case, I can still  work my way out of maintenance mode by adopting a problem-solving mindset.

Almost all projects pose some kind of problem to solve. Maybe it's figuring out why so many users keep visiting a specific topic in the help. Perhaps it's determining a way to reduce calls to the support center by 50 percent. Maybe you're trying to figure out a way to simplify or even eliminate the most complicated task. Whatever it is, identify a problem to solve and set yourself to solving it.

The first step to solving a problem is to identify the problem. Merely approaching the situation as a problem to solve can turn around the entire experience. For example, yesterday I had to clean out my garage. Not a very exciting task, but I approached it as a problem to solve. I had 5 bikes to store and 2 cars. My garage is small, so it's no easy task fitting all of this stuff in there, especially since my car's bike rack extends past the garage door.

After a few hours and a trip to Home Depot, I figured out a solution. Three bikes hung parallel on walls, and two on the ceiling. I had to open my trunk to fit in the bike rack on back (and also remove the trunk bulb to avoid draining my battery). What could have otherwise been drudgery, I approached it as a problem and found the task fulfilling.

In conclusion, recognize the dangers of maintenance mode. When we get burned out with technical writing, is it because we're "tired of the politics" (or some other cliché), or is it because we no longer have fresh problems to solve?