Growth Issues


Healthy organizations have a tendency to grow over time. Plainly speaking, those that are successful in getting done what needs to get done are called upon to do more. Usually this translates into growth, as measured by the addition of new people to the team.

A significant challenge facing any successful organization is how to stay successful as it grows. This is harder than it looks. The organization needs to continue to do well what it has been doing in the past; it needs to also succeed at the new challenges that are put before it; and, last but certainly not least, it needs to do both these things while assimilating new team members. And, issues of scaling become important; what was relatively easy to do when the team was small becomes more difficult to do as the team grows larger.

Even in periods of zero growth, there are the challenges associated with new hires. Those organizations that don't acquire periodic introductions of "new blood" tend to stagnate and succumb to group think; and there is always the addition of team members just to offset attrition, which I'll discuss briefly at the end of this chapter.

In Silicon Valley, in the arena of software development, we have seen a different problem: Organizations have a variety of reasons to attempt what I would call excessive growth. Management sees windows of opportunity as fleeting, and the addition of contractors or consultants can't always help. In an attempt to capitalize on a leadership situation or a beachhead established in a new market, organizations rush pell-mell to solidify their position through ultra-rapid growth; middle managers are asked to grow their organizations as fast as they can. The result is usually less than optimal. Certainly, when growth rates exceed 50 percent a year, one must understand that something very difficult is being attempted.

As early as 1972, in less politically correct times, Fred Brooks talked about adding people to software projects that were late, enunciating Brooks' First Law in his classic The Mythical Man-Month:[1]

[1] Brooks, Frederick P. The Mythical Man-Month: Essays on Software Engineering. 2nd ed. (Boston: Addison-Wesley, 1995), 25.

Adding manpower to a late software project makes it later.

We examine a variant of the same idea. What is new here is a quantitative generalization to other provocations for growth in organizations, not just as a knee-jerk reaction to being late. In other words, we look at Brooks's notion of the lack of interchangeability of "men" for "months."

There are two interesting data points in Brooks' notes. Vyssotsky, on page 179, estimates that large projects can sustain growth rates of no more than 30 percent a year without suffering. Yet, in the very same note, Corbató is quoted as pointing out that long projects must anticipate a turnover of 20 percent a year; this means a significant need to integrate new people, just as with growth. Clearly, given this narrow band of approximately 10 percent between what must occur and what is difficult to accomplish in long, large efforts, we need to better understand, in a quantitative fashion, the dynamics of adding people to projects.

Other previous work in this area is usually qualitative and anecdotal, probably because the hard data needed to validate models of this type is difficult to come by. Shooman is one of the rare exceptions; his treatment is more complex than mine, but a good starting point.[2]

[2] Shooman, Martin L. Software Engineering: Design, Reliability, and Management (New York: McGraw-Hill, 1983), p 469-479.




The Software Development Edge(c) Essays on Managing Successful Projects
The Software Development Edge(c) Essays on Managing Successful Projects
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 269

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net