To address the questions of whether larger or smaller teams are better and how happiness impacts employee productivity, a review of extant research was conducted and then analyzed. The research and paper begin with the recognition that there is disparity in the conclusions that have been reached over time, but final analysis found that smaller teams tend to be more productive; larger teams can overcome the lack of individual productivity through sheer size; and while happier employees are generally more productive, employers cannot necessarily make employees happy. Therefore, emphasis should be placed on organizing work into units that can be assigned to smaller teams, barriers to communication should be eliminated, and employers should try to minimize or eliminate unhappiness caused by the workplace.
Team Size, Happiness, and their Relationship to Productivity
There are many influences on team size as work groups are forming. The requisite skills for the work at hand need to be represented, but competition over valued employees may be a limiting factor on team composition. Certain people may need to be added to the team for political or oversight reasons, or the team might be limited for budgetary reasons. And over time, a team’s size is likely to fluctuate as members move on to other projects, other places of employment, or leave employment altogether due to health or other reasons. A team is a dynamic entity, but general principles regarding team size and efficiency have been established. This paper will examine literature regarding two factors and where they converge: team size, team member happiness, and productivity. Emphasis will be placed on the Information Services sector where teams are dealing with information, ideas, and technology, rather than construction or manufacturing.
While team size is dictated by a variety of influences, it is generally accepted that smaller teams ranging from 2-8 people are best (Wheelan, 2009). The minimum size of the team will be dictated by the skills necessary to accomplish the task for which the team is responsible, and the more complex the skillset needed, the larger the team. Projects can be broken down into discrete tasks allowing for smaller teams, but individuals are limited in the areas in which they can specialize due simply to lack of time, and this will impose a minimum band on team size. If the team is too large, then the factors that drive individual productivity such as receiving regular feedback, recognition, or direction will decline and impact productivity. More managers can be hired to address this, but that adds more overhead and potentially gateways on communication, which can impact quality of delivery as well. And if the team is too small, employees may be overloaded, or team members may be required to work outside their expertise (Parrish, Smith, Hale, & Hale, 2004). These tensions will undermine productivity and can contribute to higher turnover.
This paper will examine recent studies and considerations of team member happiness and how an employee’s happiness influences both individual and team productivity. Extrinsic motivators like financial compensation only contribute to happiness until one reaches a sufficient level of financial security, at which time incentives such as pay rises have limited effectiveness in regards to staff happiness. Other factors that contribute to happiness are praise, autonomy, and the ability to pursue one’s personal interests and goals (Edwards, 2009). It should be noted that many of the factors that contribute to an employee’s happiness in regards to work culture and activities are similar to factors provided by having a smaller team. Subsequently, the study of how team size impacts happiness is an important facet of understanding employee productivity.
If we can identify a generally ideal team size at the juncture of coverage and happiness to maximize productivity, it will be helpful when forming teams for different endeavors. Alternatively, it may be that team member happiness is largely independent of team size in and of itself, and the factors of autonomy, feedback, and praise are the significant contributors, such that work culture and style of management are of greater importance than team size.
This paper posits that, although smaller groups may lack the requisite range of skills to complete a project efficiently or effectively, smaller group size contributes to employees experiencing autonomy, accountability, and recognition, and this leads to increased happiness and productivity. Happier employees contribute to a positive work culture and will prompt each other to work harder, thereby leading to overall higher output when compared with larger teams. If instead we find that group size is irrelevant provided the other positive factors are present, it will be a significant contribution to the determination of team size because it will remove the limiting factor of number of people in and of itself in regards to team productivity assumptions.
Wheelan (2009) highlights the disparity in the literature regarding team size. “Gibb (1951) found that as size increased members reported more feelings of threat and inhibition. More disagreements and dissatisfaction with the group were found in larger versus smaller groups as well (Berkowitz, 1958; Slater, 1958). … Some studies concluded that small groups are more efficient and productive than large groups (Gibb, 1951; Gist, Locke, & Taylor, 1987; Laughlin, Hatch, Silver, & Boh, 2006; Orpen, 1986; Wheelan & McKeage, 1993). Other studies found that as size increased, productivity and performance increased as well (Fink & Thomas, 1963; Fox, Herrold, Lorge, & Weltz, 1953). Wanous and Youtz (1986) concluded that increased size broadened solution diversity, which in turn led to better decisions and enhanced productivity. Finally, a number of studies reported no differences in the quality of solutions or productivity in small groups versus large groups (Cummins & King, 1973; Dickinson & Stoneman, 1989; Kidd, 1958; Lorge & Solomon, 1959, 1960) (Wheelan, 2009).”
Fred Brooks addressed one of the temptations to growing team size in The Mythical Man-Month in 1975. When creating a project estimate and schedule, the estimation is done in time, such as man-hours, days, or months. This estimate is how much time one might expect a project needs to be completed, and the logic follows that one could then divide that time between people to decrease the amount of actual time needed to deliver the project. By way of example, the logic goes that if a project is to take two months of effort, then two people should be able to complete the project in one month.
While cost varies as number of staff and/or time goes up, that does not necessarily correlate to progress. People and months “are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming (Brooks, 1995).”
Brooks goes on to write that, “The added burden of communication is made up of two parts, training and communication. Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work. This training cannot be partitioned, so this part of the added effort varies linearly with the number of workers. Intercommunication is worse. If each part of the task must be separately coordinated with each other part, the effort increases as n(n-1)/2. Three workers require three times as much pairwise intercommunication as two; four require six times as much as two (Brooks, 1995).”
Subsequently, adding people to a project in-flight tends to be disastrous. To oversimplify outrageously, as Brooks puts it, “Adding manpower to a late software project makes it later (Brooks, 1995).”
To provide the appropriate team size and leadership, Brooks (1995) offers a proposal by Harlan Mills in which one person leads a team. Mills appeals to the metaphor of the surgical team which has one surgeon and a number of support staff. In this case, we would have a chief programmer as our surgeon, and he or she would be supported by a junior programmer, an administrator, an editor for documentation, secretaries to handle the project correspondence, a program clerk to maintain the technical records of the team, a toolsmith to handle and provide the various tools used by the chief programmer, the tester, and the language lawyer who focuses on making difficult tasks simple and efficient, as opposed to the chief programmer’s goal of overall design and implementation (Brooks, 1995). This team makeup, first proposed in 1971, is rather dated, and several of these roles are no longer needed and have been supplanted by computer-based tools. But note that this team has 10 members, and the reduction of the need for both secretaries and a toolsmith puts this team at 7 members, which is within the bounds of Scrum’s agile team size recommendation of 7 +/- 2 (Schwaber & Sutherland, 2013), and within the bounds of Wheelan’s optimal group development speed for high productivity (Wheelan, 2016). This model of having one person handling most of the work while supported by others is similar to the developer pair concept (Parrish, Smith, Hale, & Hale, 2004).
Brooks addresses the need to scale up, because while this team may work well, it cannot tackle a 5000 person-month project. But with the sole leadership for the team defined, it means that 20 teams requires the coordination of only 20 people, not 200. And in this instance, Brooks observes that there must be a single system architect, or a small group that is responsible for comprehensive understanding of the system architecture, design, and communication (Brooks, 1995). Again, there is an emphasis that tasks need to be handled by smaller teams to ensure productivity and progress.
Steve McConnell argues that Brooks’ Law needs to be understood in the context of poor accuracy and project estimation and tracking, and that it is not applicable to all projects or all project phases (Chernogus, 2011). Rather, it is only applicable in the final stages of a project, and there is a point up to which it makes sense to add staff. The impact of training, as well as the impact to morale, can be compensated for up to that point. And that point is often much later than people think or Brooks’ Law implies (Chernoguz, 2011).
Whether Brooks or McConnell is right, there is clearly a point where adding more people causes problems. Eric Raymond clarifies Brooks’ Law further by stating that, “Brooks’ Law is founded on experience that software bugs tend to strongly cluster at the interfaces between code written by different people, and that communications/coordination overhead on a project tends to rise with the number of interfaces between human beings. Thus, problems scale with the number of communication paths between developers (Chernoguz, 2011).” Free and Open Source Software (FOSS) falsifies the assumptions behind Brooks’ law, according to Raymond, because it provides a larger developer population and cheap communication (Chernoguz, 2011).
Schweik et. al. point out that, in most FOSS projects, only a few dedicated programmers actually do most of the code writing (which is reminiscent of Brooks’ surgical team concept). But as they examined the broad range of FOSS projects, they were unable to determine whether adding more developers increased the likelihood of success of the project or whether successful projects drew more developers (Chernoguz, 2011).
Another interesting observation of Chernoguz’s is that, despite Brooks’ law, adding veterans (programmers with 10 or more years of experience) to an established team resulted in an overall gain in productivity. And while adding rookies can have a negative impact on team productivity, it can be compensated by sufficient veterans if the team is of sufficient size. Generally, veterans were 40% more productive than rookies (Chernoguz, 2011).
All that said, the evaluation of project risks, cost, and schedule remains more an art than science. “It is still mainly dependent on a manager’s experience, ‘hunches,’ ‘gut feelings,’ and application of informal industry rules of thumb (Chernoguz, 2011).” The reason for this is that a programmer’s productivity cannot be objectively determined or compared across projects, and the human element involved in a project makes things nearly unpredictable. Models like COCOMO II incorporate environmental factors to assist in this effort, but this requires many more inputs, and it still cannot account for the dynamic nature of the development process or predict emergent effects. As complexity of calculation grows, a single error can cause disproportionate impacts in the results, and the likelihood of error grows as complexity increases.
Regardless of size, Wheelan writes that groups become more productive as they mature. According to Wheelan (2016), there are four stages of team development. The first stage is characterized by dependence and inclusion. During this stage, team members are concerned about being judged, and they want to feel secure and included in the group. They will defer to the group leader, and will rarely express disagreement with the group’s initial goals. The second stage emphasizes conflict as the team begins to negotiate its values, goals, and tasks. Role and goal clarification will begin during this stage as members challenge the leader and each other. While conformity decreases, member participation increases, and groups that can pass through stage 2 will reach stage 3. In stage 3, trust is established and a structure is formed. Consensus increases and roles and goals are adjusted to increase the likelihood of success. The leader’s role becomes less directive and more consultative as cooperation increases. The final stage, stage 4, is the most productive stage in terms of work. Members are clear about the team’s goals and their individual roles, and voluntary conformity is high. Subgroups are integrated with the team as a whole, interpersonal attraction between members is high, delegation is the prevailing leadership style, and effective conflict management strategies have been implemented (Wheelan, 2016).
Wheelan writes that it typically takes 7-9 months for a team to reach stage 4, and only 25% of teams ever reach stage 4. Many workers have never been part of a stage 4 team. What’s more, group development will be hampered by instability in team membership or inability to meet, both of which are generally impacted by the team being larger sized. If a team is not able to advance to at least stage 3, it will remain less productive (Wheelan, 2016).
The concept of group development and its impact on productivity has been well studied and documented, and in 2009 Wheelan began to focus on the effect of size on work-group development and its impact on productivity.
The results of Wheelan’s study “suggest that work group size is linked with group development and group productivity (Wheelan, 2009).” Notably, groups with 3-8 members were significantly different from groups with 9 or more members, and a majority of the smaller work groups were functioning in the higher stages of group development. Further, teams with 3-6 members were significantly different from groups numbering 7-10 members “on all measures of group development and productivity (Wheelan, 2009).” “Based on these results, it seems logical to conclude that work-group size is an important factor in both group development and group productivity (Wheelan, 2009).”
In addition, this study sought to link group size, group development, and group productivity. The findings suggest that small work groups of 3 to 6 members have a much better chance of reaching the higher stages of group development than larger groups. Group productivity has been linked with the higher stages of group development in previous studies (e.g.,Wheelan, Burchill, et al., 2003; Wheelan & Kesselring, 2005; Wheelan & Lisk, 2000; Wheelan et al., 1998; Wheelan & Tilin, 1999). The results of this study support the conclusion that group size increases or decreases the likelihood that work groups will reach the third or fourth stage of group development and, as a result, positively or negatively affects group productivity. “Group size is determined at the very beginning of the life of a group. Determining group size, then, is a crucial decision (Wheelan, 2009).”
This is counter to the traditional assumption that output increases linearly with team size. Rather, “The need for interpersonal communication, coordination activities, and interfacing between components and technologies are all thought to contribute to diseconomies (Comstock, Jiang, & Davies, 2011).” Team size can contribute to output through either an economy or diseconomy of scale.
Comstock, Jiang, and Davies used detailed information from over 4000 software development projects to perform statistical analysis under both the Boehm’s COnstructive COst MOdel (COCOMO) and the Putnam model aimed at providing guidance on increasing the profitability of software development activities through project scheduling activities and resource allocation with an emphasis on the determination of team size (Comstock, et. al., 2011). The key values that Comstock, Jiang, and Davies used to represent Normalized Work Effort were: Adjusted Function Points, Average Team Size, Language Type, Development Platform, and Development Type (Comstock, et. al., 2011). Notably, happiness was not one of their variables. The emphasis is a purely objective view of profit vs. loss while attempting to take into account complexity and requisite skills by attributing values to the maturity of the development language and environment. They found that if the potential value of the software greatly exceeded its development cost, then having a larger team to develop the software faster resulted in more profit despite lower per-person productivity and higher development costs (Comstock, et. al., 2011).
That said, there may be a way to achieve higher profitability while improving development speed. Due to the diseconomy of scale in team size in regards to per-person productivity, it might be helpful to emphasize an optimal release size that can be provided by the optimal team; in this manner, instead of scaling up the team to meet more complex projects, you reduce complexity by releasing incrementally or in pieces (Comstock, et. al., 2011). The large and complex software could be broken into smaller pieces so they can be tackled by smaller teams.
To better examine very large software development teams, Sornette, Maillart, & Ghezzi (2014) studied groups interacting with open source software (OSS) projects. The groups contributing to OSS can be quite large, and in this study they ranged from 5 to 1678 contributors (Sornette, Maillart, & Ghezzi, 2014). A key concept within these products is that each code commit can be reviewed and commented upon, and the amount of comments increases with the size of the contributing team. Subsequently, larger teams lead to more dialogue, and subsequently more opportunities for community building and individual skill development. Code commits and reviews are triggering activities that result in a burst of productivity, and since larger teams have more of these triggering events, they have more bursts as well. However, “while a minimum critical mass of contributors is needed to foster productive bursts, large projects suffer from coordination costs, which may offset the increasing return of productivity (Sornette et. al., 2014).”
“For the OSS projects, many other factors come into play, such as the role of diversity and complementarity, which describes the fact that doing more of one thing increases the return to doing more of another. Other possible mechanisms include synergies, economies of scale, coordination and leadership, role model and entrainment effect, motivations, friendship and other psychological factors. … These mechanisms dampen out as the project size becomes very large (Sornette, et. al., 2014).”
Parrish, Smith, Hale, and Hale (2004) narrowed down to the minimum team size and examined developer pairs. In pair programming, two programmers work together to handle all development tasks and they share a single computer, keyboard, and mouse. Interestingly, research cited by Parrish et. al. (2004) indicated that not only do the pair programmers produce higher-quality code than developers working alone, they turn out better designs with little or no significant loss in productivity. This quality and productivity appears to be due to role-based protocol, whereby one member of the pair is controlling the equipment and writing the code while the other serves as consultant and peer reviewer (Parrish, Smith, Hale, & Hale, 2004). Pairs that were highly collaborative and synchronous were less productive without generating demonstratively superior code when compared with pairs that were fulfilling the same role distribution but asynchronously (Parrish et. al., 2004). Whether synchronous or asynchronous, having the pair work together generated significantly better results than having two developers work on the same piece of work without synchronizing at all; it was better to focus both people on one section, rather than having both work independently on the section of code. This improvement is attributed to high concurrency. Team members generally working on the same project but not dedicated to working as a pair together, even asynchronously, are in a potentially concurrent setting but may not work concurrently, while pair programmers are by necessity in a high concurrency setting (Parrish, et. al., 2004).
That said, Parrish, et. al. (2004) found that pair programmers in a high concurrency setting were almost 4 times less productive than pair programmers in a low concurrency setting. They derive two conclusions from this finding. First, that just working together doesn’t provide higher productivity, and likely decreases productivity by having two people simultaneously work on the same problem. And second, that the key to successful pair programming is in the role-based approach rather than in high concurrency. This supports the findings from Sornette, et. al. (2014) that triggering events, such as a code review or consultation, lead to a burst in productivity. In the pair programming scenario, the person who will be performing that consultation or review need not sit idle while waiting for the person writing the code to reach a point of reflection. Instead, they can be productive, and then provide the feedback when needed.
This hints at one of the challenges of team efforts, which is that some members of the team will not work as hard as others. In fact, all members of a team generally work less than if they worked alone. Social loafing is a term coined by Ringelmann who found that “individuals assigned to a team contributed significantly less than when working alone (Suleiman & Watson, 2008). As cited in Social Loafing in Technology-Supported Teams, Karau and Williams (1993) found group size to present a curvilinear decrease in performance; large groups loaf more than smaller groups.
Suleiman and Watson (2008) studied the impact of feedback on social loafing in technology-supported teams with the hypothesis that both individuals working alone and those working within a team would loaf less when provided with feedback. They also examined and compared self-feedback with no feedback and feedback from the entire group. The results were surprising in that feedback did not decrease social loafing markedly. What’s more, a great deal of loafing occurred during the feedback phase. The result of this was that an individual working alone with no feedback was most productive, while a group working together that all provided feedback to one another was the least productive (Suleiman & Watson, 2008).
According to Hosie, Willemyns, and Sevastos (2012), the first researcher to demonstrate a relationship between emotional state and productivity in the workplace was Hersey in 1932. At the same time, the Hawthorne studies, conducted by Roethlisberger and Dickison in 1939, focused on job satisfaction. It is from the Hawthorne studies we receive the “happy-productive worker thesis,” in which better performance is attributed to happy workers when compared with unhappy workers (Hosie, Willemyns, & Sevastos, 2012).
The conclusion was that improving employee morale should result in higher productivity, but studies from the 1930s onwards have only found modest support for the link between happiness and better work output. Improving employee morale should result in improved performance, but in the 1970s the perceived direction of the relationship was reversed, and studies began to emphasize that employees who performed better were rewarded more, and this contributed to greater happiness (Hosie, et. al., 2012).
As cited by Hosie, et. al. (2012), it wasn’t until Judge et. al. found in 2001 that there was a distinction in the happiness-productivity model between extrinsic motivations such as pay rises and intrinsic motivations such as wanting to support one’s company or co-workers. Other studies by Cropanzano and Wright in 1999 and 2001, Wright and Staw in 1999, and Wright, Cropanzano, and Bonnett in 2007 found that both managers and employees with overall positive dispositions, that is to say better attitudes, tended to have both higher job satisfaction and performance (Hosie, et. al., 2012).
There are two salient conclusions to be drawn from the work of Hosie, Willemyns, and Sevastos. First, when targeting intrinsic motivators to help managers and employees be more productive by way of being happier, we must recognize that different people have different intrinsic motivations; one general intervention is unlikely to work for all people. Second, uncoordinated attempts to improve intrinsic well-being may be ineffectual and therefore costly. This means that the routine human resources policies focused on control, conformity, and standardization are in conflict with the needs for intrinsic motivation (Hosie, et. al., 2012).
Following the consideration of extrinsic and intrinsic sources of motivation and happiness, Zelenski, Murphy, and Jenkins (2008) note the growing recognition of the difference between state and trait level of analysis. A state approach is to ask, “Do fluctuations in happiness cause short-term differences in productivity?” And a trait approach is to ask, “Are happy people more productive over long periods of time?” Therefore, Zelenski, Murphy, and Jenkins employed a longitudinal perspective with multiple happiness indicators to examine both state and trait associations between happiness and self-rated productivity among Canadian middle managers (Zelenski, Murphy, & Jenkins, 2008).
Zelenski, et. al. (2008) found that happiness generally correlated to productivity in all aspects. Both those who are generally happy were generally productive, and those who experienced a period of increased happiness experienced a period of increased productivity. An interesting result of their research was that negative feelings or a short period of negative feelings did not adversely affect respondents’ productivity, but they noted that, “when interpreting this null result, it is important to keep in mind that our participants reported experiencing very low levels of negative affect, which precludes the conclusion that high levels of negative affect do not interfere with productivity. Presumably, some employees can experience low levels of anxiety, nervousness, etc. without it impacting their ability to perform. However, strong negative emotions, particularly when manifest as stress-related disorders such as depression, may be more likely to cause low productivity (Zelenski, et. al., 2008).”
Zelenski, et. al. (2008) concluded that, taken together, the results suggest that happiness has a positive effect, but that within their trait-level findings, to the extent that unhappiness is a disposition that resists change, organizational efforts to increase happiness may be unlikely to payoff in productivity gains (Zelenski, Murphy, & Jenkins, 2008). Short-term gains in happiness can boost productivity temporarily, so it may be beneficial to target generally unhappy employees, but given Hosie, Willemyns, and Sevastos in 2012, it may be hard or impossible to target all unhappy employees in an effective manner.
Control and conformity measures have long been a common tool in the management of staff. Fear can be a good motivator and result in an uptick in productivity and share price, particularly when fear is coupled with a layoff. But it tends to backfire quickly because it leads to a reduction in morale and people leaving to pursue other jobs. The cost of layoffs “could be 16,000 GBP per worker due to falls in productivity, morale, and a rise in employee turnover as those who could get other jobs decided to move on (Edwards, 2009).”
So fear is bad, but is happiness good? The Chartered Institute of Personnel and Development (CIPD) found that focusing on happiness, rather than just reducing stress, was beneficial. “Positive emotions make people more resilient to setbacks and help them find new ways of doing things (Edwards, 2009).”
Employment is changing. People are not staying in the same job until retirement, partially due to the demands-control model developed in the 1970s that focused on security for the employer through leverage of short-term contracts. This model is beginning to break down as individuals have more control over their own destiny. Employees are now introducing happiness into the equation, and are more likely now than in the past to leave a job if they are unhappy (Edwards, 2009). This doesn’t just impact the cost of recruitment, it also means a loss of training and subject matter expertise, which impacts productivity. Staff leaving impacts morale of the entire workforce, too, further drawing down productivity.
Nic Marks of the New Economics Foundation, as cited by Edwards (2009), lists four steps to a happy work environment. First, organizations need to identify good practices and build on the culture that already exists while appreciating the quality of current employees. Second, team leaders need to foster an environment that is both supportive and challenging. If done authentically, this will result in a team that is both more creative and more resourceful. Third, line managers need to support staff in the identification and exploration of personal strengths and skills and provide opportunities to use those at work. Fourth, individuals need to seek out work and workplaces that are interesting and enjoyable and where they can both foster good relationships and challenge themselves (Edwards, 2009).
Fostering good relationships can contribute to a more productive and profitable environment. “One of the most common reasons why teams fail to achieve their potential is a problematic relationship (LaFasto & Larson, 2011, p. 34).” 18% of management time was wasted on resolving workplace personality conflicts in 1996. Relationship problems are associated with absenteeism, damage and waste, and decreased organizational commitment. Healthy team relationships are characteristic of successful teams (LaFasto & Larson, 2011).
LaFasto and Larson (2011) go on to write, “With rare exceptions, members of effective teams describe the atmosphere of the team in positive terms. The team is relaxed, comfortable, informal, fun, warm. Teams that are good at problem solving have a way of making their members feel accepted, valued, and competent. Members of poor teams, on the other hand, tend to describe the climate as tense, overly critical, political, cynical, inhibiting, cold, or too stiff and formal (LaFasto & Larson, 2011, p. 68).”
There is more to influencing employee happiness than their team members, however. Fitzgerald and Danner (2012) suggested that one of the challenges to happiness in the workplace is the workplace itself. Humans developed, in an evolutionary sense, to be outdoors, and the typical office space is anything but natural. Introducing elements like sunlight and greenery “can exude specific psychological benefits in the workplace (Fitzgerald & Danner, 2012).” She goes on to write that while many workplaces do not provide the conditions necessary to help us be healthy, content, and efficient, research has provided empirically tested ways that the necessary conditions could be provided in modern workplaces if employers are willing to adopt an evolutionary psychological approach to organizing the work space. If this change is implemented, it may “drastically improve their workers’ physical and psychological health as well as their productivity (Fitzgerald & Danner, 2012).”
Sunlight cannot be replicated in regards to impact on human behavior. While full-spectrum fluorescent lighting has become popular because it is said to mimic sunlight and increase mood, health, and cognition in employees, recent research has shown that it does not have any of the positive effects similar to those of natural sunlight (Fitzgerald & Danner, 2012).
Beyond sunlight, our workplaces should better emphasize physical movement. This has health benefits in regards to lowering body mass, blood pressure, and cholesterol, and may also reduce the rate of absenteeism (Fitzgerald & Danner, 2012). Studies also show that organizations that emphasize employee health and facilitate health improvements will see increases in both productivity and work performance (Fitzgerald & Danner, 2012).
Taking an approach to workplace design from evolutionary psychology suggests that as we implement changes to improve our employees’ happiness and contentment, such as introducing additional sunlight, greenery and plants, providing opportunities for physical movement, and encouraging positive social relationships, this will create “a supportive environment for employees that will also increase employer profits (or, at the very least, decrease employer costs) (Fitzgerald & Danner, 2012).”
So in many respects, the emphasis is less on making employees happy and more on not making them unhappy, either through the creation of unnatural environments or the utilization of fear to motivate. Rost, Hongdao, and Stanley (2014) examine the impact of depression on the workplace by studying the influence absenteeism caused by depression has on both the productivity of the people absent and on those who are still at work but are influenced by the absent person. Extending this, they looked at the impact of absenteeism on the company’s capacity to deliver time-sensitive work, as well as on labor substitution in the context of a one-week absence. The former is known as product disruption, and the latter as friction (Rost, Hongdao, & Stanley, 2014).
Their findings were that the average company in the sample of 325 participating companies suffered a loss of $649 when absenteeism caused by depression impacted time-sensitive activities, and an average loss of $316 when substitution, either through temporary workers or re-allocating workload, was applied. The loss with friction correction is attributed to employees working more slowly, having to not do other work, and a general decrease in productivity due to overwork and/or needing to be trained on an unfamiliar task (Rost, et. al., 2014).
Rost, et. al. (2014) note that for nearly 50% of the companies in the current sample, the return on investment from health benefits was significant in their consideration of what benefits to offer, and the authors encourage employers and intervention developers to consider both the impact of absenteeism and presenteeism.
Many of the authors and articles consulted for this paper remarked on the significant breadth and amount of research in the topic areas of group size and happiness, but two deficiencies presented themselves in the research. First, a great deal of study on the subject occurred between the 1930s and the 1960s, then slowed considerably. Even recent articles written in the last five or ten years are generally relying on dated study of groups in either laboratory or office settings. Second, many of the articles considered are inconclusive, particularly in regards to happiness. There is an indication that changes may influence productivity, but particularly when it comes to environmental factors, there is a distinct lack of certainty.
While the correlation between happiness and productivity has been shown with general consistency, the capability to influence employee happiness has not been broadly proven, and as Chernoguz (2011) wrote, management is still more art than science. This does not preclude study, but it does suggest that qualitative rather than quantitative analysis will be needed.
The research on team size does point to smaller teams being generally more productive. A larger team may have greater output, but its per-employee productivity will be lower. This does not mean that a large team is bad, nor that it is inferior to a small team. Rather, it means that the larger the team, the less efficient it is. Many problems can be resolved through brute force application of more staff, though not all, but that doesn’t mean a larger staff is the best solution. At best, we could say that a larger staff may be more costly than is necessary for achieving a goal.
Once we establish the appropriate team size and begin the work, it is important that we do not modify that team size after a certain point in the project. Regarding issues of team training and re-tasking, the time when a team needs to have its membership locked may be later than many have interpreted based on The Mythical Man-Month. That said, team development towards maturity will be hampered by frequent changes in team composition.
Team size set at the outset of a project is crucial, coinciding with what Wheelan wrote in 2009, because it will impact the group progress through developmental stages. It is inarguable that some tasks, such as writing an operating system, are too large for a small team, but if teams are formed and then tasked with small pieces of the work (similar to Comstock, Jiang, & Davies’s concept of optimizing the release to the size of the team, rather than trying to grow a team to meet the size of a release), then an optimal team can be formed.
The concept of feedback and its relation to team size is particularly interesting. The original hypothesis of this paper was that smaller teams would facilitate better feedback, thereby contributing to greater productivity, but the literature highlights two problems with that thesis. First, smaller teams are capable of giving less feedback than larger teams, as Sornette, et. al. (2014) demonstrated in regards to large OSS projects. What’s more, the larger number of comments by fellow developers triggered bursts of increased productivity, creating a positive feedback cycle that would be lesser with a smaller team. Second, Suleiman and Watson (2008) showed that the most productive person worked alone with no feedback, not even self-feedback. Some feedback is necessary for correction and reducing re-work, so Suleiman and Watson’s findings suggest to us that feedback needs to be timely, actionable, and only when necessary. This leaves us with the two opposed team size structures, both of which were shown to be effective: the developer pair working in low concurrency, and the several hundred- or thousand-strong OSS team of contributors. There are clear similarities between these two, however. First, they both feature asynchronous, low concurrency work. Second, they feature high feedback and communication with low barriers to communication.
The research on team happiness indicates the unsurprising conclusion that happier people are generally more productive. What is less conclusive is whether people become happy because they enjoy their work, or if their happiness outside of work then contributes to them being more productive at work. This question becomes easier to consider when divided into an examination of extrinsic and intrinsic motivators, as well as examining fluctuations in the state of a person’s happiness and a person’s general happiness trait. When working through the question on these terms, the research shows that people who are happier are generally more productive, that events that cause temporary happiness likewise result in a temporary boost in productivity, and that happier employees are more resilient to challenges and negative occurrences. Unfortunately, the research also suggests that if a person is wholly unhappy, it is unlikely their manager can do much to make them happy and thereby increase their productivity. What’s more, because people are motivated by different things, wide-ranging programs to improve happiness are likely to fail to achieve their aims.
Subsequently, the research suggests that managers control what they can, including their management style and the environment of the workplace, both visually and culturally, to provide happiness where possible and to at least not cause unhappiness. If managers have little ability to make the unhappy happy, they can at least not impose unhappiness on those who would otherwise be happy. This is important because causing unhappiness, such that the workplace becomes an undesirable place to be, can contribute to depression and lead to absenteeism. This becomes costly both in terms of productivity when measured against the absent person’s normal output and in regards to the strain put upon other employees.
Due to the limitations of studies on happiness, qualitative research is most suitable. One of the challenges is that longitudinal studies would provide reliable results, but rapid advances in technology call for more recent and regularly updated studies. One of the limitations with current research is how dated it is, and data gathered in the 80s or 90s was from a time with a different corporate culture and communication accessibility in many companies. Technology changes even more rapidly now, and the work environment five years from now may be drastically different.
New research in this area will be significant as team membership continues to evolve and change. More companies are relying on globally distributed teams who never meet each other in person. How will these teams progress through the stages of team development? Is what we know about team size applicable to distributed teams who have even less opportunities for engagement and feedback? How will happiness at work be changed by innovations like self-driving cars or the ability to telecommute or more easily find a desirable job? These are questions that can be projected, but the questions that arise five or ten years from now may be unimaginable. Therefore, new research will be important, but new methods of research may need to be identified as well. Longitudinal qualitative studies begun now and conducted over 10 to 20 years may be focused on something that is irrelevant by the time they conclude.
The optimal team size is dependent on the ease of communication within the team and between teams. The easier the communication, the larger a team can be, and the more value is derived from the communication because it can trigger positive bursts of productivity. But regardless of team size, all teams will progress through the four stages of development, and a larger, or more distributed, or less experienced team will likely take longer to progress through those stages. Subsequently, the team’s productivity will be lower until it reaches the third or fourth stages as defined by Wheelan (2016).
Individual productivity can be trumped by team productivity if the team is large enough and the value of the output of the team is sufficient to justify the higher cost of having a less productive team. This suggests as well that a large and unhappy team can generate a higher output than a small but happy team, though at much greater cost.
Happiness is generally independent of team size but is influenced by a wide variety of factors, many of which are outside the control of the employer. But happiness is important to take into account because it does correlate to productivity, both in terms of an employee’s general trait of happiness and the temporary state of being happy. The organization should work to contribute to happiness where possible, such as providing a positive work environment with natural sunlight, plants, positive attitudes, and supportive team members. The workplace cannot necessarily cause happiness, but it can cause unhappiness, and it can support happiness. Avoiding contributing to unhappiness can reduce impacts of depression and absenteeism, as well as the impact of absentee employees on employees who are not absent. All of this helps maintain and even improve productivity, which results in higher profitability.
The impact of environment on happiness lacked satisfying conclusions and should be studied further. Fitzgerald and Danner (2012) indicate that certain environmental changes may influence happiness, which would in turn influence productivity, but a direct line from environmental improvements to productivity has not been determined.
Optimal team size for distributed and virtual teams has not been well-studied and warrants future research. Web conferencing solutions improve every year, and methods exist for long-distance collaboration that did not exist even five years ago. Brooks (1995) wrote that the most communication time was consumed at the interfaces between projects, but that may be different when it comes to distributed teams. There may be other areas where communication is as or more challenging, and there may be areas that are less challenging. Identifying these challenges or areas where distributed teams are actually more productive and successful might drive investment in mixed-mode teams where certain aspects of a project are handled remotely and others in-person. Combined with the findings of Parrish, et. al. (2004) regarding low concurrency review and feedback resulting in higher overall productivity could contribute to more mature methods of resource management and coordination of remote teams and distributed staff.
Last, no studies looked specifically at happiness within different sizes of teams. Much time has been spent on studying team size and productivity, and happiness and productivity, but little or none on happiness within different sized teams. Assumptions can be made based on the literature, but further research in this area would be beneficial.
Brooks, F.P. (1995.). The mythical man-month. Boston: Addison-Wesley.
Chernoguz, D. G. (2011). The system dynamics of Brooks’ Law in team production. Simulation, 87(11), 947-975. doi:10.1177/0037549710382423
Comstock, C., Jiang, Z., & Davies, J. (2011). Economies and diseconomies of scale in software development. Journal of Software Maintenance & Evolution: Research & Practice, 23(8), 533-548.doi:10.1002/smr.526
Edwards, C. (2009). The pursuit of happiness. Engineering & Technology (17509637), 4(4), 76-doi:10.1049/et.2009.0419
Fitzgerald, C. J., & Danner, K. M. (2012). Evolution in the Office: How evolutionary psychology can increase employee health, happiness, and productivity. Evolutionary Psychology, 10(5), 770-781.
Hosie, P., Willemyns, M., & Sevastos, P. (2012). The impact of happiness on managers’ contextual and task performance. Asia Pacific Journal Of Human Resources, 50(3), 268-287. doi:10.1111/j.1744-7941.2012.00029.x
LaFasto, F., & Larson, C. (2001). When teams work best. Thousand Oaks: Sage.
Parrish, A., Smith, R., Hale, D., & Hale, J. (2004). A field study of developer pairs: Productivity impacts and implications. IEEE Software, 21(5), 76-79.
Rost, K. M., Hongdao, M., & Stanley, X. (2014). Work productivity loss from depression: Evidence from an employer survey. BMC Health Services Research, 14(1), 59-75. doi:10.1186/s12913-014-0597-y
Schwaber, K., & Sutherland, J. (2013). The scrum guide. Retrieved from http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf
Sornette, D., Maillart, T., & Ghezzi, G. (2014). How much is the whole really more than the sum of its parts? Plos ONE, 9(8), 1-15. doi:10.1371/journal.pone.0103023
Suleiman, J., & Watson, R. T. (2008). Social loafing in technology-supported teams. Computer Supported Cooperative Work: The Journal Of Collaborative Computing, 17(4), 291-309.doi:10.1007/s10606-008-9075-6
Wheelan, S.A. (2009). Group size, group development, and group productivity. Small Group Research, 40(2), 247-262.
Wheelan, S.A. (2016). Creating effective teams. Los Angeles: Sage.
Zelenski, J. M., Murphy, S. A., & Jenkins, D. A. (2008). The happy-productive worker thesis revisited. Journal Of Happiness Studies, 9(4), 521-537. doi:10.1007/s10902-008-9087-4