| Now that we understand how the various factors interact to affect productivity during periods of growth, we are faced with the question of doing something about it. I have three suggestions: Whenever possible, use real data to estimate the parameters P and D. These are the ingredients in computing the multiplier M, on which everything else depends. Pulling numbers for them out of the air will likely lead you astray. Not all organizations keep records that are detailed enough to help. On the other hand, you can look at hours explicitly devoted to training, for example. These go into both P and D, as both new employees and old are involved. All meetings should be looked at to see whether they are primarily product-related or focused on getting the new hires up to speed. The better you can estimate P and D, the better the numbers you will get coming out at the other end. Think hard about P when evaluating new hire candidates. The model is most sensitive to P, and nothing can overcome a low value for it. Selecting fast learners is always a good thing; slow learners have low P and should be avoided. Look out for a "missing skill," such as specific knowledge about a programming language or technique that allegedly can be picked up easily. Even very bright people take time to learn new things; if these things are to be learned on the job, you are agreeing to reduce P for that person. Avoid hiring people who come from a company culture that is radically different from yours. There is an implicit and somewhat large decrease in P (and a corresponding increase in D) for hires who have the additional learning burden of adapting to "how we do it here." If the new hire has a tendency toward inflexibility, these factors will be magnified still further.
Think of D as amplifying the effects of a low P. Ironically, smaller organizations may have larger D than more mature organizations. This is because they have most of their organizational memory stored in the brains of a few people. When new people are brought on board, there is no way to get them up-to-speed other than one-on-one dialogs with these key people. A few things are obvious: Hire and train new people in batches, so you can get some economy of scale in the adaptation process. To the extent possible, invest in documenting "how things get done," so that new hires can read materials instead of having to take time from existing team members every time a question arises. For software development organizations, having well-written and well-documented source code can dramatically diminish D, as well as help to increase P.
There is no "silver bullet" here, but understanding the importance of both P and D can help managers keep the damages to a minimum. It also allows us to estimate the return on investment of things like documentation. Reducing D by a few tenths can tell us how much we will improve the overall productivity and reduce our incremental cost during our next growth period. We can then compare the cost of reducing D in this way with the benefits that would accrue. |
