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.

4 Responses

  1. The biggest problem for me as a lone writer has often been having the project manager not allow the SMEs time to review the documentation for technical accuracy. The writer who has only used and written instructions for using the product may not legally qualify as a technical expert. Therefore, most companies aware of their legal vulnerability require that technical specialists and project managers approve and sign off on documentation before it is released for public use. Waiting for those sign-offs can waste the shrinking time to the release deadline, when the writer would rather have already completed any revisions resulting from the sign-off reviews.

    • Good point, Techquestioner! It doesn’t help us lone writers to be super-organized, only to have our schedule thrown off by late reviews. The legal requirement you describe is certainly the safe or even mandatory route, but it doesn’t help our schedules…

      If at all possible, I try to work closely with my reviewing SMEs, so that they can understand the importance of their role in the review process, what exactly I expect from them and how much time it’ll take. I’ve also found “save the date” heads up emails helpful to let them know a review’s coming up in a few weeks.

      If I manage a more personal relationship, I can also appeal to their professional honor, so they’ll find it harder to let down the company, the product and their colleagues.

  2. Thanks Kai! I’m fortunate enough to work with people who understand the value of using the tech writer early and often. However, there are lots of projects, and often one-offs that pop up at the last minute. For me, external inefficiencies occur when two or more projects converge at the same time. Communicating across teams and planning ahead are the keys for me.

    • Thanks, Bill – yes, volatile assignments can throw off the best planning. I’ve been quite lucky so far: My last-minute jobs often ran in parallel with last-minute efforts by developers – and their last minute often took longer than mine… 🙂

      You’ve said it, it’s all about communicating across teams. That’s shaping up to be the motto of this whole lone writer post series: We’re trained to be communicators, and we even “train” our topics to play nicely with each other – so there’s no reason why we can’t do the same.

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 )

Google photo

You are commenting using your Google 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: