Buy yourself time as a lone writer

If you want to be “making it as a lone writer“, one of the most difficult challenges is to find time. Time to develop your skills, improve the documentation, advocate it and network with other teams. One comment on my previous post raised that issue, and I’m taking a couple of posts to reply. Jim wrote:

I am a lone writer for three separate product lines that are mostly custom products (only half are standard manuals). None of these products lines are planned. I hardly have enough time to finish what is required, let alone look ahead to the future of my “department”.

My strengths are technical understanding and an ability to communicate with a technical audience. Weaknesses in planning and management.

So without divorcing my family and marrying my career, do you have any suggestions for employing the suggestions you offered to my situation?

Good question and good point! Today and next week, I present some strategies that have worked for me. They have bought me time to get organized, so I could produce better documentation more efficiently.

Eliminate internal inefficiencies

When you’re a lone writer, chances are you’re not working as efficiently as you could. I know I didn’t, and it wasn’t because I was lazy or incompetent. The “benign neglect” that surrounded documentation simply put a low priority on efficient documentation. As a lone writer, you are probably the first and foremost advocate to make documentation more efficient.

Moving to(wards) topic-based authoring is one good way to become more efficient. When I was a lone writer, no one in my company knew about topic-based authoring (or “TBA”; here’s a good first introduction). I didn’t know about it either, so I wrote user manuals in long Word documents with long chapters. They were hell to maintain: For each error, each update I had to sift through the whole document to find all the places that needed editing. Lone writers can benefit from TBA in these ways:

You can structure your documents using TBA, so most information is only in one logical place. This can help you to limit the scope of your updates from one release to the next. In a first stage, it might already be helpful just to chunk your chapters smartly:

• Move all conceptual “what is…” sections into one chapter.
• Move all the procedural “how do I do…” sections into other chapters.

You can introduce TBA incrementally as a lone writer, so you don’t need extra time to reorganize all content at once. And you can take it slowly as you become more confident about how to do it.

You can reuse topics. Even if you have custom products (like Jim above), look closely at them: Are they always completely built from scratch? Maybe they reuse some concepts, elements or workflows that you have documented before. You can isolate such documentation into topics and reuse them.

You don’t necessarily need a cool authoring tool for TBA (though your reuse won’t be efficient without one). The first goal is to get your content organized, so you can quickly identify and edit the few topics affected by each functional change or update. I’ve done TBA in Word more often than I care to admit… 🙂

You pick up a marketable skill: You’ll find it easier to get and move into a new job if you know TBA. In my experience, knowing such a method is more valuable than knowing any one tool. The method still applies while skills with an old tool version have become obsolete.

– You might also find other ways to tackle inefficiencies in the way you work today. Even if it’s only a more efficient way to prepare your weekly reports.

The strategy to eliminate internal inefficiencies has an evil twin which can be just as effective, but it’s more dangerous:

Skimp temporarily

This one is risky, it requires courage, good judgment, and some mutual trust!

When I was a lone writer, I have gotten away with skimping temporarily.  The requirements on my documentation were not standardized. Sometimes, the only formal requirement was that documentation exists. If you’re in such a situation, you may be able to get away with underperforming for one or two releases, while you get organized.

When I did this, my manager indirectly called me on it and suggested some improvements to the documentation. Then I was able to show him how I had started to move towards TBA to be more efficient in the future. When he realized that I was working on larger, reasonable improvements, he supported me.

– Next week, I’ll talk about a couple of strategies to buy yourself more time: You can also fight external inefficiencies which encroach on you from other departments.

Your turn

What is your experience when trying to improve documentation? Have thesse or any other strategies worked for you?

Advertisement