Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

The work keeps piling up -- who can do it all?

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.

And a round version.

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.

We are hiring two new technical writers and are trying to come up with a practical for the candidates to complete. We had been asking the applicants to write a quick how to (e.g make a pb&j, withdraw cash from an ATM, etc.) followed by a longer writing sample, but our HR rep isn’t sure if this is the best qualifier. Any ideas? What test have you completed in the past when applying for tech writing
positions.

Although I’ve taken various tests before for job interviews, such as documenting how a small company widget works, or finding all the spelling and grammar errors in a document, or actually taking an IQ test, I’m not a fan of tests. Do you ever give doctors a test when you interview them? See now, go into the next room and try to figure out what kind of disease the guy has. You’ll have 30 minutes to write a diagnostic report. Or to a lawyer — we want to see if you’re actually qualified for the position. Please write and deliver and 3 page court presentation arguing a case of insanity for the unabomber…

If I were hiring a technical writer, rather than administering tests, here are 10 things I would do to evaluate the candidate:

1. Ask for writing samples. Writing samples are by far the best indicator of ability. The only problem is that often writing samples are proprietary and confidential to the former company, and if the writer is seeking a job without the current employer’s knowledge, it’s hard to acquire these samples legitimately.
2. Ask the candidate to evaluate your company’s existing documentation. What would he or she change? How would he or she approach the same material?
3. Ask for evidence of enthusiasm. My favorite interview question is, “What have you done in the past 6 months to demonstrate your enthusiasm for the profession?”
4. Check out the candidate’s blog to see if he or she is an interesting person. If there is no blog, Google the candidate. If you can’t find anything anywhere, be skeptical about the answer in #3.
5. Ask the candidate to explain his or her strategy for single sourcing. This is a great way to gauge the candidate’s awareness of current trends.
6. Talk with the candidate about random things. Ask yourself if you would enjoy having the person as a co-worker.
7. Have other technical writers meet with the writer, especially if you’re not a writer yourself. Writers can sometimes quickly sense whether someone knows what they’re talking about, similar to how developers or designers can judge the same about people in their fields.
8. Ask the technical writer what his or her favorite manual is and why. This will get the writer talking about best practices.
9. If you must give a test, ask the writer to create a video tutorial describing how to do something software related. Hiring managers often give writing tests, but hey, technical writers don’t just live in the written word. You want someone who can do video too. In fact, I just received a comment today on a quick Dokuwiki video I made last year. Sarah writes, “I just finished watching your video on setting up Dokuwiki (http://www.idratherbewriting.com/video/dokuwiki.html). This is not only a very useful video, it’s the future of tech “writing.” Thanks for sharing it.”
10. Check to see whether the writer formatted his or her resume with styles. This is my friend Mark Hanigan‘s pet peeve. Whenever he evaluates resumes, he first looks to see whether the content is structured with styles. It’s subtle and anyone who isn’t familiar with structured authoring will completely miss it. But you don’t want to hire someone who doesn’t understand the concept of styles.

Finally, if you are determined to administer a writing test, please make it software related (unless your company doesn’t make software). And also make it difficult. For example, provide instructions on how to speed up your Firefox browser.

April 6, 2008 Update: I have officially changed my mind about writing tests. While I initially thought they were insulting, I now think they are essential. I guess I had to experience for myself an interaction with someone whose writing I felt to be subpar. It lacked thoroughness, wasn’t easy to follow, was poorly organized, sometimes unclear, and was overall not something I’d want my department name attached to.

Many candidates pose as technical writers but really lack the skills. Writing tests can help weed these candidates out. I guess I’ve come full circle on this. I now would also encourage a writing test, and require that candidates provide instructions on how to document a typical company widget. When you get that writing sample, here are some obvious signs that you shouldn’t hire them:

• The writer doesn’t use numbered steps.
• The procedure had 20+ steps without being broken into separate tasks.
• The writing is unclear.
• The writing is poorly organized.
• The formatting is sloppy.
• The writer doesn’t structure the content with styles.
• The steps are inaccurate.
• Field definitions aren’t illuminating.
• You can spot misspellings and grammar errors.

My alternate tests are still valid. I’m just now endorsing the standard writing test.

As an added bonus, requiring writing tests will drastically reduce the number of candidates who apply.