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?


6 Responses

  1. It’s very hard to separate the urgent from the unimportant. When deadlines are looming, you simply have to set aside time for strategic activities that will help you in the long term — like learning about topic-based authoring.

    The lone writer must also build a network of professional contacts and stay in touch with the latest trends in the profession. Fortunately, in the age of the Internet, this is easier than ever before. If you’re reading this blog, you’re already off to a good start. 😉

    • Yes, it’s very difficult indeed to stay focused and to stare down deadlines. I find that it helps to plan and monitor my time closely – lest I spend all of it and more on just getting things done.

      I totally agree on the networking, and thank you for your kind words. There’ll be more about how lone writers can network on this blog sometime in the future. In the meantime I’ll consider myself lucky to see my commenters get ahead of me… After all, it proves I’m on the right track! 🙂

  2. At my first techcom job in R&D, the dept head used doc status forms. Each form gave the doc title, the main writer, the other contributors, where it would be published (in house or in an outside publication or conference), the format required, the due date, what project manager(s) and dept head(s) had to sign off on it, and the staff editor/writer assigned. Each of the preliminary and final review sections had blanks for names and dates for whom the review draft was sent to, when it was required, and the reviewer’s signature or initials and the date. A copy of the form followed each document through the review process, with each contributor, editor, or reviewer signing and dating the form before passing it to another reviewer or back to the editor for copmilation into the next draft.
    When the final release section with the printing or submittal date was added, a copy of the form was filed with the final document in the archive.

    When I moved to other jobs as a lone writer, I always created a comparable status form customised to the new company or organization, and kept a current copy of the status form for every in-progress project I had, because providing current status information on multiple projects to diverse people in a big company can be a real time sink. Once everyone was on networked PCs, I put the forms on the network, and allowed SMEs and other to update them online as they completed required reviews, etc. Everyone can check the status online, and determine who is curently holding a review up, without requiring my time to chase it down personally.

    • Thanks, techquestioner, for taking the time to outline the status forms and process! This is a great idea – one that didn’t occur to me when I was a lone writer.

      I agree, it points to one of the areas where you can lose – or save – a lot of time: Reporting! And I think it’s a smart move to let the reviewers update their own status. It probably encourages most of them to take care of their review and status pronto, lest they’re “it”!

      Thanks again for sharing your experience and best practice!

  3. Kai, I’ve just started a new assignment as a lone writer, and I’ve had tons of assignments crashing down on me right from Day One.

    But, a lot of the assignments are TBA, and it’s been surprising to me how much more quickly I can get those projects done. It’s incredible. Some are wikis, some are online help. For a while I was scratching my head wondering why it used to take me so much longer (like, 40-80 hours) to write manuals – but you’ve hit the nail on the head.

    Excellent post, as usual. Looking forward to Part 2.

    • That’s been my experience as well, Bill. I wouldn’t even say that TBA is the “one-size-fits-all” method. There’s way too much challenge in the appropriate and useful chunking and assembling of topics.

      But I did find that TBA takes away much of the “ramp-up” time in the design phase. I just get productive so much sooner – an important benefit for the lone writer.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: