Tips for Distributing the Workload Among Your Team -- Answering a Reader's Question

by Tom Johnson on Jul 23, 2008
categories: technical-writing

Sebastian asks,

I have been searching the web for information about how to divide workload among writers as the the workload--and the department itself!--grow. I am thrilled to find your blog! I am a new writer in a Health Information Systems doc group. We write for 120 products, maintain 600+ documents (several output formats). Do you know of any effective strategies/tools/medications?

What kind of documents do you produce?

We produce online help, how-to guides, quick reference guides, manager's guides (procedural content), introductory guides (conceptual content), release notes, configuration guides, known product issues, tutorials....

Do you do translation too?

Translation/localization of deliverables seems to be evolving here. There is an international department who have a couple of writers . . . What happens might be translation but is not certifiable localization.

Any other factors that caused the increased workload?

I think what broke our system was an acquisition that increased department size by about 50%. Our lead writers had been coordinating work across product families, but the definitions of product families have gotten a little too fluid, and the workload has gotten so huge that we can only do part of what's needed, so there's now a backlog and it's growing, and we' in the midst of this move to AuthorIt, which adds work in itself.... We'd like to know what really big teams do to keep everything coordinated.

Our 50% increase did include some writers, and I know that part of the chaos comes from trying to train people on new products at the same time they're trying to meet deadlines. But I think if I could condense the problem to a single category, it would be about coordination and communication--knowing what's going on across that broad range of products, having the workload allocated so that the deadlines are distributed reasonably, that sort of thing.

Did the 50% size growth include an addition of new writers?

I guess I envision that other groups have tools of some kind that automate this kind of tracking, or they have some information-exchange routine, or a set of job assignments that somehow pull all the information together and keep the workload balanced.

I'm using an online project management system for tracking how hours are spent, spreadsheets for trying to balance workload (don't even ask--corporate decisions prevent us from using a single tool for both types of tracking), lead writers for keeping up on product family information, and all kinds of meetings--methods that worked when there were 12 of us but that don't seem to work now that there are 18.

Dear Sebastian,

Thanks for writing. I'll share my thoughts and others can build on them in the comments if they have anything to add.

Get Professional AuthorIt Training. About AuthorIt, one thing I recommend is that you get someone to come in a provide training on it. It can take months before you feel comfortable with a robust product like AuthorIt. When I was in Florida, a colleague at another company was moving to AuthorIt (from RoboHelp). She hired Char James-Tanny (helpstuff.com) to come out and provide 3 days of training. It worked pretty well. I would recommend that training for your company too, unless you already have AuthorIt gurus.

Set Up AuthorIt Templates. I also recommend seting up AuthorIt templates and styles for the entire team to use, or even pay the trainer to come in and set them up. This can reduce the learning curve.

Insert Writers Early On in Software Development. As far as distributing the workload, inserting the writers into the software development process early is always best. That way they can stay in the loop through the entire process and be better aware of changes and other information that affect documentation. It's the last minute emergency documentation needs that stress writers out. Or being expected to write documentation without complete information and access to the product and SMEs.

Deliver Only What Users Want. You can also survey your users to ensure you're actually delivering the help content they want. If they only want online help and a short quick reference guide, you might do away with the long printed manual. (See this post for more info.) Of course, if you set up the AuthorIt templates and styles right, single sourcing to print shouldn't be too arduous.

Provide a Style Guide. Having a simple style guide helps avoid the guesswork of technical writing. When writers know what style is expected, they don't have to spend time making stylistic decisions. (But don't go overboard with a 200 page style guide. Keep it short and sweet.)

Lighten the Editorial Process. If you have a tedious editorial process, I'd recommend getting rid of it. At one company I worked, we had an editor that required multiple submissions, requiring at least 3 weeks total for reviews and edits. It slowed the process up a bit (although granted, the quality increased). Short peer edits are more practical in my opinion.

Have the Manager Meet with Each Team Member Weekly. A good manager can help allocate resources well, and make sure each writer has an appropriate amount of work -- but only if the manager is in tune with each of his or her team members. One time I had a manager who met with each of us for 30 min. to an hour a week. The outward purpose was to get a report on how we were coming along with our projects. But it transformed into much more than this, as we wandered into tangents and talked about other things. I found this one hour with my manager each week to be the best thing a manager has ever, ever, ever done. Honestly, it built rapport. It let the manager know exactly what the workload was for each of us. It allowed us to communicate any problems we were having, either with access or with reluctant SMEs. No tracking software can replace face-to-face communication.

Market Your Department. If you need more resources, you should let upper management know. If they don't want to pay for more tech writing resources, then push back on the deliverables, the timeline, or the scope. How are you marketing your dept. to your organization? Consider getting together the key senior leaders for a dog and pony show about the benefits of good documentation.

Publish in a Place You Can Update On-the-Fly. Are you publishing your help on a server separate from the application? When you have control to continue modifying the help once the product is launched, it removes a lot of the burden of a deadline. In my situation, I give the developers a link to the help. The link points to a Flare file that I have hosted on a SharePoint site. It works well because I don't have to stay up the entire night before a release creating video tutorials. In fact, by release time, I just have to have the basic help content out there. I can continue adding to it after the release date.

Another Perspective: Take Your Time

I don't know quite how to say this, but good documentation takes time. Rather than always trying to do everything faster, better, with fewer resources in less time and with double the quality, etc., consider that a slower, more labor-of-love-type approach isn't necessarily a bad thing.

I'm not recommending that you join the Slow Movement, but there's something to be said for taking your time with a project you're heart is in.

One of my favorite movies is Brother Sun, Sister Moon. It's by Franco Zeffirelli and from the hippy-era, and definitely dated and corny, but it gets me every time. Here's the song I like most.

The key line is this:

If you want your dream to be, take your time go slowly. Do few things but do them well -- heart-felt work is holy.

I'm engaged in a lot of activities, and sometimes I see my life getting stretched thinner and thinner. In addition to being a father of 3 young girls, a husband of a voracious blogger, young men's president in my branch, I also post regularly on my blog, publish a podcast, coordinate a social news site, and occasionally I teach courses on WordPress and do freelance web copy/design. I also love to play basketball, go on Saturday outings with my family, and read nonfiction tech content. This past week, I said to myself, Tom, focus on what you really want, and simplify your life, because you're not doing any of these activities particularly well.

I think the same can be said for documentation. Focus on what really matters -- the application that's going out to 20,000 users, or the one designed for the highest-paying customers, or the application that generates the most calls to the support center. Give that your highest priority by doing it first. Then work on the less important tasks. (It's the Stephen Covey big-rocks-small-rocks principle.)

The other stuff will get written eventually. The world won't stop. This is the one comfort to being a tech writer: while your work is valuable and incredibly important, no one is going to delay the product launch if you aren't ready.