Buy yourself time as a lone writer, part 2

To be “making it as a lone writer“, you need time. Time to develop your skills, improve the documentation, reach out and network with other teams.

Last week, I talked about some strategies to buy yourself time. You can, for example, move to(wards) topic-based authoring. This eliminates internal inefficiencies, namely those you can deal with yourself.

To buy yourself time, you can also try to:

Fight external inefficiencies

These are inefficiencies that encroach on you from other teams and give you a hard time. Here are two common examples:

Don’t test the product when you should be documenting it. It’s late in the production cycle, and you’re already looking at a tight schedule. You really have to start documenting now to ship on time. And then you find bugs and inconsistencies in the product and interface all over the place…

Testing as a lone writer is not a bad thing as such. Often, it’s what makes the job so interesting and diverse. The problem is if the time isn’t budgeted. Make sure such time and efforts are accounted for. If you enjoy testing, make sure your manager knows you’re doing it, and that it you need extra time for it.

If you cannot test efficiently, or if it’s actually someone else’s job, try not to do it. Yes, “we’re all in this together, and we have to cover each other’s backs”, but that shouldn’t mean that you pick up all the loose ends, just because you’re last in line. Being in it together doesn’t mean taking it out on the lone writer.

Time and again, I’ve “given back” products for testing along with a list of 19 bugs I’ve found in the first hour of documenting. Most managers actually understand that I cannot write documentation efficiently on unfinished or buggy products. To fix this problem, you might need to address a larger issue:

Insist that documentation is included in the project plan. Often, lone writers drop off the radar, and their efforts are not planned appropriately in the project plan or the production schedule. It should be, of course. Your manager and your project managers might not like to hear it, but good documentation takes an adequate amount of time. If they don’t believe you, let them compare measly quick starts that can be thrown together in two days with tutorials or manuals that might take two weeks or longer.

Lone writers are often not used to stand up for their documentation like this. Still, I’ve found it well worth the effort: You can start small by simply inquiring about the project schedule. Maybe you’ve heard about a strategic project or an important customer, and you want to make sure you can deliver good documentation along with it. It shows you’re taking an interest in the project as a whole and your position in it. Managers can’t push you away so easily, once they’ve understood your engagement will help their project – even if it means budgeting extra time.

Usually, project managers have pain points that you can appeal to: Maybe a certain level of documentation is part of the requirements, so it should be planned like any other part of the product? Maybe they’ll latch on to better documentation to buy themselves time and appease the customer? (They can’t very well say they need the extra time also for last-minute development and testing…)

Your turn

What other inefficiencies steal your time and energy? How do you cope with them? Feel free to leave a comment.