I have explored a very simple three-parameter model for growth and productivity in organizations during the transition period when we are assimilating new hires. I have modeled "useful hours" and "overall organizational productivity" as a function of growth rate, new team-member productivity, and organizational assimilation effectiveness. While the model is simple, it shows that high growth rates are risky and that the combination of high growth and low new-employee productivity can be disastrous. Note that this occurs even under the assumption that the steady-state productivity of the new employees equals that of the existing ones. Add to that an organization that is inefficient in assimilating new team members, and you have the recipe for a perfect storm.

Even if the new hires are as good as the people already in place, there is yet another danger: The new, larger organization may be less productive, per capita, than before. Overall productivity may suffer due to size and scaling effects, such as the increased overhead of more communication links, and so on. Our model ignored these effects.

What happens in reality is often even more insidious: In our attempt to grow faster, we often lower our recruiting standards. When this happens, not only is the combined "growth + training hit" large, but there is a dilution of the talent pool, leading to a permanent lowering of productivity even after the ramp-up is complete. The problem for the organization is a difficult one: During the ramp-up period, we attribute the decrease in productivity to ramp-up activities; it is only after that period is completed that we observe that our overall productivity has suffered. By then, of course, it is too late. A long-term problem has escaped us under the guise of being a transitional or short-term one; there has been "masking." That is why it is crucial when hiring to always bring people on board who, in steady state, will raise the average productivity of the group.

Along the way we made an interesting observation: Although our model was very simple, it led to several non-linear relationships. We have poor instincts for things that are non-linear. The graphs that we produced to illustrate the interdependencies amongst the variables revealed structures that we had not foreseen. It is these "hidden" structures that cause otherwise good managers to be surprised; things diverge on them more rapidly than they expect because of non-linearities. Cutting just one more month off a schedule by adding people sometimes has disastrous consequences if you are already in the "yellow zone" without knowing it. That last seemingly small step pushes you over the cliff and into the abyss. Better to draw some graphs and understand where you really are than to scream loudly on the way down.

Attention should be paid to the suggestions I made to improve the parameters P and D that govern everything else. This is the "call to action." Models are useful only to the extent that we use them to understand nature and then work on changing the values of the parameters that negatively affect our performance.

The model made several simplifying assumptions about which I prudently tried to warn you. If, based on these assumptions, the model predicts productivity and cost effects that are unpleasant, it behooves the manager to proceed with caution. The reason is simple: Nature is rarely as kind to us as the mathematical model. When Mr. Murphy (of "Murphy's Law" fame) adds his contribution to the mix, one can be sure that the results will in general be worse than what our models predict. One needs to have a margin for error. So "taking the model with a grain of salt" means this: If the model says you are OK, proceed with caution; if the model says you might have a problem or be in a high-risk situation, back off and reconsider. In most situations, managers are too optimistic in estimating the parameters that go into the model, and that, coupled with some of the "ideal" assumptions that go into it, can lead to project Hell.

The Software Development Edge(c) Essays on Managing Successful Projects
The Software Development Edge(c) Essays on Managing Successful Projects
Year: 2006
Pages: 269 © 2008-2017.
If you may any questions please contact us: