Small is beautiful: A study of packaged software development teams

SMALL IS BEAUTIFUL: A STUDY OF P A C K A G E D S O F T W A R E D E V E L O P M E N T TEAMS

ERRAN CARMEL BARBARA J. BIRD American University

Writers in diverse fields have recognized the advantages of small teams. The common justification is, not that a small team is so advantageous, in and of itself, but that the alternative--a large team--is so disadvantageous, primarily because of the burden of maintaining n*(n-1)/2 communication links between the n team members. We established the following rule derived from the literature--a team often or above is a violation of"small is beautiful." We examined data from 74 product development teams in a cross section of packaged software companies. First, using the rule, we found that most teams in these finns were small with a median of five members. Only 15% of the firms violated the "small is beautiful" rule, and only when the number of employees in the firm neared or exceeded 100. Three factors were identified to explain why the teams remained small: there was a proactive policy about small teams, the release was relatively minor, and teams were permanent rather than ad hoc. Four factors were identified to explain why those teams that violated the "small is beautiful" rule grew beyond small: product size and complexity, firm age and ossification, non-desktop roots of the software products, and ad hoc teams rather than permanent teams. Brief case studies illustrate our findings.

INTRODUCTION

I w e n t o v e r to D a v i d and asked h i m " i f m o n e y w e r e no object, h o w m a n y m o r e p e o p l e w o u l d you hire [to a u g m e n t y o u r five-person team] to get this thing out by the first o f June instead o f S e p t e m b e r 1 ?" D a v i d replied "I w o u l d hire three p e o p l e and w e ' d h a v e to push it out 'til D e c e m b e r before I could e v e n g i v e you a date. L e a v e m e alone and I ' l l get it d o n e on time. President, 65-person p a c k a g e d software firm.

Direct all correspondence to: Erran Carmel, Kogod College of Business Administration, American University, Washington DC 20016-8044 USA; Fax: 202 885 1992: E-Mail: [email protected]. The Journal of High Technology Management Research, Volume 8, Number 1, pages 129-148 Copyright O 1997 by JAI Press, Inc. All rights of reproduction in any form reserved. ISSN: 1047-8310.

130

THE JOURNAL OF HIGH TECHNOLOGY MANAGEMENT RESEARCH VOL. 8/NO. 1/1997

The phrase Small is Beautiful was popularized by Schumacher (1973) as a cry against the idolization of what he termed "giantism," or economics of scale. In the ensuing two decades, there has been a significant shift in the business culture to recognize that entrepreneurship and small teams--rather than large ones--are key factors to success and innovation. Small teams are advocated for everything from corporate committees, government units, to technical design activities. At roughly the same time, Brooks' difficulties with large software development teams at IBM were chronicled in the classic Mythical Man Month (1975). Brooks' Law, "adding manpower to a late project makes it later" has direct implications on team size. In the ensuing two decades, Brooks' Law became one of the most broadly diffused dictums in software management. In brief, we set out to determine if all this accumulated wisdom has been heeded. In our own studies of high technology firms--specifically packaged software organizations--we were struck by the small size of the software development teams. The focus in this study is on packaged software, 1 representing a segment of high technology that is growing particularly rapidly and steadily. Packaged software is a term we use to cover all types of tradable software products: shrink-wrapped products, mainframe accounting systems, operating systems of all sizes and platforms, software tools, as well as content software, such as games. Packaged software is particularly interesting vis-a-vis teams because, while it is still an aggressive, vibrant, entrepreneurial segment, it is also one in which a number of companies have grown to be quite large and successful on a global scale. In the next section we review the literature on team size and then posit our "rule" on small teams. Then we present our research methodology, followed by our data and analysis. We answer each of the following questions: • • •

Are the software development teams really small? H o w do some of the larger firms manage to keep their teams small? If small teams are so popular, w h y did the large teams grow b e y o n d "small"? LITERATURE REVIEW

Team Size & Group Size The literature is unanimous in advocating small teams. The common justification is, not that a small team is so advantageous, in and of itself, but that the alternative--a large team--is so disadvantageous. Hackman (1990) states that if a task requires four sets of hands, the team should have no more than that. Wicker et al. (1976) go one step further, stating that the team should be slightly smaller than is technically required. Katzenbach and Smith (1993) find that the majority of effective teams number less than ten members. In fact, their definition of team purposefully uses the word "small" as a descriptor of team. Of course, the rationale for small teams is premised on the belief that characteristics of "smallness" lead to positive performance outcomes (see Figure 1). Software performance outcomes may be measured by product quality, timeliness, or budget. We are aware of only one study that directly examined this relationship: Littlepage (1991), in an experimental study, verified the negative correlation of group size on performance.

Small is Beautiful

131

E

Team Size FIGURE 1 Common Belief About Relationship of Team Size and Performance

Other studies examined an important related variable, the effect of intra-team communication (discussed below) on performance, finding a positive relationship (Allen et al., 1980; Rubinstein et al., 1976). However, such studies seem to be the exception: by and large, both scholars and practitioners simply accept the conventional wisdom that small teams improve performance. In a software engineering textbook Schach (1990) writes that if a software product would take one person one year to complete, it would most likely take three people one year to complete--and not four months--and it would most likely be of poorer quality. Not all work units are called "teams." Other terms are often used, the most important of which is "group." There does not appear to be a consensus among social scientists on when a work group (or team) shifts from being an ad-hoc collection of people into a collective with substantially different properties. Organizational theorists usually follow Hackman's (1990) conceptual definition of a work group which distinguishes it from non-group entities. Hackman (1990) focuses attention on real groups with tasks to perform in an organizational context. A real group is one perceived to be an entity by its

132

THE JOURNAL OF HIGH TECHNOLOGY MANAGEMENT RESEARCH VOL. 8/NO. 1/1997

members and recognized by non-members (i.e., it has a boundary, people know who is a member and who is not); members have some degree of interdependence for some shared purpose; and members develop specialized roles within the group. Guzzo and Shea (1992), using the terms group and team as synonyms, state that "Groupness" seems to be a matter of degree. Our definition of team is synthesized from these and other sources: An organizational work unit with a clearly defined task and a high degree of interdependence and intra-communication among its members. Peak performance is expected from all members (rather than just some). Members share in a single reward, rather than only the sum of individual rewards. Within the population of teams, our unit of analysis is defined as the product development team, a commonplace unit for new product development (Brown & Eisenhardt, 1995). Our specific interest is in teams that develop software packages. These teams are typically made up of individuals with functions such as: programmer, designer, analyst, developer, architect, project manager, team leader. The team may also include: quality assurance specialist, tester, marketing engineer, president and CEO, and technical support specialist. The starting point for the ideal team size is a team of one person (cf. a similar quote attributed to David Cutler, architect of Microsoft Windows-NT, in Zachary, 1994: 146). Software is an artifact that has an enormous number of interdependencies in its components which are not physical but rather symbolic. Thus, a one person "team" can keep most programming logic in her/her head, but once the program grows in size and complexity, and the number of people involved grows beyond three, or five, or seven, it is humanly impossible to do so. Consequently, the principle argument for small teams is that "smallness" helps to ensure effective, dense, intra-team communication between all members. A small team has the simple arithmetic property that there is a manageable number of communications links. Steiner (1972) argues that groups begin to lose effectiveness at about 8 individuals. At eight members a group must manage 28 communication links, following the formula n*(n-1)/2. The "magic" number eight has made its way to some unusual teams: based on this literature the Biosphere II project chose eight bionauts for a multi-year assignment in an enclosed artificial environment. Fried (1991) calculates that in groups of ten or fewer members, 55% of each employee's time can be considered productive (after discounting for communication needs); when the size of the group goes up to 100 members, only 5.5% of each member's time is productive. The shear number of links leads to the deterioration of communication quality: Curtis et al. (1988) point to communication breakdowns, resulting from the large number of communication links, as one the most critical problems in systems development. Numerous other disadvantages are advanced for larger teams. Fried (1991) points to two: the commons dilemma (in which the individual member uses up team time inadvertently) and social loafing (in which individuals in larger units do not contribute their maximum individual effort). Katzenbach and Smith (1993) also emphasize that larger teams have problems of finding physical work space and meeting time. Larger teams find it more difficult to build the team by intensely sharing viewpoints and are more likely to settle for ambiguous visions of their goals that are determined by hierarchical leaders.

133

Small is Beautiful

Over the years, two strategies have emerged to alleviate the communication links problem in software: information hiding and new team structures. First, although intra-team communication is inevitable, not all scholars and practitioners accept the premise that communication necessarily be encouraged as much as possible. Information hiding has repeatedly been proposed for software development (Parnas, 1972; Zahniser, 1990) to alleviate the communication burden. Information hiding is a general design concept that calls for properly structuring the software's modules such that the design logic is hidden from its user--the programmer. If the programmer has to comprehend less design logic this can reduce the amount of communication needs. Extensions of the principle of information hiding can be found in many of the software development improvements of recent decades: structured design, Computer Assisted Software Engineering, and most recently, software objects. Second, interesting team structures have been proposed (although they have never been accepted in industry): chief programmer (analogous to the chief surgeon in medicine) and egoless programming (in which team membership is perfectly equal rather than differentiated by status).

Team Size Examples From Industry Many of the most innovative and significant packaged software products were developed by very small teams. Eric Schmidt, Chief Technology Officer at Sun Microsysterns (Higgens, 1996), points to several instances to support his own strong advocacy of very small teams: Unix was developed by two people, Java by "less than five," Mosaic by "two to four," and the Mac (including software) by twelve. During the 1980s, the dawn of microcomputer packaged software, many of the well-known products came out of small development team efforts (and some were done by one solo programmer). Two collections of 1980s software success stories illustrate this: of fifteen software "wizards" in Levering et al. (1984) ten wrote their products in teams of 2-4 members. Most of the 19 "super-star" programmers in Lammers (1986) advocated small teams or solo programming. Lessons from two influential software leaders, Microsoft and IBM, offer insights to the industry's practices regarding teams. It is often argued that, in spite of Microsoft's enormous success and rapid growth, the company makes a deliberate effort to keep the culture of the firm like that of a small entrepreneurial firm. These efforts include keeping the teams small. In the 1980s Microsoft development teams, particularly for applications software, remained relatively small. For example, the first Microsoft spreadsheet was built by a team of five (Cusumano & Selby, 1995). However, as the products matured and as the firm grew, team size grew. A 1990s spreadsheet, Microsoft Excel, had a development team that peaked at above 100. Systems software efforts grew even more quickly, in part because of greater inherent complexity. Development of Window-NT's first version began with a team of about thirty for its first phase, in the late 1980s, and was released in the early 1990s after team size peaked at several hundred (250 according to Zachary, 1994; 400 according to Cusumano & Selby, 1995). This, in spite of concerted attempts by the NT project leader to keep the team small, and in spite of Microsoft having an unwritten "n minus one" rule (similar to Wicker et al.'s dictum) in which, if n people are needed, only "n minus one" will be used. IBM, the second software leader, still sells more software (measured in dollars) than Microsoft. IBM has been less successful than Microsoft in keeping its software development teams small. This harkens back to IBM's development of the OS-360 system in the

134

THE JOURNAL OF HIGH TECHNOLOGY MANAGEMENT RESEARCH VOL. 8/NO. 1/1997

mid 1960s that led to Brooks' Law (Brooks, 1975). In the early 1990s, IBM's desktop packaged software efforts grew out of control. Both the OS/2 and OfficeVision product development groups each grew to well over one thousand members, each at multiple sites, with costs exceeding one billion dollars (cf. Carroll, 1991), leading IBM to disband its desktop computing group in 1991. IBM's development approach can be viewed as a legacy of the MIS (Management Information Systems) environment for which its products were typically targeted. Even though Brooks' lessons from the 1960s are well-known in the software community, MIS departments still tend to form large project teams. Project size in MIS environments are typically thought of in terms of Rayleigh curves (Putnam & Meyers, 1992) in which the number of developers increases until it reaches a peak and then decreases once coding is near completion as members leave for other projects. As a reaction to excessively large teams, Martin (1991), an influential software industry writer, has advocated small SWAT teams (of small, highly-trained teams of programmers and designers) as one of the critical success factors for Rapid Application Development (RAD). In sum, team size is viewed as a perpetual industry problem demanding attention.

The "Small is Beautiful" Rule To aid our empirical research, we needed to determine the boundary between small teams and teams that are no longer small. We set this boundary for "smallness" at below ten members based on a preponderance of literature that sets the upper bound of a small team at eight or nine or ten. Steiner (1972), using group theory, defines the upper limit of a small team at about eight based on reasonable number of communication links. Fried (1991) defines ten as the upper bound because at that point an individual spends a maximum of 10% of the workday communicating with others. Filley et al. (1976) set nine as the upper bound. Katzenbach and Smith (1993) set the upper bound at nine. In summary, we state our rule: A team of ten or above is a violation of "small is beautiful"

Conceptual F r a m e w o r k As predictors of team size we propose firm and product characteristics as shown in Figure 2. Based on the logic of scale and the many anecdotes from the software industry we expect larger and older firms to employ larger teams. Larger firms require more layers of management and more formal "professional management systems" (Flamholtz, 1990). These requirements may trickle down to the development staff as a whole, and to the product development team itself. Furthermore, a successful firm may not closely monitor costs and thus apply excessive resources to product development. Older firms are also likely to be larger (Greiner, 1972). While younger firms tend to be flexible, responsive, "quick" (Quinn, 1985), and have less inertia, older firms tend toward ossification and loss of entrepreneurial spirit. Product size is also expected to influence the size of the team and be positively related to firm size. As the software product grows (and therefore becomes more complex), adding new functions and new platforms, the product components become more specialized and more people need to engineer and integrate these components.

135

Small is Beautiful

I

Firm ~ Age

~ Team

I I

Size

Firm

\

~ize

.

, f--.. ~

Legend

Develo Staff Si

Examined

in this study Demonstrated

elsewhere Expected, but

not tested h e r e

FIGURE 2 Conceptual Framework Used in This Study.

METHOD As part of a multi-year study of software development in packaged software, team-related data were collected over the years 1993-95 through written surveys and through structured face-to-face interviews. Each firm in the sample is represented by only one case (team) in the dataset. Of the 74 cases, 73% (54 cases) were collected via mail survey. The rest (27%, or 20 cases) were collected via direct structured interview. Given that data were not behavioral, instrumentation bias is presumed negligible. Our choice of such a multi-method approach allowed us to create a large sample set while, at the same time, gathering a large amount of rich, qualitative data. At each firm one person, usually a team leader, product development manager, or VP of Development, served as source of all data. Mail-based cases were addressed to one individual; roughly one quarter of the interviews included more than one interview source. Several firms described in the brief case descriptions received follow-up phone interviews from the authors. Confidentiality was promised in all interviews and surveys. Therefore all names and some dialogue have been disguised.

136

THE JOURNAL OF HIGH TECHNOLOGY MANAGEMENT RESEARCH VOL. 8/NO. 1/1997

Each respondent had to choose a particular product development team to discuss. The respondent was asked first to choose a product version/release 2 development cycle: one that he/she was intimately familiar with and that had recently shipped. Once the development effort was selected, the team became the product development team that developed that particular version/release. This approach has proven successful in both surveys and face-to-face interviews.

Sample Selection & Representativeness The sample packaged software companies were drawn from several sources: membership in the Software Publishing Association (one of the largest US-based software associations) and from a cross-section of trade directories and periodicals (such as Data Pro and Software Magazine). The firms were carefully selected to reflect breadth of firm types, sizes, and products. Several secondary criteria were made in sample selection: at least one product had to be shipping (to establish the firm's viability); packaged software revenue had to be a significant source of revenue (in order to eliminate consulting companies that developed packaged software as a minor side of their business); content software, such as educational software, which was judged to have a high ratio of content relative to software code, was omitted. The 54 mail-based cases were obtained from a survey sent to 275 packaged software firms. The 20 interview-based cases were conducted in the US and in three other advanced nations. Special efforts were made within the interview-based sample to seek breadth. For example, one of the firms ranked among the world's five largest packaged software firms, while another was a young firm of 18 employees. How close is this sample to its population? We answer this question using firm size (Table 1). First, we compare our sample to the large-scale Price Waterhouse survey of US software companies (1993) in which the (sample) median firm size is ten employees and 31% of the firms have five employees or less. Since our sample's median firm size is 35, it is likely that our sampling is biased to larger firms than are found in the total population. This would be expected from our selection methods and is deliberate since we have consistently sought firms to study that have already begun shipping their products. Second, by extrapolating from published lists of software vendors, we estimate that our sample represents roughly 13% of the global population in the largest category (packaged software firms of 100+ employees).

MEASURES Four predictors of team size appear in Figure 2. Each predictor, as well as team size, is operationalized by a measure, with some measures subdivided into categories. The categorized measures are for team size and firm size. Categorization within each measure is based on theoretical and empirical grounds, but boundaries must have an element of arbitrariness as does any such breakdown (e.g., membership in the "Fortune 500" is arbitrarily cut off at the 501st firm even though the revenue differences between it and its predecessor may be small). Team Size of less than ten members, as introduced with the "small is beautiful" rule, is referred to as a small team. Firm Size is the number of employees at the firm---customarily measured as Full-Time Equivalents (FTE). Firm employee size is the most common measure of a firm's size (along

Small is Beautiful

137

with annual sales) and is commonly used in trade rankings and the research literature. The three firm size categories are presented in Table 1 and labeled as Embryonic (1-19 employees); Small (20-100 employees); and Medium-to-Large (over 100 employees). The rationale for the three category boundaries of firm size follows. Firm size is commonly used in entrepreneurship literature to gauge the development of the firm (Churchill & Lewis, 1983; Kazanjian, 1988). Entrepreneurs themselves testify to discontinuities between stages of growth of the small venture. The founder of Horizon Air remarked: "the worst mistake an entrepreneur can make is to think that the abilities he had to run a company of 20 employees are good enough to run a company of 850 [... ]" (Rhodes, 1986). Thus, if one assumes a comfortable span of control of 20 direct reports, a founder will need to delegate supervision if he or she decides to grow the firm beyond that size. Once the founder has 5-10 directly-reporting supervisors, the firm size is 100-200 employees and it is ripe for another layer of managers. When an organizational layer is added an important "punctuation" occurs in the organization equilibrium (Tushman et al., 1986). The US Small Business Administration considers firms small when they are under 200 employees and Price Waterhouse' s survey of software companies (1993) sets the largest category at over 100 employees. Development Staff Size is the number of employees in the technical staff including all programmers, designers, technical managers, quality assurance specialists, etc. Age of Firm is the number of months since ship date of the first packaged software product. This measure is precise in that it is an easily measurable event. The other common birthdate measures, date of incorporation and first sale, are inaccurate for many software firms which begin as consulting firms and then drift, some years later, into development of specific products. Product Size is the lines of (program) code (LOC). LOC is the most common measure of product size because it is very easy to measure. LOC is a reasonable, though clearly imperfect, surrogate for measuring complexity (Schach, 1990). In spite of its appeal, LOC is programming a controversial measure because lines of code are different depending on the language used. RESULTS AND DISCUSSION

Are the Software Development Teams Really Small? The descriptive team statistics are presented in Table 1. It is immediately apparent that the product development teams are indeed small--with a median of five. This

TABLE 1 Descriptive Statistics of Team Size Team Statistics Firm Size Label

n o f cases

Median

Embryonic

Firm Size 1-9

22

3

Avr. 3.77

Min. 2

Max. 8

SD 1.47

Small

20-99

28

5

5.07

1

11

2.30

Medium +

100+

24

8

12.29

2

40

11.33

Total

......

74

5

7.03

1

40

7.66

138

THE JOURNAL OF HIGH TECHNOLOGY MANAGEMENT RESEARCH VOL. 8/NO. 1/1997

40

30

E 20

10

0 20

100

Firm size FIGURE 3 Line Graph of Team Size with Firm Size (in Full Time Equivalent Employees). The X Axis Represents Sorted Cases and it is Deliberately not to Scale.

confirms that most firms follow the "small is beautiful" rule stated earlier. Inspection of Figure 3 shows a slow increase in team size as the firm grows in size. In fact, there was only one development team larger than nine until the firm size is well into the hundreds. Of 74 cases only eleven diverge from the "small team" (1-9 employees) and only five diverge by more than 50% (larger than 15).

Team Size in Relation to Other Measures Before we answer the last two questions we posed in the Introduction, we examine several key measures that help inform those answers. In Figure 4 we present a descriptive model of team size and firm size, based on our sample data. This model was derived from the median team size for each firm size category. The model depicts the following: in "embryonic" firms, teams hover at three people; in "small" firms, teams are at five people, and when the firm exceeds one hundred, teams stand at roughly eight. Team size is compared to other descriptive measures in Table 2. The last column of Table 2 presents the correlation of team size with each measure, showing a positive correlation with each: firm size, development staff size, firm age, and product size. These correlations are expected. As the firm grows in total employees and in the total development staff, the product team size tends to increase. Similarly, the firm grows with time, and thus age is also positively correlated with team size (autocorrelated). There is also a significant positive relationship between team size and product size

Small is Beautiful

139

10 8 (1)

.--

o0

6

E (0

4 2 0 Firm size FIGURE 4 Descriptive Model of Team Size as Firm Size Grows

(measured in lines of code). Most, though not all, of the larger teams that we discuss in subsequent sections, dealt with larger software products. How Do the Teams Stay Small?

As the descriptive model in Figure 4 illustrates, it is not surprising that a firm of ten people has a small product development team. It becomes more unusual as the firm grows beyond 100 employees. We examined the fifteen cases in which firms succeeded keeping their teams small in spite of being in the medium-to-large category in firm size. Given

TABLE 2 Relationship Between Team Size and Other Measures n

Median

Avr.

Min.

Max.

Correlation with Team Size

Firm Size (employees)

74

35

183

3

1800

.39**

Staff Size (employees)

72

I1

47

l

600

.31 **

Firm A g e (in months)

73

84

83

l

303

.29**

71

100

377

1

5400

.33**

Measure

Product Size (in thousands of lines o f code)

Correlation is Pearson two-failed. xx = statistically significant at p < .01.

140

THE JOURNAL OF HIGH TECHNOLOGY MANAGEMENT RESEARCH VOL. 8/NO. 1/1997

large firm size (and usually increased age) how have these firms kept their teams small? We analyzed our sample data seeking patterns that help explain how these firms kept the teams small. The data suggest three factors: Factor 1: Proactive policy. In several cases the team size was small because of a deliberate, proactive policy. This point is of paramount interest to our question and therefore we present three of these cases further below. Factor 2: Minor release. In some cases, the team was small because the specific release (i.e., the specific product development effort) was a relatively minor one. A typical, paraphrased response in such a case was: Yes, the team was small in this example, but the major release that we are working on right now has double that number of people on its team. As preface to Factor 3, we present our definitions of two managerial approaches to product development that we have observed in our research3: •

•

P e r m a n e n t team. M e m b e r s of this t e a m are involved throughout the entire d e v e l o p m e n t cycle and m a y even see the product through several develo p m e n t cycles. T h e t e a m is e m p o w e r e d with decision making responsibilities ("ownership") o f the product. As a result of m e m b e r s ' long tenure and decision m a k i n g responsibility, such teams generally have a very high level of c o m m i t m e n t to the product. Ad hoc team. Within such a t e a m the project m a n a g e r m a y be one of the few people involved throughout the entire d e v e l o p m e n t cycle. Other t e a m m e m b e r s m a y be involved for short periods, or just briefly every day. This approach is conceptually close to a matrix organization. As a result o f the flexibility in this approach, m a n a g e r s can optimize personnel assignments and provide m o r e varied and stimulating w o r k to employees.

Factor 3: Permanent teams instead of ad hoc teams. We found that most of the small teams fell into the category of permanent team--with a stronger and more committed product focus. The three cases below are all illustrations of this focus. (In a later section we discuss the reverse of this factor--for cases in which teams grew too large). We present three brief case descriptions for three small teams within large firms: Small Team Case #1. The firm is an established developer of business software on multiple platforms, most of them being midrange and mainframe systems. Although the firm had 200 employees, the product development team had only four members. The Vice President of Product Development claimed that small product teams were a deliberate management policy, pointing to other teams within the firm that were also in the four-five person range. The two elements of this policy were specialization and tenure. The team members were more experienced in the application domain area than in the technical area, meaning that although they were highly qualified in computer areas, they had very narrow and deep knowledge of the esoteric application domain. The 4-person product team had "ownership" of the product, across all releases. There was no project structure that rotated team members to other products. Their product was all they did. Finally, all had stock options in their publicly traded stock. Small Team Case #2 is a large computer hardware vendor, that like other hardware vendors, has several software product divisions. The Silicon Valley-based team was part of one of these software divisions. The team in our sample was of size six, a deliberate and usual policy for this division. Product development teams were deliberately kept small 4

Small is Beautiful

141

to 6 members--and most interestingly were called "garages" to capture the mythic, entrepreneurial spirit of Silicon Valley. The physical "garage" itself was formed by facing cubicles into a small pen creating a common area. Several such garages were situated in the large office space. The garage name hung from the high ceiling above the pen. The team leader was called the "garage manager." Teams were formed to be independent and cross-functional: All team members participated in decision making as well as in marketing activities. In fact, the marketing engineer was one of the six full-fledged members of the garage for the entire development cycle. The respondent summarized their approach as follows: "We've tried to model ourselves on a small software company, as opposed to [our other software division] where we have a distinct R&D group and a distinct marketing group under different managers." Small Team Case #3: The firm is one of the world's largest independent packaged software companies developing desktop and client/server products. Although the firm was large (one thousand employees) and the technical staff was large as well (550), the product development team for this product--one of firm's main products--stood at only nine. The small team size was a deliberate policy of this division. The development manager was surprisingly apologetic about the size, pointing out that version 1.0 was developed by one person, so the team of nine was not to be commended because it represented growth of an order of magnitude in size. In 1995, two years after the data were first collected, the team for a subsequent release of that product also stood at nine and, according to the development manager, will grow by only a few people in the coming years, mostly because of cross-platform issues. This firm, like many of today's larger software firms, is composed of two major product groups resulting from a merger several years ago. The two product groups have cultural differences that include their respective philosophies regarding team size. While the group from which our case was drawn purposefully kept teams relatively small (4 and 11 for other major products), the other product group, with a different culture, used a development team of 45 members for its flagship product. In sum, the three brief cases demonstrate different organizations with different products and cultures that each have a proactive approach to the team size issue. The common denominator in these cases is that one or more managers had a vision about the team size. This is most likely the reason that these teams stayed small. As opposed to empire building, the "small is beautiful" view prevailed in team building. This vision may have emanated from the firm's president, the project leader, or as part of the firm's underlying culture.

Why Did Those Larger Teams Grow Beyond "Small"? Eleven of the teams (all in companies with at least 90 employees) had ten or more members in the team and were in violation of our "small is beautiful" rule. The eleven cases are presented in Table 3. We analyzed the eleven cases seeking patterns that help explain why these firms allowed their teams to grow. The data suggest four factors: Factor 1: Product is large, likely to be complex, and is in advanced release. In all but one case the product was well established and in advanced release (e.g., release 3.1). By this time, the software package has typically grown to be quite large. Of the eleven products in question, five were at or above one million lines of code. When the software product is small, a small number of people can hold most of its principal logic in their

142

THE JOURNAL OF HIGH TECHNOLOGYMANAGEMENTRESEARCH VOL. 8/NO. 1/1997

TABLE 3 Descriptive Statistics for the Eleven "Large" Teams in the Sample

Firm Num.

LOC (Lines of Code) in Release O00s Num.

Firm Age: Months Since 1st Ship

Platform Type D = Desktop L =Larger

Firm Size

Team Size

1

25000

35

officeautomation No Data

3.1

113

L

2

285

40

graphics

4.0

67

D

Application

1000

3

23

10

document management

300

1.0

4

170

10

developmenttool

500

3.0

32

D/L

5

90

1l

businessapp

175

3.0

46

D

1

D

6

1800

12

computer language

400

1.0

125

D

7

1000

12

businessapp

1500

1.0

303

L

8

2000

24

businessapp

4000

4.0

139

L

9

1800

25

developmenttool

1000

6.0

205

L

10

280

13

businessapp

500

4.0

134

L

11

200

40

officeautomation

1000

7.0 l

161

L

heads. However, when software surpasses a certain threshold, this is no longer possible. Thus, if there is one factor that stands out as an explanatory factor for the larger teams, it is the size of the product. Additionally, many larger teams included significant numbers of personnel needed in porting/cross-platform development and localization (translating the software from one spoken language to another). These are two tasks that are more mundane, requiring more perspiration than inspiration. Factor 2: Firm age and ossification. Most of the eleven firms were older, well-established firms. In fact, a tendency toward bureaucratization was detected in a few cases. For example, at Large Team case #11 (see Table 3) the respondent, VP of Development, made frequent references to "chains" of decision making and proper"channels" of communication between employees and between customers. Factor 3: Non-desktop roots. Of the eleven firms, most are designated as "L" in platform type in Table 3 indicating that the company' s core products were, or still are, for mainframe or midrange platforms (and not desktops or client/server).4 Software development for large platforms is not necessarily more complex, rather, we speculate that the larger team sizes are a managerial/cultural legacy of the mainframe days of large information systems projects. Factor 4: Ad hoc team instead of permanent team. We defined these two terms earlier and then stated the converse, explaining, in part, why some teams stayed small. Of the eleven large teams in this study, some used traditional project management approaches in which many team members were not fully assigned to the development effort. Therefore, there tends to be less continuity and, hence, less commitment. In addition, Ad hoc teams tended to have less overall product responsibility; team members did not make key decisions about the product. For example, at Large Team #10, the principle design decisions were made entirely outside of the product development team, by a design steering committee made up of senior management.

Small is Beautiful

143

We present two brief case descriptions from among the largest teams in our sample: Large team case #1 is a large computer hardware vendor, that like other hardware vendors, has several software product divisions. The European-based team was part of one of these software divisions. The team worked on, what was acknowledged to be a "minor" release, but nevertheless required a team of 35 members filled from elaborately detailed organizational charts. Roughly half of them were not assigned full time for the entire development cycle. The particular division composing the team in question was assimilated into the corporation as a result of acquisition. The 35-person team was made up of two major groups that were separated by a two hour train ride. These two groups resulted from a still earlier merger that had taken place some years prior. Although communications between the two groups was frequent, making heavy use of e-mail, rivalries existed between the groups. Furthermore, customer requirements were largely defined outside the team and without team members' participation. Of the factors we stated for team size growth, this team exhibited all four factors. First, although the specific product size figure was not available, this was clearly a substantial product in advanced release. Second, the large firm legacy and the impact of numerous mergers forced together various products and layers of management. Third, the firm's legacy is that of large platform products. Fourth, the development effort can be characterized as an ad hoc team using traditional matrix management approaches. Large team case #2. The firm is a large desktop packaged software developer with a well-known mass-market product. This forty-person team developed the firm's flagship product. The forty team members were divided into five subgroups including one for Quality Assurance. Although the team significantly violated the "small is beautiful" rule, the company has been doing extremely well as measured by total revenues per employee. Sales have grown very rapidly as a result of the lucrative niche that the firm has come to dominate. In a 1995 follow-up interview, the Chief Technology Officer, who supervised the project, did not feel that 40 was too large because "it was a creative process." The subsequent release had a team of 150 people. In conclusion, based on somewhat limited data, we could not detect what "had gone wrong" resulting in the team size growth--or if, indeed, anything did "go wrong." One interpretation is that this may be a case in which the windfall revenues of a successful product cause management to be unconcerned with implications of bloat. In sum, we identified four factors that contribute to large teams. Large team case #1 paints a picture of an organization gone awry in some respects, contributing to excessive team growth. Large team #2 is a more difficult case to analyze because of the product's enormous financial success.

SUMMARY AND FURTHER QUESTIONS We began by establishing the rule--a team of ten or above is a violation of "small is beautiful." We then examined data from 74 product development teams in a cross section of packaged software companies. First, using the rule, we found that most teams in these firms were indeed small with a median of five members and were well within the "small is beautiful" threshold. Only 15% of the firms violated the "small is beautiful" rule, and only when the number of employees in the firm neared or exceeded 100. Three factors were found that help explain why the teams remained small in larger firms: there was a proactive policy regarding small teams, teams were permanent rather than ad hoc, and the release was relatively minor.

144

THE JOURNAL OF HIGH TECHNOLOGY MANAGEMENT RESEARCH VOL, 8/NO. 1/1997

Four factors were identified that explain why those teams that violated the "small is beautiful" rule grew beyond small: product size and complexity, firm age and ossification, non-desktop roots of the software products, and teams were ad hoc rather than permanent. This study's most profound managerial finding is that in some large firms the teams were able to remain small. The data revealed several instances in which specific cultural norms and/or managerial policies included the small size of the team as a significant attribute. As part of this proactive policy the team management approach may be important. Permanent teams tended to be smaller than ad hoc teams in which individuals joined the effort on temporary assignments. Permanent teams benefit from the experience resulting from members' immersion in the process, in the product, and in learning to work with one another. While we are comfortable that the sample of 74 teams is representative and generalizable, once we break down the cases into smaller categories, the cells become too small to draw strong conclusions. As mentioned previously, we purposely biased our interview data away from the "embryonic" firms (smaller than twenty) in which teams are very likely to be very small. Our findings answer some questions, but raise others. These questions are organized in the remainder of this section into four topics. The first topic is devoted to the team structure once the team is no longer one small, cohesive unit. In the second topic we examine the boundaries of the product development team. In the third topic we introduce national culture differences in team size. Lastly, the fourth topic has to do with the size implications of differences in organic and mechanistic teams. From Size to Structure One of the problems of correct management is the correct level of separation between the teams. It would be wonderful to all get together and have everyone work with everyone. But when you pass 30 employees, it doesn't work. Director of Development, 345-person packaged software firm. Our analysis to this point has been largely agnostic of issues of intra-team structure. But structure has a direct bearing on our understanding of team size issues. For example, Large Team case #1, with 35 members, was made up of two major subgroups and several additional subunits within those major groups. These subgroups and subsubgroups may themselves be referred to as "teams." Clearly, at some size n, varying for every product team, it becomes more effective to split the team into several subunits. Some reasons for this include: need for specialization, increased span of control, reducing communication link permutation, as well as organizational realties such as a merger of two groups, which may even be geographically dispersed. Our data for these subteam structures are sparse given that this was not part of our intended data collection. However, two very brief descriptions from the sample cases give a flavor for large team practices regarding subteams. Large Team case #10, of size thirteen, was split into three functional teams of three programmers each, one Quality Assurance team of three members, plus the project manager as the 13th member. At a 450-employee firm the Vice President of Development' s rule of thumb for his product teams was to have about 15 members, split up into subteams of five plus/minus two. Given that some teams grow beyond small, a topic that needs further research is: what subteam structure is best? Although team structure has been researched in other technol-

Small is Beautiful

145

ogy-oriented organizations (focusing on the role of liaison or linking pin; Likert, 1967; Lawrence & Lorsch, 1969), in software development there is little in the literature with the exception of Zahniser (1990). Zahniser prescribes a normative organizational systems development structure in which the "atomic" teams communicate through a metaphorical hub. The communication permutation problem is reduced through several devices. The hub materializes into an executive committee that includes the project manager and all the "atomic" team leaders. All the superteam members are convened only for unusual events. At all other times groupware (e.g., Lotus Notes) should be used to keep all members informed. Zahniser also encourages "information hiding" in which some design logic is shielded from the programmers. Fried (1991) points to some of the fallacies in this and other team structure proposals that attempt to create order in larger teams. The assumption, he argues, is that those structures reduce the possible interaction permutations between members because most communication take place between the "atomic" team leaders. However, this assumption may be misleading: with larger superteams, more information must now flow between all its members, more managers are now needed to run the various teams, and larger structures lead to formality and the requirement to document everything. Microsoft may have found a successful solution to this problem. Cusumano & Selby (1995) describe Microsoft's approach to intra-team structure. Large teams are broken down into subunits, each of which proceeds in parallel, synchronizing continuously. The key to the "synch-and-stabilize" process that was observed at Microsoft was the daily "build" in which programmers check in their code by the end of the day. The individual components are then tested daily and problems are resolved (immediately) as a result. Such a process forces a non-verbal form of communication between the various members and subunits: if something doesn't work it must be resolved. Cusumano & Selby consider this approach one of Microsoft's key success factors. F r o m Size to C o m p o s i t i o n - W h o is I n c l u d e d and W h o is E x c l u d e d F r o m the T e a m ?

Interview data revealed that the boundaries of the product development team varied, there was no one all-encompassing definition, nor could an arbitrary definition be imposed on the norms of the organization. While at some firms the team was highly inclusive to include any number of "peripheral" personnel, at other firms the developers did not consider any such peripheral personnel as part of the team. These peripheral personnel may be the testers, the chief technical officer, who may have been heavily involved in design, or a programmer who is seen as too highly specialized. Often the product development team partially overlapped with the company's core team which encompassed the technical gurus, architects, and visionaries of the product (Anthony & McKay, 1992; Carmel, 1995a) who were still involved in high-level design. In general, team boundaries were usually quite clear for the smaller teams, but tended to become more ambiguous with larger teams. Team boundaries were a function of the style and culture of the firm, the personal proclivities of the team members and of its management. In sum, an important question requiring further research is--what is the "right" composition of the product development team?

146

T H E J O U R N A L O F H I G H T E C H N O L O G Y M A N A G E M E N T R E S E A R C H V O L . 8 / N O . 1/1997

From Size to National Culture While organizational, occupational, and entrepreneurial cultures have permeated many of our discussions to this point (e.g., the cultural differences between IBM and Microsoft), national cultural differences may also have implications for team size. For example, Carmel (1995b) argues that US software developers, with their greater needs for individualism, have a greater tendency to form very small, entrepreneurial teams. Our sample data for non-US firms are too small to draw any inferences. The relationship of national differences and team size is an important area for further research as software teams increasingly collaborate across national frontiers.

From Size to Task Type Literature in organizational behavior suggests that routine tasks can be organized and structured differently than creative tasks (March & Simon, 1958). As some tasks of software development become routine, the need for creative solutions may decrease and with it the need for dense communication among team members. In such a situation the task of development may be organized in a more mechanistic rather than organic fashion (Burns & Stalker, 1961). Mechanistic organizations tend to be formalized, non-specialized, undifferentiated horizontally with more hierarchy than organically structured organizations which are more informal, highly specialized, decentralized, and flatter. Use of subteams and information hiding reflect a more mechanistic organization structure. Where the task is largely non-routine, where novelty and innovation demands are high due to competitive pressure and market changes, a flexible, highly interactive, learning team is called for. Such a team is necessarily small. Thus, a practical research question is at what point does a software product development task become routine, allowing the organization to relax the small team dictum? Furthermore, organizational theorists have come to believe that the mechanistic structure is more adaptive to environments that are stable while organic ones adapt to changing environments. While the software industry is changing rapidly, there are niches where a firm's product dominance gives it a relatively more stable environment. In such environments--where competition is limited or at least well known, where innovations are versions of products rather than completely new products--a structured, mechanistic approach to software development may indeed be appropriate and may account for violations of the "small is beautiful" rule. Finally, when a software product is complex, even in a downstream version, and the need for innovation and creativity is high due to competitive and market pressures, a tension will exist between the structural demands for a large team and the process demands for a small team. In these cases, managers of the product development process become managers of paradox: they must find ways to think big and act small. ACKNOWLEDGMENTS We thank Steve Sawyer and Roger Volkema for helpful comments, Katherina Zettl-Schaffer for data entry, our reviewers, and the dozens of software developers who shared from their experience and time. This research was partially supported by research grants from American University.

Small is Beautiful

147

NOTES 1. The software industry can be divided into two sectors: a sector that produces customized business, military, and science applications; and a sector that produces packaged software which is produced for multiple customers. Packaged software is also referred to as commercial software and COTS (Commercial Off-The-Shelf Software). 2. This requirement stems from the unique characteristics of a software product. But the difference between a new product and a new version is arbitrary and subject primarily to marketing considerations. 3. Team management structures have been shown to have an impact on outcomes as shown by Larson and Gobeli (1989). 4. "Large platform" was designated when the finns' packages were primarily a legacy of nondesktop platforms even as some products were, at the time, being migrated to client/server.

REFERENCES Allen, T.J., Lee, D.M.S., & Tushman, M.L. (1980). R&D performance as a function of internal communication, project management, and the nature of work. IEEE Transactions on Engineering Management 27, 2-12. Anthony, M.T., & McKay, J. (1992). Balancing the product development process: Achieving product and cycle-time excellence in high technology industries. Journal of Product Innovation Management, 9(2), 140-147. Brooks, F. (1975). The mythical man month. Reading, Mass: Addison-Wesley. Brown, S.L., & Eisenhardt, K.M. (1995). Product development: past research, present findings, and future directions. Academy of Management Review, 20(2), 343-378. Burns, T. & Stalker, G. M. (1961). The management of innovation. London: Tavistock Publications. Carmel, E. (1995a). Cycle-time in packaged software firms. Journal of Product Innovation Management, 12(2), 110-123. Carmel, E. (1995b, Nov/Dec). Entrepreneurial technologists may have the upper hand in global software competition. Research Technology Management, 38(6), 10-11. Carroll, P.B. (1991, Dec 2). How an IBM attempt to regain PC lead has slid into trouble. Wall Street Journal, 1. Churchill, N. C., & Lewis, V. L. (1983, May/June). The five stages of small business growth. Harvard Business Review, 30-50. Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems. Communications of the ACM, 31(11), 1268-1287. Cusumano, M.A, & Selby, R.W. (1995). Microsoft secrets. New York: Free Press. Flamholtz, E. (1990). Growing pains: How to make the transition from and entrepreneurship to a professionally managed firm. San Francisco: Jossey-Bass. Filley, A. C., House, R. J., & Kerr, S. (1976). Managerialprocess and organizational behavior (2nd edition). Glenview, IL: Fried, L. (1991). Team size and prodiuctivity in systems development. Journal of Information Systems Management, 8(3), 27-35. Greiner, L.E. (1972). Evolution and revolution as organizations grow. Harvard Business Review, 50, 37-46. Guzzo, R.A., & Shea, G. P. (1992). Group performance and intergroup relations in organizations. In D. Dunnette & L. M. Hough (Eds.), Handbook of industrial and organizational psychology (2nd ed.): pp. 269-314. Palo Alto, CA: Consulting Psychologists Press. Hackman, J.R. (1990). Groups that work (and those that don't). San Francisco, CA: Jossey-Bass. Higgens, S. (1996, Jan. 17). Leaders and success. Investor's Business Daily, p. A1.

148

THE JOURNALOF HIGH TECHNOLOGYMANAGEMENTRESEARCH VOL. 8/NO. 1/1997

Katzenbach J.R., & Smith, D.K. (1993). The wisdom of teams: Creating the high performance organization. Boston, MA: Harvard Business School Press. Kazanjian, R. K. (1988). Relation of dominant problems to stages of growth in technology-based new ventures. Academy of Management Journal, 3•(2), 257-279. Lammers, S. (1986). Programmers at work. Redmond, WA: Microsoft Press. Lawrence, P. H., & Lorsch, J. W. (1969). Organization and environment: Managing differentiation and integration. Homewood, IL: Irwin. Levering, R., Katz, M., & Moskowitz, M. (1984). The computer entrepreneurs. New York: New American Library. Likert, R. (1967). The human organization. New York: McGraw Hill Littlepage, G.E. (1991). Effects of group size and task characteristics on group performance: A test of Steiner's model. Personality and socialpsychology bulletin, 17(4), 449-456. March, J., & Simon, H. A. (1958). Organizations. New York: Wiley. Martin, J. (1991). Rapid application development. New York: MacMillan Parnas D.L. (1972). On the criteria to be used in decomposing systems in modules. Communications ofthe ACM, 15, 330-336. Price Waterhouse (1993). Software industry business practices survey, 1993. Boston, MA.: Price Waterhouse. Putnam, L.H., & Meyers, W. (1992). Measures for excellence: Reliable software on time, within budget. Englewood Cliffs, NJ: Yourdon Press. Quinn, J.B. (1985, May/June). Managing innovation: Controlled chaos. Harvard Business Review, 63(3), 73-84. Rhodes, L. (1986, April). Kuolt's complex. Inc., pp. 72-75, 78-84. Rubinstein, A., Chakrabarti, A. O'Keefe, R., Souder, W., & Young, P. (1976, May). Factors influencing innovation success at the project level. Research management, pp. 15-20. Schach, S.R. (1990). Software engineering. Homewood, IL: Irwin. Schumacher, E.F. (1973). Small is beautiful: Economics as if people mattered. New York: Harper and Row. Steiner, I.D. (1972). Group process and productivity. New York: Academic Press. Tushman, M.L., Newman, W. H., & Romanelli, E. (1986). Convergence and upheaval: Managing the unsteady pace of organizational evolution. California Management Review, 29(1), 29-44. Wicker, A., Kirmeyer, S.L. Hanson, L., & Alexander, D. (1976). Effects of manning levels on the subjective experiences, performance, and verbal interaction in groups. Organizational Behavior and Human Performance 17, 251-274. Zachary, P. (1994). Showstopper: The breakneck race to create Windows-NT and the next generation at Microsoft. New York: The Free Press. Zahniser, R.A. (1990, July/Aug). Building software in groups. American Programmer, 51-56.