Productivity Counts: What if your measure the effectiveness and productivity of your team members?

Home/Publications/Best Practices Newsletter/1999 – Best Practices Newsletter/Productivity Counts: What if your measure the effectiveness and productivity of your team members?


August 1999

Productivity Counts: What if your measure the effectiveness and productivity of your team members?


“I have the most productive technical publications group in the valley,” Carl boasted. “We produced documents at a rate of one hour per page.” “How so?” I asked. “That’s way below industry average.” “Well, don’t tell anyone, but we counted all the pages we reproduced and shipped that came directly from the engineering group.”

Not only was Carl cheating by not counting all the work done by the engineers, he was digging his department into a hole. He needed to improve the productivity of his writing staff. They were well known in the company for producing masses of useless information, much of it full of errors. But any effort to improve the research and writing done by his department would make his productivity numbers get worse.

Measuring productivity means figuring out how many goods and services are produced and how many people it takes to produce them. If the number of people working increases (full employment these days), so should the number of goods and services they produce.

How do we bring this concept home to technical communications? Technical writers produce documents-lots of them. We could measure how much they produce by simply counting the documents. If Sam creates three new manuals in a year and Sally create five, that means their average output is four new manuals each. If Sam produces four new manuals next year but Sally only produces three, that might indicate that their average productivity has decreased from four manuals to three and a half.

We all recognize that simplistic measurements like counting the number of manuals produced gives us some information about our department’s productivity but not much. So we start looking for more meaningful measurements.

Measurement one-the number of documents produced by our organization per year, including new and revised documents. The goal might be to produce more successful documents with the same staff.

We have traditionally counted pages rather than documents, believing that by counting pages we even out the productivity measure. Sally may write five new manuals and Sam three in a year, but if Sally’s manuals have 50 pages each and Sam’s have 150 pages, Sam is clearly producing more pages and more words than Sally. That makes Sam more productive.

“Wait just a minute,” argues Sally, “my pages are a lot more difficult to write than Sam’s. It’s not fair to count all pages as if they were the same.” If we want to be fair to Sally, we have to add a complexity measure, giving her extra credit for producing difficult-to-write pages.

Measurement two-the number of pages produced by our organization per year, new and revised, with a complexity weighting factor added in. The goal might be to increase the number of weighted pages produced by the same number of people.

Software developers face the same dilemma when they count lines of code produced per person per year. A sloppy, disorganized programmer might produce more lines of code than a well-organized, effective programmer, even though they both produced the same number of functions. As a result, software development has begun to measure functions produced instead of lines of code. Functions refer to parts of the program that do something useful, such as: sending text to a printer, drawing a graphic dynamically, performing a mathematical calculation, or searching a database.

In technical communication, what can we measure that might be similar to functions in software? We could measure how many user tasks are successfully explained by our writers. Counting user tasks in the documentation is easy; measuring success is likely to be more difficult. We might begin with “errors.” Errors are reasonably easy to detect if we verify the accuracy of the documentation by testing it against the product. Aside from outright mistakes, however, measurement becomes more difficult. We might use usability testing of a writer’s work to see if typical users find the task-oriented information easy to follow. The more problems the users have interpreting the written instructions and background information, the less productive the writer has been.

“Well,” I already hear you arguing, “what about the complexity of the information and the level of knowledge and experience the user brings to the task? And what about the product? What if it’s so difficult to use that no one can explain it?” You’re right! But if we spend a lot of time producing information that is not useful (or products that aren’t easy to use), we certainly aren’t going to get any rewards in the long run.

Measurement three-the number of successful sets of functional information delivered to the users each year. The goal might be to deliver more successful functionality each year in proportion to the number of people on the staff.

We can also measure writer productivity by looking at the amount of extra work for others in the department that an individual writer generates. For example, Dan is an experienced and highly competent senior writer. He follows templates scrupulously and knows the department’s style standards by heart. When his work goes to Mike in the editing group, Mike knows he can plan a quick review, handing minor comments back to Dan. When the production team gets Dan’s books and help topics, they know they’ll have only minimal cleanup to get them ready for printing and web publishing. Everyone in the internal support groups benefits from Dan’s work habits. They would call him “very productive.”

In contrast, when the editing team receives documents from Joan, they’re almost afraid to open them. They know that Joan’s work will be full of spelling mistakes (Joan can’t even be bothered to run the spell check program) and grammar errors. They also know that they’ll have to “bleed all over” Joan’s work because she has a difficult time organizing her writing and communicating ideas simply and straightforwardly. The production team also fears Joan because her documents are full of stylistic variations. She changes the standard styles constantly, which means that her files don’t convert cleanly. Joan and Dan produce the same number of pages per year, but Joan is far less productive (and everyone but Joan’s manager knows it).

Measurement four-the amount of rework staff members generates for themselves and everyone else on the support team. An organizational goal might be to reduce the amount of rework done.

Rework could also apply to the relationship between the writers and the developers. Since we generally ask product developers to review draft documents for the accuracy of the information, the amount of rework they generate is another potential measure of our organization’s productivity.

The list of productivity measurements quickly becomes long. We might measure, for example,

  • the total number of hours it takes to move a document through the information development life cycle
  • the percentage of time spent on each phase of development activities (planning, organizing, writing, researching, editing, illustrating, and so on)
  • the number of technical communicators compared with the number of product developers in an organization

We’ll talk more about these metrics in the next issue. CIDMIconNewsletter