Select Page
One of the perennial questions that development teams face is the struggle to staff a full time technical writer. Of course, I have an opinion on this…but I was quite stricken by Kenneth S. Rubin’s analysis of this very question in his book, Essential Scrum. He frames the discussion in the context of cost-of-delay calculations, and the difference between idle work and idle workers. Consider:

Assume that we assign the documenter full-time for 12 months to work on this product, even if he is not needed 100% of the time. Doing so costs an incremental $75K (think of this as idle worker waste) above what it would cost if we brought him on for two months at the end once the product reaches the state of “all but documented.”
 
If we assign the documenter to do all of the documentation at the end, we will need him full time for only two months, but we will also delay the delivery of the product by the same two months. If we delay shipping the product by two months, the calculated cost of delay in terms of lifecycle profits is $500K (lifecycle profits are the total profit potential of a product over its lifetime; in this example, that potential decreases by $500K).
 
In this example, the cost of the idle worker is $75K and the cost of the idle work is $500K. If we focus on optimizing the utilization of the documenter, we will substantially suboptimize the economics of the overall product. During product development we are presented with these types of trade-offs on a continuous basis…

Technical writers who have worked with software development teams will undoubtedly understand the challenge of idle work, while giggling at the notion of idle workers. Believe me, there’s usually a pretty hefty backlog of legacy documentation that is always in need of grooming. Not to mention the myriad other work waiting for her in the agile enterprise…

I also commend Rubin for expressing so clearly one of the reasons that most technical writers invest so heavily in being ready to roll when the product is ready (or as close to that as possible).