Manage documentation as a lone writer

Even when you’re the “lone writer” in your organisation, it may be a good idea to manage documentation as if it was a team or a department. You need a little leeway, but you can get a lot of mileage out of it: You can elevate documentation beyond a rushed after-thought in the production process. You can raise your profile, from the guy or gal who writes the help to the user advocate. You can help to turn developed features into marketable user benefits. In short, you can turn documentation into a relevant asset of your company – an asset that’s connected to your face.

In my previous job, I was a lone writer for a while. On JoAnn Hackos’ Center for Information-Development Management, I found the New Manager’s To-Do List. I recommend that you check out this invaluable presentation by Marty Williamson!

I’ve found it so helpful that I’ve condensed it to a single slide which has been hanging over my desk ever since:

Managing Documentation in a Nutshell

Some of these practices come pretty easy: Building trust is a given in many workplaces. In fact, if you don’t, chances are you won’t succeed as a lone writer.

Other practices require dedication and discipline. If there’s little incentive in your company to keep metrics or to profile users, such efforts start out as pet projects. But you’ll see colleagues and managers taking note fairly soon, when you back up suggestions to change documentation or deliverables with such evidence.

Taken together, these practices can remind you of the business sense of being a tech writer among the nitty-gritty of everyday writing, editing and publishing. They can make you a more complete (lone) writer and an asset to your company – present and future!

To learn more about the Information Process Maturity Model, see JoAnn Hackos’ article “Using the Information Process-Maturity Model for Strategic Planning“.

If you have any ideas or questions about advancing documentation as the lone writer, please leave a comment!

– Thanks to Michael and André, my managers who gave me the freedom and support to expand my responsibilities and the value of the documentation.

5 Responses

  1. Hi Kai,

    Send regular status reports to line managers, ie so they know what you’re doing and

    Give credit to those who helped you when a project is completed. Everyone deserves a little recognition.

    Ivan

  2. Thanks, Ivan, both are excellent points!

    By giving credit to reviewing SMEs and editors, lone writers can subtly point out what all else goes into doing documentation right. Often, managers and colleagues of lone writers don’t have a full picture…

  3. I’ve done a lot of short-term contract lone writer gigs. My advice to other loners is to get yourself plugged into all the info sources you can find on the product(s) you will be documenting: Design and requirements specs, product team meeting minutes and status reports, online shared directories, bug reporting systems, the dev content management system, e-mail distribution lists for the team and product, etc. You may get a lot of useless stuff, but you will find some references to changes you will need to know about that no one will remember to tell you about directly. You need those notices so you can keep up and track down what the users will need to know, even when no one thought you might need to know about it.

    • Thanks for the excellent advice, techquestioner! Yes, I can confirm that: If you have an encyclopedic bent and an eye to separate the relevant from the irrelevant, by all means, get your hands on anything that so much as mentions the subject of your writing.

      If you have a long-term relationship with the company, they will soon learn to value your ability to track down information that few people remember that it exists.

  4. […] may not formally manage anything but your documentation and yourself. (See my previous post “Manage documentation as a lone writer“.) But each stage also adds more value to the documentation you produce – and hence for […]

Leave a reply to Your perspective shapes your work and your future « Kai's Tech Writing Blog Cancel reply