Staying Out of Maintenance Mode
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?
Tom, it seems to me that in this post and your last you have captured the essential dilemma of technical communications, both for the employer and for the writer.
In your last post you wrote: “If there’s one truism about writing that seems to work universally, it’s this: write about what you know.”
In this post, you write that maintaining the same information gets boring and you seek ways to switch to a new project where you have lots to learn.
The dilemma for the writer is that to write well they should write what they know, yet writing about the subjects they know gets boring after a while. (Many writers are essentially professional dilettantes — easily excited by a new field, and just as easily bored as time passes.)
The dilemma for the company is that it is expensive to have writers spending time learning rather than writing, and that the quality of the information they do produce is lower that it would be if they wrote about something they knew well, at least until they have worked with the new subject for a while.
This explains why companies would rather hire people who are passionate about a particular field and don’t get tired of writing about it — even if their passion and expertise is not in writing or publishing itself.
Mark, this is one of the best comments I’ve received on my posts. Thanks for drawing comparisons between my blog posts that I myself didn’t even realize. Very insightful.
Yes, it is a dilemma. I’m not sure what the best solution is, though my guess is that the middle ground is more realistic and less problematic. For example, I’ve been writing about tech comm on this blog for the past six years. Yet I still feel like there’s so much to learn and explore. I’m writing about what I know — tech comm — but exploring topics and issues that extend my learning into areas I’m not that familiar with. For example, I recently wrote a long post on mobile.
With product documentation, I’m not sure it works the same as a discipline or field. The limit of knowledge about one application is pretty finite, and once you approach that knowledge ceiling, there aren’t many other directions to go. But fortunately at that point, the documentation is usually done and it’s time to move on to some other project.
We’re rather lucky to be in the position we’re in. Technical writers hop from project to project to project while developers often slug around with the same project for years.
Thanks again for commenting. Sorry I’m so slow to interact in the comments section. I’ve had my head buried in a project for the past couple of weeks. Just now coming up for air.
Lately, I’ve found myself in something beyond maintenance mode, as we gear up for new products which are just in the planning stages while the documentation for existing mature products requires little attention. In the meantime, I’m tackling the conundrum of creating and publishing documentation in a social media-enabled environment.
t seems that tech writing is at a crossroads, with strategies and tools not quite addressing the needs of writers or our audience.
How do we thrive in an Agile environment?
What’s are the best tools to create and publish documentation?
How can we be responsible for content while enabling social interaction with users?
How do we fit in a mobile app world?
What about our role in content management?
Should we be involved in documenting backend systems?
Is good professional writing valued or even needed in business today?
I suspect that many of us are wrestling with at least some of these questions. It seems that lately I vascillate between frenzy and boredom as I attempt to tackle some of these issues.
It seems that the transition to mobile, social apps is resulting in a schism, with small intuitive apps on one side and complex backend systems that ultimately drive those little apps on the other.
The trick is not to be caught in the void in between.
Anne, you’re definitely right about always having more to learn, especially with the introduction of social media and mobile. In fact, I just wrote a long post about what I learned in writing documentation for mobile. I think your point, as it relates to this post, is to use our maintenance mode time to reach forward into these new domains and consider how our practice fits in with emerging trends. How can we move forward with a documentation strategy that fits the social/mobile/personal world that is developing? Given the pace of change on the web, it’s hard to even fathom a maintenance mode that lasts long enough to make one bored.
Thanks for commenting.
Good post! When my documentation is mostly maintenance, I see it as an opportunity to look into some of the new software that is always out there. Alternatively, maybe time can be found to help out another team on a small project.
Cathy, excellent tip about using down time to learn new tools and software. Thanks!
As I read your post, it struck me that you were also describing programmers. My husband is a programmer, and I often think we work very differently. But when it comes right down to it, our work is very similar. Figuring out how something should work, keeping the customer in mind, investing time and money in project knowledge only to be threatened with going off project to another task, getting bored with maintenance even though it is very important. Feeling creative even though our work is technical. We are problem solvers at the core, and we thrive on challenge.
Thanks for commenting, Eileen. I agree that maintenance mode isn’t specific to tech comm; it’s probably common to many other fields as well, esp. programming. I know some programmers who remain on the same project for years. I don’t know how they maintain interest, but removing someone from that role seems costly. It would require a newbie to learn the whole thing from scratch, potentially costing months in down time. Then again, the renewed energy that a person feels in tackling a new project might just be worth it.
Tom,
As is often the case, your post is quite timely.
I’m on a project right now that is full of brand-new problems, and I’m having a blast. I didn’t realize how long it’s been since I’ve really had brand-new problems to solve.
That said, my first thought when I read “maintenance mode” was that you were talking about handling “tech debt” — those things that you know you want to fix in your projects but that others might not know enough to care about. You’re not talking about that as much as you are about the maintenance of user assistance for existing products.
Nonetheless, I know that when I’m in maintenance mode, I find myself dipping into the tech debt while I update pre-existing user assistance. Based on your post, I think that you’ve explained why I do that; namely, I’m still trying to solve problems.
Eileen makes an interesting point, too. I was going to say it’s probably part of human nature to gravitate toward the new and exciting. But as I think about it, I guess some people are wired more for that than others. And we need both people, those who push the limits of the new and those who like to stick with what they know and keep it in tip-top shape.
Also, I come to techcomm from a journalism background. Editors that I worked for occasionally liked to shake up the newsroom by shuffling beats.
There are pros and cons to that, but the reasoning was similar to your section on rotating projects among team members. It brought fresh eyes to a beat (really good) but it reset relationships between reporter and source (potentially really bad). Same thing could be true in techcomm.
On my current techcomm team, we often talk about cross-training each other, and we do a lot of what the software devs call “pairing” (collaborative writing for us). It isn’t always possible to write collaboratively, but I think one of the reasons we do that is to get fresh eyes on something while the “expert” tech writer gets to stay the expert.
John, thanks for your comment. You mentioned a few things that jumped out at me as being particularly useful.
I also think that tech writers gravitate toward this mode — fixing tech issues — because it involves problem solving. If we wrote documentation 8 hrs a day, we might quickly tire. Our minds need the problems to solve, so we gravitate toward these technical issues.
This sounds like an excellent idea. If you wouldn’t mind, can you share a little more about the pairing that you do? Does that involve one writer testing out the documentation another person writes and then giving close feedback and criticism/suggestions? I think that might be a really useful practice. It’s interesting to see the comparison with the journalism field.
Thanks again for commenting.
Hi,
Yes, I can see myself in the article. The first, say, 7 months of the last year were extremely exciting, as I was trying out new things and facing new challenges. Then, slowly but perceptibly, I started just updating the documentation, one minor release after the next one, and it stopped feeling exciting.
I had expected it to happen – after all, it is not possible to stay enthusiastic about one’s job for too long – but when it hit me, I started wondering whether I should change job. And yes, office politics play a considerable role.
Thank for the post, I am going to try and change my mindset.
DiSc
Thanks DiSc, I’m glad to know I’m not alone in my experience. Are there new projects that you can sink your teeth into? That seemed to do the trick for me. But this is rather easy because I work for a large organization, with many new opportunities always nearby.
At one time, about 7 years ago, I worked for a startup, writing a lot about just a few products. That job (I was a coypwriter) fizzled out and I switched to tech comm, but I’m sure I would have experienced the same maintenance mode syndrome there after a while, with no easy escape route.
Hello Tom,
I started editing a white paper for the marketing department, and I am documenting a bunch of XSDs – I had been postponing that but now I decided it is time to finish off the task.
That means I am going to avoid my usual tasks for a while, and it feels like a holiday of sorts.
DiSc