Research on Teams with Multiple Boundaries

Proceedings of the 35th Hawaii International Conference on System Sciences - 2002

! Research on Teams with Multiple Boundaries J. Alberto Espinosa, Jonathon N. Cummings, Brandi M. Pearce Carnegie Mellon University [email protected], [email protected], [email protected]

Jeanne M. Wilson The College of William and Mary [email protected]

Abstract

with multiple geographic locations, functional areas, project affiliations or organizational memberships.

The main purpose of this paper is to discuss: (a) types of boundaries found in field research on teams; (b) methodological challenges encountered when examining teams that cross boundaries; and (c) possible research design solutions. Based on our own field research at three companies (a software development organization, a telecommunications firm, and a financial institution), we outline four different types of boundaries (geographical, functional, identity, and organizational) and discuss methodological issues in distinguishing the effects of one boundary where multiple boundaries existed. We suggest solutions to help: (a) isolate the effects of distance, (b) assess functional similarities within and across teams, (c) identify and control for the impact of multiple project affiliations, and (d) distinguish organizational level influences. Only through careful attention to measurement can we properly assess the effects of team boundaries and draw accurate conclusions about these changing forms of organizing.

As our understanding of these teams advances, we also realize that these boundaries are not always independent. For example, in many cases groups that represent multiple organizations also work at a distance, which introduces potential confounds. When boundaries are not clear or when they co-vary, it is difficult to draw firm conclusions about the observed effect of a particular variable or dimension. Although researchers may attempt to draw conclusions about the effect of one type of boundary, we often cannot be sure that the effects observed are not due to other differences, such as language, cultures, time zones, or local contexts. Drawing upon our individual research projects, we discuss four types of boundaries (i.e., geographical, functional, identity, and organizational) that we encountered, identify the methodological challenges, and suggest solutions. These observations are summarized in Table 1.

1. Introduction Recent trends in globalization and telecommunications are making new forms of organizing more possible and prevalent [15,17]. Communication networks and information technologies have provided tools and incentives for linking individuals and groups across geographic, functional, project, and organizational boundaries [6,7]. Work in organizations is increasingly carried out across such boundaries. One of the key components in linking people across boundaries has been the creation of new configurations of groups. These forms have evolved from traditionally fixed structures to a more fluid and emergent type of organizing. Although research on these new forms is increasing, we do not completely understand the implications of work across these boundaries [14,18]. Very little attention has been given to the methodological challenges of doing research on teams

2. Methodology This paper is based on observations from our individual field research in different companies. The first company is a Fortune 500 high technology firm. The groups studied are part of a main division that produces large-scale real-time software. The study is about coordination in software development, so we refer to this research as the study about “Software Teams.” It involved semi-structured field interviews of 36 software developers and managers across two European sites (Germany and England), and observations of cross-site coordination meetings. These sites develop software for a major subsystem, which is implemented incrementally in the form of product releases and new features. A feature is implemented through one or more software “modification requests” (MR). MR’s can involve one or any developers, and can take a few weeks to several months to implement.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE

Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS-35’02) 0-7695-1435-9/02 $17.00 © 2002 IEEE

1


Software teams

Product Development Teams

Banking Teams

Geographical Boundaries! Issues

Issues

Issues

Confounding effects: language, culture

Temporal component of distance (e.g., travel, relocation)

The "meaning" of distance! The non-linear nature of distance

Distance is not random, self-select

Solutions

Solutions

Solutions

Assess distribution early and late in the project

Triangulate on the measurement of distance

Use contexts with strong similarities Use groups with similar mix of skills across locations

Functional Boundaries Issues

Issues

Issues

Functional expertise

Perceived and actual functional representation

Function co-varies with expectations

Solutions

Measure expectations/reputation of function

Software process phase specialization Solutions Use groups with even mix of specialization across locations

Measure self-reported and company records

Solutions

Identity Boundaries Issues

Issues

Issues

Feature teams & multiple features Levels of integration

Time commitment differs across members

Identity a powerful influence on behavior

Solutions

Solutions

Unit of analysis: work processes

Control for amount of time as well as variation of time commitment with team

Multiple membership affects affiliation

Study low levels of integration first Control for level of involvement in task

Solutions Measure group/unit identity directly

Organizational Boundaries Issues

Issues

Issues

In-house or outsourcing

Members exist in two contexts

Interdependencies with institutions

Suppliers or customers are also on the teams

Solutions

Solutions

Use in-house groups

Include all members, regardless of organization, in assessments

Study groups with low external interdependencies

Organizational affiliation does not exert a uniform influence Solutions Measure variables in the home organization context

Table 1 - Researching teams with multiple boundaries: Issues and solutions

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


2


The second company is a Fortune 500 telecommunications firm. Observations are drawn from 45 groups that worked in product development (e.g., designed handheld scanning device for shipping company, developed utility for detecting wiring errors on electrical boards), thus we refer to this sample as “Product Development Teams”. The third company is a financial institution that uses teams to provide various financial services. We refer to this research as the study about “Banking Teams”. A total of 78 banking teams were observed and surveyed over the course of the teams' first year working together. The teams managed the employee retirement accounts of large corporate customers, with an average account value of 2.3 billion dollars. Some of the teams were almost fully colocated, and other teams were completely dispersed. In the following sections, we first describe, analyze and present the solutions we adopted when faced with geographic, functional, identity and organizational boundaries in our respective research studies. We then use these observations and solutions to draw more general conclusions about these boundaries based on the commonalities found among these studies.

3. Geographic Boundaries There have been a number of research studies on the role of distance in teamwork [1,4,19]. However, the effect of geographic distance is often difficult to isolate in the face of other factors often associated with distant collaborators, such as language, cultures, time zones, or local contexts. For example, geographic distance in distributed software development is generally associated with increased coordination overhead and more substantial delays [10]. But it is difficult to discern if these increased inefficiencies are due to geographic distance alone or because of other factors such as different management practices among the dispersed sites.

example, the German group had a long history of stability with the company, while the English group was established in recent years and had higher employee turnover, making it difficult to isolate the effects of distance. When faced with many correlates of distance, one way to address the problem is to select the sample in such a way that you reduce variation on the other co-variates. In this study we reduced variation on time zones and familiarity by focusing on developers working on a particular software release. While developers in England and Germany collaborated with other sites, we limited the study to these two countries because they had a closer collaboration and stronger similarities (e.g., time zones, familiarity with other site, fluency in English, same continent, etc.). For the next phase of this study, we selected software developers from a different software organization in which a majority of the development work is done between the U.S. and England. Developers for this product in both sites had substantial similarities in methods, approaches, language and culture than the previous groups, thus helping us isolate the effects of geographic distance. The second methodological issue we found with respect to geographic boundaries in the Software Teams is that geographic location was not necessarily an exogenous factor. Work is often divided and distributed in order to reduce coordination problems, and that this work tends to be distributed either by function, product structure, software process phase, or by proximity to clients [9]. This issue was addressed in the study by focusing on developers for a single sub-system and then interviewing a mix of developers with similar functional, product and software process responsibilities across locations. For the next part of the study, we narrowed down the participant pool to developers of a single subsystem, who worked in one software phase (i.e., coding).

3.2. Product Development Teams 3.1. Software Teams While 59% of the software team members interviewed did not view coordination as a problem with co-located development, 94% of them reported problems with development across geographically distant locations. However, many of the problems cited were not directly associated with distance per se. The most frequently cited problem was lack of familiarity with colleagues and contexts in other sites (e.g., knowing who and when to call). Also, 44% indicated problems with the communication media, such as not being able to share information easily. Furthermore, there were different levels of expertise and tenure among these groups. For

Although researchers often refer to team geographic distribution in terms of the number of locations where members work, distance is not always a static phenomenon. It is often the case that group members travel frequently or move locations because of new buildings or organizational restructuring. Therefore, members are not always resident in their assigned office or they may move to an entirely different location during the team project. This means that static measures of geographic distribution do not always capture the complexity of being distributed in space and time. Two teams exemplify how geographic distribution can be more complex than distance alone. First, an electrical

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


3


circuitry team had 9 members from engineering and quality assurance, who were spread across France and Switzerland. Their task was to develop the next generation airbag system for automobiles through electrical circuitry. One of the members in this team moved twice during the project, once from Switzerland to France to be with the team toward the middle of the project, and then back to Switzerland toward the end of the project. In a second example, a handheld device design team had 10 members from engineering, project management, and customer service, who were spread across Arizona, Georgia, Illinois, Tennessee, and Israel. Their task was to design a scanning device for a shipping company. One of the members in this team worked at home in Georgia during the project, and commuted to Tennessee whenever the team needed to make decisions. One solution employed for assessing geographic distribution was to divide the project into two stages: early and late. We then measured the extent to which members were distributed at each stage as well as the change in distribution over time. Another option could have been to use the location where the member spent most of his or her time, or weight the distribution score by the percentage of time spent in a particular location. No matter how researchers account for the different patterns of distribution throughout a project, it is crucial to understand how these factors change over a project cycle.

3.3. Banking Teams In the past, results have tended to show that team members have more synchronous and frequent interaction with local peers and are likely to have stronger affiliations to local workgroups than the distributed team. However, as mentioned above for the software teams, location may not be an exogenous variable. Organizations make decisions about where employees will be located for all kinds of reasons, which may affect dependent variables of interest. For instance, in previous experiments with distributed work at the bank we studied, managers made conscious decisions to relocate some members back to the main headquarters in an effort to create more cohesive teams. In this case, team dysfunction led to co-location. Any attempts to draw conclusions about the effects of colocation would have been clouded by an unspecified relationship between an exogenous causal variable (team performance) and the independent variable of interest (geographic distribution). Once other related variables have been identified, researchers are still left with the problem of how to measure distance or geographic dispersion in teams. For instance, in one team at the bank, one member was located on the 11th floor of a downtown office building, another member was located on the 9th floor of an adjacent office building downtown (connected by a

skybridge), the 3rd and 4th members were located in a back-office operation about 5 miles from downtown (although not on the same floor), and a fifth member was located in Atlanta approximately 757 miles away. In this case, most of the analysis was conducted at the dyad level. Members of each team rated how much they interacted with and trusted every other member of the team. The distance between each pair of members was easily calculated and used in the analysis. However, it is more common for team studies to be conducted at the group level of analysis. A group-level measure of geographic dispersion of the same team based on the greatest distance between team members (one measure used in the past) would not adequately reflect the clustering of team members in one city. It might be more appropriate to use the weighted average travel time between sites. Alternatively, the location of some members may be more important than others. Consider the difference in meaning if the team leader was located in Atlanta rather than the headquarters city. In this case, average distance from the team leaders might be a more appropriate measure of distance.

4. Functional Boundaries Cross-functional teams face unique challenges as a result of having members representing different functional areas, such as marketing, engineering, and manufacturing [2,5,8]. Because functions are often interrelated with knowledge, skills, and experience, cross-functionality measures in teams are not necessarily independent from other important measures.

4.1. Software Teams Functional boundaries can often have stronger effects than team identities or team boundaries. If researchers only measure team effects they may miss important determinants of behavior. As an example, the software study focused initially on feature development teams. But the feature team concept was relatively new to the groups under study and it became quite clear that a feature implementation was viewed more as a task than as teamwork, and that feature teams were strongly divided by functional boundaries. Most interviewees had stronger bonds to their organizational departments, peer technical specialists or peer software process specialist (e.g., design, coding, testing, etc.). This made it difficult to study the effects of other boundaries because strong functional affiliations changed the meaning of other boundaries. For example, testing engineers in England and Germany seemed to have a very close “collaboration” distance and more common ground because of their familiarity with technical terminology, procedures, work schedules, and deadlines. On the other hand, one group of

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


4


technical specialists in Germany appeared to have a farther “collaboration” distance with other developers even within their own building. This issue was addressed by selecting an even mix of functional and software process specialists from both geographic locations in order to account for the functional differences by location. For the next phase of the study, we narrowed down the participant pool to developers working in a single software phase (i.e., coding) for a single sub-system (i.e., requiring somewhat similar functional expertise), again at both locations.

4.2. Product Development Teams An important observation that arose in the study of cross-functional teams was the distinction between perceived and actual functionality. Team leaders were asked in a survey to indicate the functional area of each team member. However, the responses to this question were not uniform across teams. Leaders seemed to report greater functional similarity within a team when the disciplines were distinct (e.g., engineering, manufacturing) compared to teams where the disciplinary boundaries were less clear (e.g., design engineering and layout engineering rather than "engineering"). It appeared as though the more similar team members were with one another, the greater the attempt leaders made to differentiate their functions. The leaders indicated their perceived functionality of the team rather than the functions provided by the company database records. Two teams illustrate the contrast between perceived and actual functionality. First, a circuit design team had 9 members from engineering, who were spread across US, Israel, Singapore. Their task was to design chips that processed digital signals more efficiently in electronic products. Even though the 9 members in this team represented the company’s engineering function, the leader reported that 5 of these members were in design engineering, 1 member was in layout engineering, 1 member was in product engineering, 1 member was in field application engineering, and 1 member was in computer-aided design engineering. Second, a mobile manufacturing team had 11 members from engineering and manufacturing, who were spread across US, Germany, and Ireland. Their task was to design mobile phones with integrated feedback from manufacturing early on in the process. However, the leader of this team reported that 8 were from engineering and 3 were from manufacturing. When assessing cross-functionality, researchers need to be clear whether they want to measure perceptions of functional differences among team members (as team leader surveys would yield) or actual differences among team members (as company records would show). A solution we used here was to create two indices of cross-

functionality, one in which team leader or member distinctions were used, and another in which the company distinctions were used. If company records are not available, then alternative coding schemes can be devised to differentiate between true functional differences and a potential bias on the part of team leaders or members to distinguish themselves from others.

4.3. Banking Teams Although functional roles are seemingly easy to measure, function is often confounded with other important variables of interest in these new group configurations. This was certainly the case in the banking teams; but the related variables were not obvious or immediately apparent. Several months of on-site observation of 3 representative teams revealed that in the case of the banking teams, function was sometimes confounded with geographic distance as well as with status and preconceived expectations about team members' behavior. For instance, in the case of the banking teams, one whole function (the accounting or information delivery analysts) was located in a "backroom" technical center several miles from the downtown headquarters of the bank, whereas most (but not all) of the relationship managers were located in the headquarters building. This meant that at least these functions co-varied largely with geographic distance. In this setting, it would have been impossible to determine whether low trust between the relationship managers and the accountants on each team was due to distance or due to functional differences. This situation is often true in organizational settings where the R&D facility is physically removed from the main office, and customer service or other "back-office" functions are relegated to other locations. In the example given, it was possible to differentiate the effects of geography and function because other functions were less systematically distributed. Another issue that became apparent in early observations and interviews with banking team members was that functions were associated with certain organization-specific reputations. For instance, in this case, the risk and performance analysts had a reputation for being picky and detail-oriented. Other team members expected them to go over the monthly reports the team produced, find errors, and then publicly blame others. These expectations resulted in a form of confirmation bias. The accountants felt they did not need to check the foreign currency rates for the client's global investments very carefully, for instance, because they could count on other analysts to pick up mistakes. This behavior, of course, resulted in the other analysts finding plenty of mistakes. This cycle of behavior ultimately resulted in a deterioration of the relationships between the accountants and the other analysts. If "function" was being used as a

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


5


proxy for "unique knowledge contribution," as it often is, there would be no relationship between diversity of function and knowledge sharing in this case. Lack of communication and disregard for the other function's expertise would act as suppressor variables (i.e., other influences which co-vary with function have suppressor effects or produce spuriousness in the relationship between function and the dependent variable of interest). One solution to this problem was to measure the effects of role reputation before the start of the teams and to use this as a control variable in the analysis.

5. Identity Boundaries Team members are often involved in more than one project or team at a time, thus making it difficult to define team identities. Members of a distributed team may have started a new project before finishing the current one. Or, they may have been assigned to multiple projects. Furthermore, the particular project they were working on may have been part of a larger project that has complex interdependencies. When team members are part of multiple projects or multiple teams, the challenge for researchers is to distinguish the contribution or impact of participation in one effort from another. Since identification can have powerful effects on behavior (e.g., satisfaction, turnover, and performance) [3], it is important to carefully consider team identity boundaries.

5.1. Software Teams Methodological issues with team identity can often be addressed by identifying the right level of analysis. The critical issue is to measure at a level where the team identity is meaningful. In the software teams, developers often did not identify with their feature teams because they worked on multiple features in parallel. Other development organizations within this company that used feature teams had developers who were fully dedicated to single features. For example, one functional expert and a testing engineer were assigned to all feature teams of one particular release. Consequently, there was a stronger sense of identity with the larger release team than with the smaller feature team. On the one hand, release teams had well defined boundaries and memberships, but they were too large and complex to use as a unit of analysis (e.g., 40 to 60 people). On the other hand, while feature teams were more manageable in terms of size, they did not have a strong sense of identity because of the number of simultaneous features they were associated with. This issue presented substantial challenges in identifying the proper unit of analysis. These were addressed by interviewing primarily developers and managers from one release team. In the next phase of the study we selected a smaller unit of analysis, the MR

(modification request), and we only analyzed work done in a single software development phase (i.e., coding). Because a MR is a smaller unit of work (e.g., 1 to 10 developers), it helps us understand the underlying work processes and building blocks for features and releases. While developers are not always dedicated to a single MR, they seem to have a stronger sense of identity with the MR’s. Also, by narrowing the focus to coding work only, we eliminated some functional boundaries that would otherwise introduce confounds in the study. In addition, we control for the level of involvement of developers in their respective MR’s. Overall, we felt it was important to develop a good understanding of the work processes at this level of software integration before attempting to study higher levels.

5.2. Product Development Teams While work group boundaries are often set by who is “in” and who is “out,” there are substantial differences across teams in terms of how much time members commit to the team. In the sample of work groups discussed here, the average time commitment to each project was 60%, which meant that 40% of member time at work was devoted to another project. Furthermore, all team members within a group did not necessarily devote the same amount of time. Some members participated fulltime, yet others only participated part-time or when needed. Understanding how much time and energy members invest into the project reveals their stake in the group, which often plays a role in the strength of their identification. However, time commitment is not always a perfect proxy for identification in the group. Two examples provide a good comparison that shows these differences in time commitment or identification. First, a material bonding team had 10 members from engineering and quality assurance, who all worked in Malaysia. Their task was to improve the performance of semiconductor chips through shrinking the size of bonding materials. In the material bonding team, the percentage of time members spent on the group project ranged from 60-70%, which means that all members of the team were committed in similar ways, However in a second example, a memory chip team, had 10 members from engineering and project management, who all worked in Texas. Their task was to integrate different circuitry technologies for new SRAM memory chips. However, in the memory chip team, the percentage of time members spent on the project ranged from 40-90%. This means that there was much less consistency in how much time at work was put into the project compared to the first team. In terms of defining membership for a team, one solution was to include members if the team leader saw an individual as part of the team. However, going beyond

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


6


dichotomous decisions about who is in or out, it is also important to control for the extent of membership, such as the time commitment of members. A source of conflict for members may be the disparity in participation or identification in the team, and researchers interested in the individual reactions to group processes need to pay particular attention to time commitment. For example, when assigning responsibility for parts of a task, time commitment can be extremely important because if one member is only spending 30-40% of his or her time on the task, then it will take longer to produce a piece of work than a member who is spending 80-90%.

5.3. Banking Teams As is common in many organizations today, some members of the banking teams belonged to multiple teams. For instance, Pat Smith, an information delivery analyst, tracked the accounts of both General Motors and Advanced Micro Devices, making her a member of both teams. The obvious issue in this situation is that if people are members of more than one team included in the analysis, you may be violating the independence assumption required in many statistical tests. One answer to this problem is to exclude teams in which any of the members overlap with teams that are already in the sample. Although this solves the problem of independence, it does not address all of the issues associated with identity in these cases. There are several implications of belonging to more than one team. One issue is that Pat Smith simply cannot devote as much time to both teams as someone who belongs to only one team. Pat's ratings of the team are based on a smaller sample of team behavior than the other members of the team, who may be assigned full-time to one team. This can be handled by measuring the percent of time that each member spends on team activities, and using time as a covariate in the analyses. But percent of time is not the only implication of this difference. Pat may feel more or less identified with the two teams. Identification with a group does not always co-vary with the amount of time spent on group activities. In fact, in this case, Pat started her career at the bank working on the General Motors account. Even though Pat spends more of her time on the Advanced Micro Devices team, Pat continues to think of herself primarily as a GM team member, because GM is a prestigious client. The fact that identity does not always co-vary with time spent in a group suggests that in groups composed of members with multiple affiliations group identity may need to be measured directly.

6. Organizational Boundaries An important implicit assumption that has permeated most team research is that members belong to a single

organization. As our understanding of new forms of organizing evolves, it is apparent that inter-organizational arrangements, such as outsourcing, joint ventures, partnerships, and alliances, are leading to an increase in the utilization of groups that cross organizational boundaries [20].

6.1. Software Teams Conventional assumptions about the effectiveness of working within organizational boundaries versus across organizational boundaries are not always correct. The software teams interviewed had a fair amount of collaboration with developers in India where two different organizations were involved: an in-house group from the same company and an outsourced group, which employed highly skilled software engineers. Participants indicated some preference for working with the outsourced group. The in-house group was more hierarchical and formal, and it was more difficult to have fluid communication with them because formal channels had to be followed. It was also difficult for developers to talk directly to managers and directors above their own levels in the organizational structure. In contrast, developers had very direct and smooth communication with their peers in the outsourced group, partly because contractual agreements established more clear roles and responsibilities for them. Furthermore, many developers from the outsourced group traveled to both England and Germany to be trained for extended periods of time, thus forming stronger bonds with their team members there. On the other hand, because the company we studied used secure communications and firewalls, it was much more difficult for the outsourced group to access company resources inside the company’s secure intranet. These differences in communication patterns and access to internal information between the in-house and outsourced groups made it difficult to study the effects of other boundaries (i.e., geographic distance) with Indian groups because we could not always distinguish the effects of distance from those of different organizational practices. We resolved this issue by interviewing developers in England and Germany only, thus excluding outsourced groups, but we asked them to describe their interactions with their Indian peers to gain some insights into these working relationships. In the next phase of the study we selected developers from England and the U.S. that produce most of the software in-house.

6.2. Product Development Teams Some of the product development teams included members from different divisions or members who represented the customer organization. Issues arose for groups whose members came from different organizations, in part because they were less likely to

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


7


share common ground or experience. Furthermore, ingroup or out-group differences may have resulted from decisions made in the group, such as where to allocate resources. For example, conflict can arise if team members are from two organizations, but one of these organizations offers its members a higher pay, better accommodations, or more administrative support. Two teams provide examples for how group members can span organizational boundaries. First, a silicon wafer team had 5 members from engineering, all of whom worked in Scotland. Their task was to increase the quality of silicon wafers for transistor manufacturing. In this team, 2 of the 5 members were from the supplier organization, which allowed them to monitor and supply materials needed for the project. In a second example, a circuit cost team had 8 members from engineering and manufacturing, who were spread across Texas and Arizona. Their task was to redesign circuits that yielded faster data rates at a lower cost. In this team, 4 out of 8 members were from a separate company, which was then purchased by the larger company, so during the project members essentially became part of the same company. When determining member affiliations and the impact of being a part of different organizations, one solution used was to solicit feedback from all parties involved, not just the members of the parent organization. An oversight of some members could leave out important information about the group, which may in fact yield the most interesting insights. Moreover, the context of members in all organizations represented should be considered to uncover other possible influences on group behavior, such as the availability of resources.

6.3. Banking Teams Although the banking service teams were generally composed of members from within the bank, there were other teams within the larger financial services organization that crossed organizational boundaries. It was clear in the case of the cross-organizational teams that members managed their commitments to the crossorganizational team by either exaggerating or downplaying the pressures they felt from their home organization. In cases where a member wanted to minimize her commitment to the cross-organization team, she would overstate the size of her workload in the home organization. In other cases, where a member really wanted to participate in the cross-organization team, he might fail to report all the pressures he was experiencing in his home unit. The implication for the study of crossorganization teams is that it is very important to measure not only what is going on within the team, but also pressures and influences from the home environment. As in the case of within-organization identity issues, members are often positioned in more than one camp, and

ignoring critical parts of their jobs may result in a skewed view of the situation. Moreover, it is not possible or advisable to assume that organizations exert a uniform influence on members in these cross-functional teams. Certainly they do not exert a uniform "pull". In some cases the influence may be a "push," as in the case of a dissatisfied employee who would like to get a job with one or more of the organizations involved. Team member loyalty, behavior and decisions are not always going to be aligned with those of their home organization.

7. Common Observations As our understanding of groups that cross boundaries continues to evolve, it is important to recognize the complexities of the underlying context, and how this affects the design of our research as well as the implications of our results. Teams in real organizations often have multiple boundaries defined by location, function, identity, and organizational boundaries. As a result, researchers are faced with a number of challenges when studying such teams. We discuss some of these challenges below in the form of answers to methodological questions we encountered in our studies. Which unit of analysis should be selected? Unless one is studying teams that are co-located, homogeneous in function, and fully dedicated to their teams, multiple boundaries will exist within teams. This makes the identification of the appropriate unit of analysis for the study very challenging in some cases. This was particularly the case with the software teams in which multiple technical functions, software processes, and levels of integration made it difficult to identify an effective unit of analysis. In essence, teams had multiple boundaries. Furthermore, smaller teams (e.g., MR or feature teams) were nested within larger teams (e.g., product release teams). We found, for example, that coordination problems at lower levels of integration were much more numerous, but were easier to resolve because they were mostly technical in nature. Coordination problems at higher levels of integration were fewer, but a lot more substantial and harder to resolve because they involved different divisions, and often resulted in substantial re-planning, re-work, and unrest among managers. The units of analysis for product development teams and banking teams were somewhat easier to select because the identity boundaries present were not as marked. However, these teams had stronger functional, geographic, and organizational boundaries, which needed to be considered. Researchers should select a unit of analysis based on both theoretical and practical reasons, including how many boundaries are present. What should be included in the unit of analysis? Once a unit of analysis is selected, there are still tradeoffs

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


8


involved in selecting who belongs in it. Team membership can be narrow or broad in scope. For example, one can be more inclusive of team members, yet controlling for the presence of other boundaries. Also, if multiple units of analysis are present, one can collect data at several levels and then use hierarchical linear modeling to estimate effects at both levels [11]. Alternatively, one can be more selective to reduce boundaries within the team, but this comes at the expense of not learning about these cross-boundary effects. In the product development teams, for example, team leader assessments were used to determine who was a team member and who was not. While some of the tasks involved non-team members, the responsibility for the success or failure of the product developed lay in the hands of the members. It is ultimately up to the researcher to determine which locations, functions, and organizations to include. Which of the boundaries do we need to control for? When multiple boundaries are present within teams these boundaries introduce potential confounds. Geographic distance, in particular, can be vulnerable to such confounding factors. For example, while co-located software teams tend to be more coordinated than geographically distributed ones, this may be attributed to factors other than distance, such as differences in expertise diversity and functional affiliations within the team. Similarly, if we are studying coordination across functional boundaries, it will make a difference if such functions are collocated or geographically distributed. Consequently, research studies on distributed teams with multiple boundaries need to control for membership in other functional, identity or organizational groups whenever it is anticipated that such boundaries may affect the dependent variable under study. Which interactions should be explored? While controlling for main effects of particular boundaries is important, it is quite possible that some of these boundaries interact with one another. For example, some members of the banking teams who were in different geographic locations also represented different functions, so it is possible that the possible negative consequences of distance (e.g., lower communication frequency) could be compounded by possible negative consequences of different functions (e.g., lower communication quality). In other words, while it may be difficult for team members to communicate across geographic and functional boundaries, the difficulty of communicating across both could be much greater. It is up to the researcher to determine whether or when boundaries interact with each other, and to include the interaction terms if necessary. How should boundary variables be measured? The particular boundary measure used in any given study may depend on what aspects are most important. For example, if we need to control for functional boundaries, we could measure the number of functions represented in a team, or

if more appropriate to the task, we could instead measure the functional heterogeneity within the team. Similarly, if we need to control for organizational boundaries, we could dichotomize the measure (i.e., 1 if organizational boundaries are present or 0 if not) or, again, we could measure the heterogeneity of organizational affiliations within the team. When it comes to geographic boundaries, for example, the results of research on the effects of geographic distance on social influence [13] were called into question because of errors in the measurement of distance [12]. Latane et al. reported that social influence (as measured by memorable interactions) was determined as a function of distance. When Knowles re-analyzed the same data, he found that the results they claimed were largely an artifact of how they measured distance. Latane et al. used 11 distance categories, which varied in width from 100 feet to 68,380 feet. They chose to divide the number of memorable interactions by the number of miles in each distance category to get the number of memorable interactions per mile. Unfortunately because the width of the category was in direct proportion to the distance of the category (narrow categories at close distances and wide categories at far distances), the results were found to be an artifact of how they chose to measure distance. Memorable interactions were highest for people who lived close (within 100 feet) and people who lived far (5 and 20 miles away). In the case of geographically distributed teams, what often matters is the level of dispersion within the team rather than the physical distance between any pair of members. O'Leary [16] has outlined 4 measures of distance or dispersion: (1) number of sites represented within the team, (2) degree of isolation (one over the average number of team members per site) to address sublocations within the team, (3) separation of sites—i.e., the weighted average travel time between sites, and (4) minimum aggregate travel or center of population, as used in geography. He also suggests measures that address some of the confounds typically associated with raw distance measures: (1) shared work hours—to address the correlation between increasing distance and decreasing opportunities for synchronous interaction, and (2) role maps—to reflect the fact that distance from some members (i.e., the leader) is more important than others. Perhaps similar metrics can also be adopted when measuring distance across functional, identity and organizational boundaries. Also, since distance is often a proxy for other variables of interest (frequency of interaction, familiarity with the other members, etc.), this suggests that it is important to consider what distance means in the specific context, and to select one or more measures that represent the aspect of distance that is most relevant.

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


9


[10] Herbsleb, J. D., Mockus, A., Finholt, T., & Grinter, R. E., “Distance, Dependencies and Delay in a Global Collaboration”, Proceedings, CSCW 2000 Conference. ACM Press, 2000

8. Conclusions In this paper, we have used empirical evidence from real organizations to raise awareness of the complex methodological challenges that exist when conducting research across boundaries. Specifically, we have addressed the potential confounding effects of multiple boundaries, the importance of understanding context to ensure validity, and the role of the individual investigator in determining the salience of specific boundaries. For researchers interested in group processes and virtual organizations, the treatment of these boundaries in future research is a consequential issue. Our analyses are important to the information systems research community because teams with multiple boundaries are often mediated by information technologies, and it often involves virtual, geographically distributed, and asynchronous (i.e., different-time) collaboration. These areas have achieved high visibility in the literature and researchers need the best approaches for studying teams in such contexts. One of the contributions of this paper is to highlight boundaries that have important methodological implications for future research.

[11] Hofmann, D.A., “An Overview of the Logic and Rationale of Hierarchical Linear Models”, Journal of Management, 23, 723-744, 1997 [12] Knowles, E.S., “Distance Matters More than You Think! An Artifact Clouds Interpretation of Latane, Liu, Nowak, Bonevento and Zheng’s Results”, Personality and Social Psychology Bulletin, 25, 1045-1048, 1999 [13] Latane, B., Liu, J.H., Nowak, A., Bonevento, M. & Zheng, L., “Distance Matters: Physical Space and Social Impact”, Personality and Social Psychology Bulletin, 21, 795-805, 1995 [14] Lipnack, J., & Stamps, J., Virtual Teams: Reaching Across Space, Time, and Organizations with Technology, New York: John Wiley & Sons, 1997 [15] O'Hara-Devereaux, M., & Johansen, R., Global Work: Bridging Distance, Culture, and Time, San Francisco: JosseyBass, 1994 [16] O'Leary, M.B., “Varieties of Virtuality: Separate but not Equally”, paper presented at the FIU Workshop on Distributed Work and Virtuality, Miami, March, 2001 [17] Sproull, L., & Kiesler, S., Connections: New Ways of Working in the Networked Organization, MIT Press, 1991 [18] Townsend, A., DeMarie, S., & Hendrickson, A., “Virtual Teams: Technology and the Workplace of the Future”, Academy of Management Executive, 12(3), 17-29, 1998

9. References [1] Allen, T., Managing the Flow of Technology, Cambridge, MA: MIT Press, 1977 [2] Ancona, D., & Caldwell, D., “Demography and Design: Predictors of New Product Team Performance”, Organization Science, 3(3), 321-341, 1992 [3] Ashforth, B.E. & Mael, F., “Social Identity theory and the Organization”, Academy of Management Review, 14, 20-40, 1989

[19] Van den Bulte, C., & Moenaert, R., “The Effects of R&D Team Co-Location on Communication Patterns Among R&D, Marketing, and Manufacturing”, Management Science, 44(11), S1-S18, 1998 [20] Yan, A., Louis, M.R., “The Migration of Organizational Functions to the Work Unit Level: Buffering, Spanning and Bringing Up Boundaries”, Human Relations, 1999

[4] Conrath, D., “Communication Environment and its Relationship to Organizational Structure”, Management Science, 20, 586-603, 1973 [5] Denison, D., Hart, S., & Kahn, J., “From Chimneys to Cross-Functional Teams: Developing and Validating a Diagnostic Model”, Academy of Management Journal, 39(4), 1005-1023, 1996 [6] DeSanctis, G. & Poole, M.S., “Transitions in Teamwork in New Organizational Forms”, Advances in Group Processes, 14, 157-176, 1997 [7] Drucker, P.J., Concept of the Corporation, Brunswick, Transaction Publishers, 1993.

New

[8] Eisenhardt, K., & Tabrizi, B., “Accelerating Adaptive Processes: Product Innovation in the Global Computer Industry”, Administrative Science Quarterly, 40, 84-110, 1995 [9] Grinter, R.E., Herbsleb, J.D., and Perry, D.E., “The Geography of Coordination: Dealing with Distance in R&D Work”, Proceedings, Group '99 Conference. ACM Press, 306315, 1999

0-7695-1435-9/02 $17.00 (c) 2002 IEEE


10