In this course we shall explore some of the concepts, issues and theories that apply when working as a member of a team. Some of these factors are generally applicable to all teams – both face-to-face and virtual. Other factors are enhanced, reduced or changed by the degree to which the team is a virtual team.
This OpenLearn course provides a sample of postgraduate study in Management.
After studying this course, you should be able to:
understand the issues and processes that relate to team formation and development in a virtual context
identify barriers to effective team work in a virtual environment and propose solutions
review and comment on team activities in a virtual environment and develop insights to make informed judgements and recommendations for future good practice
synthesise theory and practical experience to make recommendations for good practice in new team environments.
Different organisations and situations may well use different types of team. The type of team affects how that team is organised and managed and what the communication needs of the team are. These in turn are affected by the nature of the task that the team has been created to carry out.
In this section we discuss four types of team: project teams, operational teams, self-managed (or self-directed) teams, and communities of practice. In practice, it is often the case that teams do not fall clearly into one type of team, but may combine elements of different types of team. While project teams and operational teams have been recognised for many years, self-managed teams are a relatively recent phenomenon and reflect flatter organisational structures and the management style of the times. Communities of practice, some would argue, are not teams, but they have come into prominence with the development of the internet, which facilitates bringing together groups of like-minded people who have some shared purpose.
A project team consists of a group of people who come together as a distinct organisational unit in order to work on one or more projects. The team is often led by a project manager, although project teams may also be self-managed. There are several commonly accepted types of project team: the functional team, the matrix team and the contract team.
A functional team is a team in which work is carried out within a functionally organised group, where people working together carry out the same or similar functions. In organisations where functional divisions are relatively rigid, project work can be handed from one functional team to another in order to complete the work. For example, work on a new product can pass from marketing, which has the idea, to research and development, which sees whether it is technically feasible, then to design and finally to manufacturing. This is sometimes known as ‘baton passing’, following the analogy of a team running a relay race. Needless to say, developing projects using this type of teamwork requires that a manager with oversight of the entire project must ensure that each functional team hands work over to its successor team in such a state that the successor team can carry on with it without undue problems.
The baton-passing technique has been used to hasten product development and reduce time to market by having teams (not necessarily functional teams) distributed in locations around the world. As the working day finishes in one location, so the team’s work is passed on to the next location, where the working day is just beginning.
Matrix structures are often found in project teams. In a matrix team, individual staff report to different managers for different aspects of their work. Staff will be responsible to the project manager for their work on the project, while their functional line manager will be responsible for other aspects of their work, such as training and career development, as well as ‘routine’ tasks. This matrix project structure is represented in Figure 1.
Figure 1 description
The figure shows a table structure with five columns, four of which represent four different departments. The first column is labelled ‘People assigned to the team’. The second column is labelled ‘Design’ and there is just one name given: ‘Andrew’. The third column is labelled ‘Research and development’. There are two members of the team from this department: ‘Bashar’ and ‘Colin’. The fourth column is labelled ‘Manufacturing’, with three team members being from this department: ‘Davina’, ‘Edward’ and ‘Fi-Han’. The fifth column is labelled ‘Marketing’ and has just one member: ‘George’.
It is important to overcome the problems that staff might have with the dual reporting lines (the ‘two-boss’ problem) because it is possible for a team member to receive conflicting instructions from their functional manager and their project manager. This requires building good interpersonal relationships with the team members and regular, effective communication.
A contract team is typically brought in from outside an organisation in order to perform the project work. Here, the responsibility to deliver the project rests very firmly with the project manager. Relationships between the contract team and the client are particularly important in this type of team. A variant of this is the so-called ‘outsourced supply team’, which simply means that the team is physically situated remotely from the project manager, who then encounters the additional problem of ‘managing at a distance’. These teams are becoming increasingly common in a globalised world. Although the concept is simple, time zone, culture and communication issues make this a challenging project to manage.
In reality, few teams are exactly as described in the previous section and they are usually some hybrid or mixture of these basic forms. For example, an operational team may be a permanent part of an organisation‘s structure – a top management team or a team running a helpdesk. Or the team may be temporary, such as a project team set up to introduce a new piece of software into an organisation. Some authors note that there is a spectrum of team organisation structures from functional through matrix and on to a project or single team structure. The different structures for project teams have different advantages and disadvantages so that one team structure may suit a particular task in some organisations better than another.
Table 1 sets out the strengths and weaknesses of different team structures. Note that in this table, we are defining a client to be a person or organisation that requested or receives the product of the team’s work.
Table 1 description.
The table has two columns. The headings are ‘Strengths’ and ‘Weaknesses’.
Under these headings there are three rows.
The first row is a ‘Functional team’. The strengths of a functional team are: handles routine work well; line management has control of projects; pools technical and professional expertise. The weaknesses of a functional team are: communication and coordination across functional areas in an organisation is more difficult; can be inflexible; tends to push decision making upwards.
The second row is a ‘Matrix team’. The strengths of a matrix team are: acceptable to traditional managers; top management retains control of projects but are relieved of day-to-day decisions; flexibility in the personnel assigned. The weaknesses are: project staff have dual reporting lines, which can cause conflicts of priorities; staff appraisal and performance measurement is difficult; the team leader may not be able to influence who is assigned to the project.
Finally, the third row describes a ‘Contract team’. The strengths of a contract team are: easy to employ technical and professional expertise; reduces training requirements for the client; the team can use its own management structure; can be used to bring a number of organisations together. The weaknesses of a contract team are: difficult for the client to assess the quality of the work and progress of the project; there may be problems on acceptance as the client is the judge of project success; difficult to identify and resolve political or organisational issues; communication between geographically remote team members is difficult.
Strengths | Weaknesses | |
---|---|---|
Functional team | Handles routine work well. Line management has control of projects. Pools technical and professional expertise. | Communication and coordination across functional areas in an organisation is more difficult. Can be inflexible. Tends to push decision making upwards. |
Matrix team | Acceptable to traditional managers. Top management retains control of projects but are relieved of day-to-day decisions. Flexibility in the personnel assigned. | Project staff have dual reporting lines, which can cause conflicts of priorities. Staff appraisal and performance measurement is difficult. The team leader may not be able to influence who is assigned to the project. |
Contract team | Easy to employ technical and professional expertise. Reduces training requirements for the client. The team can use its own management structure. Can be used to bring a number of organisations together. | Difficult for the client to assess the quality of the work and progress of the project. There may be problems on acceptance as the client is the judge of project success. Difficult to identify and resolve political or organisational issues. Communication between geographically remote team members is difficult. |
An operational team is formed to undertake some ongoing activities that are required for the provision of goods or services. For example, the counter service and telephone services operated by a bank are provided by operational teams that are supplying a service to the public, whereas an accounting department within a larger organisation is supplying a service to other parts of the organisation. The purpose of the operational team is usually specified in terms of the level of service or the quality of the goods supplied.
Operational teams usually have well-defined roles and responsibilities. While the idea of team roles is typically applied to project teams, an operational team also needs a variety of types of people to support the processes and progress of the team.
An operational team can be a virtual team. However, it is less common for an operational team to be fully virtual than some other types of team. It is more likely that some, if not all, operational team members will be collocated. If the team does operate from more than one location it will be split into sub-teams, each of which will be collocated. The needs of a virtual operational team are very similar to the needs of a virtual project team; in particular, they need some shared workspace that may be wholly or partly virtual.
In some circumstances, operational teams can work as project teams. For example, an accounts department provides an ongoing service to other parts of the organisation. When the organisation needs to produce end-of-year accounts this can be approached as a project. A schedule may be devised, with interim milestones building towards the goal of producing a set of accounts that are complete, accurate and on time.
The following list of tasks could be undertaken by an operational team or some form of project team. What form of organisation would be most appropriate for managing them? Briefly state the reason(s) for your choices.
Self-managed teams have been described as one of the more important approaches to improving team performance in recent years. Other teams with this style of team organisation are described as ‘self-directed teams’ and ‘semi-autonomous work groups’, which gives some sense of how a self-managed team manages itself.
A self-managed team is a team in which the members take collective responsibility for ensuring that the team operates effectively and meets its targets. Typically, members of self-managed teams are employees within an organisation who work together, within a broad framework of aims and objectives, to reach a common goal. When setting up the team, two of the parameters that have to be defined are the levels of responsibility and autonomy that are given to the self-managed team. So teams can have varying degrees of autonomy, from teams who have considerable control over their work, and the boundaries within which they operate, to self-managed teams that are set boundaries by team leaders. (Some authors give different names to teams at different ends of this spectrum. In this course we use the same term.)
In general, self-managed teams have considerable discretion over:
The leadership role in a self-managed team is very different from that of a team leader in a traditional hierarchical team such as a functional team. In a hierarchical team the team leader allocates work. In contrast, in a self-managed team, the leadership role involves taking on more of a supporting role, which includes identifying the long-term career and personal development needs of the team within the context of the overall organisation. Table 2 compares the roles of a team leader in these two types of team.
Table 2 description
The table has two columns. The first column has a heading of ‘The team leadership roles in a hierarchical team and the second column, a heading of ‘The team leadership role in a self-managed team.
Under these headings there are six rows.
The first row states that the team leadership role is vested in one individual in a hierarchical team and the role may be shared in a self-managed team.
The second row states that the team leader’s role is to manage the team in a hierarchical team, whereas it is to support the team by providing (or arranging others to provide) coaching and advice in a self-managed team.
The third row states that the team leader’s role in a hierarchical team is to plan and allocate the work done by the team and in a self-managed team, it is to agree, in discussion with the team, the standard of work and the aims, objectives and targets of the team.
The fourth row states that in a hierarchical team the team leaders should monitor and appraise the performance of team members in carrying out the tasks allocated to them. In contrast, in a self-managed team the team leader’s role is to monitor the achievement of the team as a unit and to appraise individual performance.
The fifth row states that the team leader’s role in a hierarchical team is to motivate the team members, whereas in a self-managed team it is to provide the conditions for high motivation.
Finally, the sixth row states that the role of a team leader in a hierarchical team is to act as the main contact point for communication between the team and the rest of the organisation and in a self-directed team it is to facilitate the creation of channels of communication with the rest of the organisation.
The team leadership role in a: | |
---|---|
Hierarchical team | Self-managed team |
The role is vested in one individual. | The role may be shared. |
To manage the team. | To support the team by providing (or arranging others to provide) coaching and advice. |
To plan and allocate the work done by the team. | To agree, in discussion with the team, the standard of work and the aims, objectives and targets of the team. |
To monitor and appraise the performance of team members in carrying out the tasks allocated to them. | To monitor the achievement of the team as a unit. To appraise individual performance. |
To motivate the team members. | To provide the conditions for high motivation. |
To act as the main contact point for communication between the team and the rest of the organisation. | To facilitate the creation of channels of communication with the rest of the organisation. |
Individual team members may have the opportunity to use their skills and experience outside their specified remit (or job title) within an organisation. Since team roles within self-managed teams are much more fluid than in hierarchical teams, team members may have increased discretion over their work, which can lead to greater motivation and improved performance. Team members may also have greater freedom to complement each other’s skills. Finally, team leaders can act more strategically, resulting in fewer surprises and purposeful team development, since they are freed from some of the management tasks required of team leaders in hierarchical teams.
The benefits of self-managed teams include (based on Howell, 2001):
For all their potential benefits, successful self-managed teams are not without their problems. They can be difficult to set up, particularly if there is not a culture of using self-managed teams in an organisation. For example, the team may find it difficult to interact with other parts of the organisation because of their different working practices. Individuals new to self-managed teams may be anxious if they perceive that they may be given extra responsibility. Conversely, team leaders may feel that their role is threatened by having some responsibility taken away from them. Everyone may need additional training to give them the extra skills that they may require in their new team. There can be more redundant communication in self-managed teams because there is often no clear structure for communication, obtaining guidance or making decisions. Consequently, guidance may be sought from the entire team and decisions will be made by discussion, rather than by reference to a team leader who is empowered to make decisions, as would be the norm in a project or operational team. The team leader must provide an initial structure until the team has established its rules and norms. Finally, an ever-present problem with teams is that of ‘freeloaders’. If a member of a team does not meet their responsibilities this will impact upon the work of the other team members, and hence the productivity of the team as a whole.
Planning, preparation, ongoing communication and follow-up are all necessary for a transition towards self-managed team working. For a self-managed team to remain successful, its members must be tolerant of errors and allow for learning, and there must be trust both within the teams and between the team members and team leader. This will allow risks to be taken and information to be shared, and will foster a willingness to accept change.
Communities of practice are not a new phenomenon, but they have become much more popular in recent years as a means of supporting people in improving their performance. A community of practice can be formed by people who engage in a process of collective learning through their shared experiences and practices. For example, a group of engineers working on similar problems, a network of surgeons exploring novel techniques, or a gathering of first-time managers helping each other cope could all be examples of a community of practice. The concept has been popularised, particularly in the educational context, by Etienne Wenger, who provides the following definition.
Communities of practice are groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly.
Wenger identifies three characteristics of a group that are crucial to it being a community of practice. These are:
The domain: A community of practice is not merely a club of friends or a network of connections between people. It has an identity defined by a shared domain of interest. Membership therefore implies a commitment to the domain, and a shared competence that distinguishes members from other people. The domain is not necessarily something recognised as ‘expertise’ outside the community.
The community: In pursuing their interest in their domain, members engage in joint activities and discussions, help each other, and share information. They build relationships that enable them to learn from each other. A website in itself is not a community of practice. Having the same job or the same title does not make for a community of practice unless members interact and learn together. The claims processors in a large insurance company or students in American high schools may have much in common, yet unless they interact and learn together, they do not form a community of practice. But members of a community of practice do not necessarily work together on a daily basis. The Impressionists, for instance, used to meet in cafés and studios to discuss the style of painting they were inventing together. These interactions were essential to making them a community of practice even though they often painted alone.
The practice: A community of practice is not merely a community of interest – people who like certain kinds of movies, for instance. Members of a community of practice are practitioners. They develop a shared repertoire of resources: experiences, stories, tools, ways of addressing recurring problems – in short, a shared practice. This takes time and sustained interaction. A good conversation with a stranger on an airplane may give you all sorts of interesting insights, but it does not in itself make for a community of practice. The development of a shared practice may be more or less self-conscious. The ‘windshield wipers’ engineers at an auto manufacturer make a concerted effort to collect and document the tricks and lessons they have learnt into a knowledge base. By contrast, nurses who meet regularly for lunch in a hospital cafeteria may not realise that their lunch discussions are one of their main sources of knowledge about how to care for patients. Still, in the course of all these conversations, they have developed a set of stories and cases that have become a shared repertoire for their practice.
Every community of practice must have all three elements: a domain, a community and a practice. But they come in a variety of shapes and sizes, from small to very large, from local to global, from meeting face-to-face to meeting only online. Some exist only within one organisation, whereas others span several organisations. Some, such as professional societies, are formally constituted, whereas others are very informal.
Given the above description of communities of practice, identify those communities of practice to which you belong.
Depending on your background and experience, you might be part of, or have had contact with, a variety of communities of practice – at home, at work, or socially. Here we discuss a number of examples, based on the discussion in Wenger (2009).
Business organisations have been quick to adopt the communities of practice concept because they recognise that organisational knowledge is a critical asset that needs to be managed strategically. Prior attempts to manage knowledge in organisations have often focused on technical solutions based on information systems. Communities of practice provide an approach to capturing, disseminating and developing organisational knowledge which is people-focused rather than technology-focused. However, communities of practice can be perceived as a threat to traditional, hierarchically structured organisations because they are not constrained by formal structures: people within a community of practice can create links between people that span organisational and geographic boundaries.
In the same way that businesses face knowledge management challenges, so do local and national governments. Communities of practice provide a mechanism for enabling connections between people across formal structures and facilitating more open knowledge sharing.
Professional societies and similar associations are making increasing use of the concepts of reflection and reflective practice as a way of developing more professional and responsible practitioners. In addition to more traditional courses and publications for Continuing Professional Development (CPD), communities of practice offer less formal opportunities for peer-to-peer learning.
Many people are involved in communities of practice through their hobbies and interests; allotment holders, for example. The domain is gardening; the community is made up of those people who rent an allotment at each site, and the practice involves becoming better gardeners or allotment holders. Through meetings, shows and other events, seeds, plants and information are exchanged.
There is a community of practice within The Open University for ‘e-learning’, which is a voluntary grouping of staff interested in developing their understanding and use of e-learning for pedagogical uses. It provides opportunities for interaction through seminars and other gatherings, and produces a regular update of activities and objects related to e-learning. So there’s a domain, a community and practice.
Arguably, the internet, and particularly Web 2.0, have allowed communities of practice to flourish. As this course demonstrates, electronic communication technologies have extended our reach beyond the limitations imposed by geography, making it possible to interact and form communities with people across the world.
The concept of community of practice is influencing theory and practice in many domains. From humble beginnings in apprenticeship studies, the concept was seized by businesses interested in knowledge management and has progressively found its way into other sectors. It has now become the foundation of a perspective on knowledge and learning that informs efforts to create learning systems in various sectors and at various levels of geographical scale, from local communities to single organisations, partnerships, cities, regions and the entire world.
This section has dealt with four specific types of team: project teams, operational teams, self-managed teams and communities of practice. It was acknowledged that, in practice, real teams tend to cross the boundaries between these types of team.
A project team consists of a group of people who come together as a distinct organisational unit in order to work on one or more projects. The team is often led by a project manager, although project teams may also be self-managed. There are several commonly accepted types of project team: the functional team, the project team, the matrix team and the contract team. A functional team is a team in which work is carried out within a functionally organised group where people working together carry out the same or similar functions. A project team consists of a group of people who all belong to the same organisation but work as a separate unit on one or more projects. In a matrix team, individual staff report to different managers for different aspects of their work. Staff are responsible to the project manager for their work on the project while their functional line manager is responsible for other aspects of their work. A contract team is typically brought in from outside an organisation in order to perform the project work.
The strengths and weaknesses of the different categories of project teams were discussed.
An operational team is formed to undertake some ongoing activities that are required for the provision of goods or services.
A self-managed team is a team in which the members take collective responsibility for ensuring that the team operates effectively and meets its targets. The benefits of a self-managed team include cost savings, innovation, effective decision making, increased productivity, improved customer satisfaction, commitment, motivation and increased compatibility between employers and employees. However, there are potential problems: they can be difficult to set up, particularly if there is not a culture of using self-managed teams in an organisation, and there is the perennial problem of individuals not contributing fully (meeting their responsibilities).
A community of practice is a group of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly. To be a community of practice, the group must consist of practitioners in a domain who engage in joint activities and discussions to help each other and share information.
Several ways of characterising or classifying virtual teams have been proposed in the literature. One of the most popular was elaborated by Fisher and Fisher (2001), who argued that virtual teams typically can be characterised by three variables, or dimensions. These variables are time, space and culture, although other authors also refer to the third variable as organisation. Thinking about these three variables as dimensions enables us to draw the diagram shown in Figure 2.
Figure 2 description
The centre of the figure contains a cube. Each face of the cube is divided into four squares. The left-hand vertical edge of the front face is labelled ‘Time’ and the bottom horizontal edge is labelled ‘Space’. These two edges represent axes and are each divided into two sections labelled ‘different’ and ‘same’. Thus, the top left-hand square on the face of the cube represents ‘different time and same space’ and the bottom right-hand square represents ‘same time and different space’.
The right-hand face of the cube represents the dimension of ‘Culture’, and this is also divided into two sections labelled ‘same’ and ‘different’.
Hence, the cube consists of eight small cubes, each one representing one value (same or different) of each of the three dimensions, ‘Time’, ‘Space’ and ‘Culture’.
Understanding these three variables is useful in determining what kind of virtual team you might be involved in and in helping you decide on appropriate actions to improve them. For example, a team that has members working in the same place at different times (such as an operational team providing telephone services in a bank) might be able to meet some of their communication needs using noticeboards in their shared office space, but a team that is distributed across multiple sites or time zones would need a different communication strategy.
Time refers to when people work. Virtual team members may be assigned to work different hours, on different shifts or on different days. They may work at the same time, but be in different time zones, so the time when their working day overlaps with other team members is short.
Space (or place) refers to where people work. Virtual team workers may work close to one another or at a distance. They may share the same office or work in different places in the same building. They may work in different buildings, in different towns, or even in different countries.
Culture (or organisation) refers to who people work for and how people work together. Aspects of culture include language, race, nationality, profession, education and gender, as well as religious, political, social and economic factors.
In Figure 1, the continuum is divided into just eight boxes, to represent eight types of team, depending upon whether the time, space or culture variable is the same or different. So, for example, in the bottom left corner of the diagram you would place teams that work at the same time, in the same place, for the same organisation. In contrast, at the top right corner of the diagram are teams whose members work at different times, in different places, for different organisations.
Two of these boxes – the same time, same space, same organisation teams that we have already discussed, and the one behind it in Figure 1 (same time, same space, different organisation teams) – are not virtual teams according to Fisher and Fisher (2001). You may disagree with this viewpoint, but a team consisting of people working for different organisations (or cultures) but who work at the same place and at the same time may not need technology to mediate their interactions, although they may prefer to operate virtually. They should be able to meet in the same room even if they need interpreters or other intermediaries to facilitate their interactions.
To help you think about the different types of team and the implications of the three variables for teams of different types, we have partially completed Table 3 with examples of virtual teams and the potential challenges that are implicit in these variables. We have put an example team and a team challenge in each row, but some examples and challenges can be placed in more than one row. Identify them. There are other examples and challenges that do not appear in the table. Identify some of them.
Table 3 description
The table has six columns. The headings are Type (of virtual team), Time, Space, Culture, Example, Challenges.
Beneath these headings are eight rows.
The first row has a type of 1, the time is different, the space is the same and the culture is different. The example is customer service team and the challenges are interaction between organisations or cultures.
The second row has a type of 2, time, space and culture are all different. The example is a global team and the challenges have been left for you to fill in.
The third row has a type of 3, time is the same but space and culture are different. The example is regional services and the challenges are again left blank.
The fourth row has a type of 4, the time is different, the space and culture are the same. The example given is of a warehouse team and the challenges are interaction between shifts.
The fifth row has a type of 5, the time and space are different and the culture is the same. The example is a multinational organisation and the challenge has been left blank for you to fill in.
The sixth row has a type of 6, the time is the same, the space is different and the culture is the same. The example is OU regional centres and the challenge is interaction at a distance.
The seventh row has a type of 7, the time, space and culture are all the same, the example is a project team and the challenge is a note that this is not a virtual team.
The eighth row has a type of 8, the time and space are the same and the culture is different. The example is a contract team and the challenge is again a note that this is not a virtual team.
Type | Time | Space | Culture | Example | Challenges |
---|---|---|---|---|---|
1 | Different | Same | Different | Customer service team | Interaction between organisations or cultures |
2 | Different | Different | Different | Global team | |
3 | Same | Different | Different | Regional services | |
4 | Different | Same | Same | Warehouse team | Interaction between shifts |
5 | Different | Different | Same | Multinational organisation | |
6 | Same | Different | Same | OU Regional Centres | Interaction at a distance |
7 | Same | Same | Same | Project team | Not a virtual team |
8 | Same | Same | Different | Contract team | Not a virtual team |
Type 1 and Type 4 teams differ in whether or not team members come from the same (Type 4) or different (Type 1) organisations or cultures. Both types of team are typical of customer service, manufacturing or warehouse teams that have multiple shifts of people using the same space to provide the same service or function, but working at different times. In practice, these two types of team can use non-technical means to communicate with each other, such as leaving notes or writing on shared noticeboards. Many teams in this situation use overlapping shifts to provide face-to-face meetings and facilitate shift handovers.
A typical Type 2 team could be an international product development team, a multinational organisation or a global project team. Again, Type 2 teams are similar to Type 5 teams, differing only in whether team members work for the same organisation or have similar cultural backgrounds. In a world that is becoming increasingly globalised, teams of this type are becoming increasingly common. For example, in order to speed product development and reduce time to market, teams are being formed with members that are located in countries distributed roughly eight hours apart around the globe. At the end of the working day in one location, the work in progress is handed on to team members who are just beginning their working day, eight or so hours behind them. Teams of these types are the most difficult to manage and work in because they cross time and space, and potentially organisation. Team members must become proficient in using asynchronous technologies such as email or shared workspaces. Since times when synchronous communication by audio or video conferencing can take place will be limited, such meetings that do take place by these means must be used very efficiently.
Many virtual teams are of Types 3 or 5, consisting of people who work at different locations but for the same (Type 5) or different (Type 3) organisations. These could be regional sales teams or teams providing other regional services. Such teams have the benefit of working at the same time so they can work remotely, in real time, using synchronous technologies. Face-to-face interaction is difficult since the team members are normally working at different locations, so they will have to travel to meet in the same place.
Finally, Type 7 and Type 8 teams are included in the table for completeness. These are not virtual teams. From your own or others’ experiences, you might like to add further examples, or note down team challenges typical of conventional teams.
Taking some examples from my own experience: I work with colleagues at the Open University, based both at Walton Hall and the Regional Centres, on a variety of projects in different teams. These are examples of Type 5 teams when they involve colleagues from centres other than the one where I work. If everyone is based at the same location then they should really consider themselves to be a Type 7 team – same time, same space (or place), same organisation – but email is so pervasive that people can use that rather than the telephone or a quick face-to-face conversation.
I also work on a research project with colleagues at the Natural History Museum, London. This is an example of a Type 3 team since we work for different organisations, at a distance, but in the same time zone. On another research project, colleagues in Japan are involved, so this is an example of a Type 2 team. Time zone differences make it difficult to schedule audio or video conferences, but we have used it to our advantage when trying to meet deadlines. I can write a draft of a paper, circulate it to the team by the end of my working day and receive comments on the draft from my Japanese colleagues in time for the beginning of my next working day. It is exhausting, since you don’t get a break from working on the paper, but the work is finished quickly!
Virtual teams can be characterised by the three variables, or dimensions, of time, space and culture, although the third variable is sometimes referred to as organisation. This classification enabled six types of virtual team to be identified (two of the classes in the classification are not strictly virtual). The classification can be used to identify different types of virtual team and to help you decide on appropriate actions to take to improve them.
How do teams form? Are there any common patterns in the way in which they develop? It turns out that there are. In this section we shall discuss one of the more widely known models of team formation and development – Tuckman’s model (after the person who described it). This model is also frequently referred to by the stages of team development that it identifies: forming, storming, norming, performing and adjourning.
Teams often come together in order to carry out a project or undertake a task that is too large, complex, or would take too long for one person to complete. While the team may be involved in producing a finished product or an end result, it can also be thought of as being engaged in a process that has a beginning, a middle and usually an end. The team is formed at the beginning of the project, it carries out the project, and at the end of the project it may or may not be disbanded. Teams rarely come into being fully fledged; they usually have to proceed through a number of stages of development before they function well together as a team.
These developmental stages can take some time to pass through before a group of disparate individuals begins to operate effectively together as a team. Unfortunately, time is something that many teams don’t have. They may have tight delivery deadlines imposed upon them, leaving little spare time for preliminary ‘ice-breaking’ activities to help team members to get to know one another during the initial stages of team development. In virtual teams, this lack of time is particularly unfortunate since it has been found that such teams often take longer to develop than teams that are collocated or can meet face-to-face (Lipnack and Stamps, 2000). One of the reasons for this is to do with the nature of the communication mechanisms used (electronic communication rather than face-to-face meetings, often using email instead of telephone calls or video conferencing). All teams can take a long time to develop if team members are juggling participation in the team with their normal duties and other competing priorities, rather than being assigned to a team as a full-time member. This situation, where team membership is part time, often occurs in virtual teams.
Many teams appear to develop in the same way and to follow a predictable pattern of formation and growth (their life cycle). As a member of a team, if you know what the pattern is and can recognise the features of the developmental process in your own team, then you are in a strong position to be able to do something about it – if indeed you need to. First, you can understand what is going on – the growing pains of your team; second, you can take appropriate action to help your team to move on to the next stage of growth; and third, you can try to avoid doing anything inappropriate to upset the development of your team!
In 1965 Tuckman published a paper in which he identified and characterised four stages of team development (Tuckman, 1965). Later on, Tuckman and other authors added a fifth stage to the end of the team development life cycle (Tuckman and Jensen, 1977). Tuckman’s model formalises the process of team development and gives names to the different developmental stages. These stages have been given other names by other authors but they are widely recognised as being ones through which many teams pass. In the remainder of this section, Tuckman’s model of the development of teams is described. Furthermore, we have included some advice for virtual teams to consider at each of the five stages.
In the first stage of team development, team members meet (either in person or electronically) and begin to get to know each other. Often, team members will begin to establish the ground rules for how the team is to operate and how they will work on the task that the team has been assigned. It is tempting to skip or rush this stage in team development because it does not appear to contribute directly to the project outcomes. However, you should recall that this ‘forming’ stage is an important part of the team development process without which effective communication is unlikely to be possible within the time available to the project.
As its name suggests, this stage in team formation can be characterised by spirited discussions and even arguments amongst the team members. While the storming stage can be difficult, it is sometimes the case that intense discussion during this phase of team development leads to more productive working later on in the project. In other words, the team has worked out its differences early on and has developed mechanisms for managing discussions and arriving at satisfactory conclusions when disagreements occur.
When teams are over the storming stage they often breathe a collective sigh of relief, since the team has begun the transition from a group of individuals to becoming members of a cohesive team. A team identity has established itself and disagreements between team members are largely settled.
Having completed or passed through the previous three stages, the team will be working productively together. They will be getting on with the task, producing results, and there will be good working relationships within the team.
This, the final stage of team development, is sometimes called ‘mourning’. While it was not in Tuckman’s original (1965) proposal, it is widely recognised as being an important stage in the life cycle of a team, as team members anticipate the project coming to an end and the team being disbanded.
Generally, significant progress on a team’s tasks does not occur until the norming stage. This is captured in Figure 3, which shows how team performance (in terms of progress towards the final goal, plotted on the vertical axis) varies according to the stage of development of the team (plotted on the horizontal axis in terms of time). The graph is intended to give you only an impression of how teams perform so it should not be interpreted too literally. In particular, teams do not spend an equal length of time at each stage of development. In some teams, team performance may even drop during the storming stage as the team undergoes the sometimes painful transition from being a group of collaborating individuals and becomes a team (Becker, 2003).
Figure 3 description
The figure is a graph of team performance, plotted vertically, against time, plotted horizontally. As time increases from left to right, the graph starts off near the origin, stays at a low level, begins to rise rapidly and then slows down, becoming horizontal again. The area beneath the graph is divided into vertical sections of roughly equal width. The portions of the graph indicated by these areas are labelled (reading from left to right) ‘Forming’, ‘Storming’, ‘Norming’, ‘Performing’ and ‘Adjourning’.
It is instructive to compare this view of the development in team performance over time, as a team progresses through the different stages of team development, with the formation of high-performing teams proposed by Katzenbach and Smith (1993). These authors suggest that team effectiveness increases as teams move through phases of team development, from a working group to a high-performance team as illustrated in Figure 4. When comparing Figures 3 and 4, you should note that Figure 3 shows the development of team performance over time, whereas Figure 4 show the development in a team’s performance in terms of their effectiveness.
Figure 4 description.
Figure 4 is a graph. The horizontal axis along the bottom of the figure is labelled ‘Team effectiveness’ and the vertical axis on the left is labelled ‘Performance impact’. The graph is a single curved line which begins on the left-hand side about half-way up the vertical axis. The curve increases briefly and at the maximum there is a label ‘Working group’. The curve declines to a minimum one-third of the way across the horizontal axis where it is labelled ‘Pseudo team’. The curve then rises in the middle third of the axis and almost reaches the top of the figure, and approximately half-way up is labelled ‘Potential’. In the final third, the curve begins to flatten out and is labelled ‘Real team’. Finally, the curve is horizontal and is shown dotted; this part is labelled ‘High-performing team’.
Tuckman’s model of team development has a number of other implications and consequences of which it is useful to be aware:
From the above discussion it would be very easy to think that there is a need to manage the process of team formation by actively intervening if the team does not appear to be moving on to the next stage of development. Often, a more task-oriented approach, of letting the team evolve by focusing attention and energy on the team task, is more effective. It has even been found that teams that devote excessive attention to their own development are less productive and enjoyable to work in than those that do not. Therefore, the skill in facilitating team development is to know when, how, and if at all, to intervene in building the team.
Briefly describe each stage of Tuckman’s model of team development.
The five stages are: forming, storming, norming, performing and adjourning. In the first stage, forming, team members primarily get to know one another and do little towards meeting the goals of the project. This stage can be thought of as socialisation. In the second stage, storming, spirited discussions and arguments amongst the team members occur, but these lead to the team developing mechanisms for managing discussions and arriving at satisfactory conclusions when disagreements occur. Some significant progress towards the team goals can occur in this stage. However, most progress occurs in the third stage, norming. In the norming stage the team members transition from a group of individuals to becoming members of a cohesive team. In the fourth stage, performing, the team will be getting on with the task, producing results, and there will be good working relationships within the team. The final stage, adjourning, is where the team has completed the tasks and disbands.
In this section we have given some advice and guidance on how virtual teams develop based on Tuckman’s model of team development. Understanding the stages by which teams develop can help stop a team from overreacting to normal problems that arise in teams as members learn to work together, to cooperate and collaborate in completing the task that they have been set. But in common with other situations in which you are working with people, patience is essential.
The three different types of role that people can play in the team – technical, functional and team roles. The first type of role someone plays in the team is that of undertaking the team task; in other words, working on the task that the team has been assigned is known as their technical role. The second type of role consists of the tasks that are required to make the individual members of the team function effectively as a team (a functional role). In this section we shall turn our attention to a person’s functional role in a team. The third type of role that a person can play in the team, a person’s team role.
Working on the process of team organisation and management often appears to be of secondary importance when compared with that of working on the task and meeting deadlines. However, ensuring that team members work constructively together will prevent the team from drifting aimlessly, sometimes acrimoniously, without getting much goal-oriented work done.
Some of these process-related tasks are best defined and carried out by team members having particular roles. In the remainder of this section we will describe these roles, and give recommendations as to how these roles can be allocated and which roles you should have in your team.
Teams needs to agree on who is going to carry out which role (role allocation). This need not be fixed for the lifetime of the team, particularly in operational teams. You could, for example, rotate the roles so that everyone takes a turn and thus gains experience of the different roles (as in some forms of democratic team). Or you may want to allocate the crucial roles within the team to the people who would like to take them, are best qualified to carry them out through prior or current experience, or even to people who would like to take on an unfamiliar role in order to gain experience of performing that role.
Whatever protocols you use for allocating roles within your team, you should make sure that someone performs these roles or, if the roles are not allocated explicitly, that someone in the team undertakes the tasks.
Even where decisions may be taken by the whole team, someone has to take responsibility for chairing meetings, or their virtual equivalent. In a meeting, this person has responsibility for clarifying the aims of the meeting and its agenda. They should introduce each item on the agenda, guide the discussion of the items and then summarise the discussion and decisions taken. If the team leader has a strong leadership role they will also have a key role to play in decision making, partitioning of tasks and allocation of activities.
A team needs someone who takes notes in meetings: a team secretary or record keeper. One of their duties is to keep a record of what decisions have been taken, who is doing what, and the date of the next meeting. A summary of the meeting, in the form of meeting minutes, will normally be circulated to the rest of the team by the record keeper. Therefore, the minutes of the meeting can be seen as the official record of the meeting and can be referred to if decisions are revisited or are in doubt. In the virtual team setting, the easiest way to emulate this decision-making function of the meeting is to set a deadline by which an issue must have been debated and a decision made, by voting if necessary. The team leader can facilitate this process, with the record keeper recording the decision that is made.
In some operational and project teams, keeping records of issues (or bugs in computer software) is a significant record-keeping task. Special ‘issue tracking’ software has been developed that is often used by helpdesk teams or those working in customer support departments to manage records of issues reported by customers and their resolution. Project teams engaged in software development might well use a related type of software – bug-tracking software – to help manage records of errors found, and the steps taken to resolve them, in the software they are developing.
In project teams, the record keeper may coordinate the production of team documents and reports through managing the different versions of the documents that the team produces. Or this role could fall to the team leader. If production of documents is a large task or requires knowledge skills that are held by those with technical roles other than record keeper, then the role of document controller is needed. While many projects do not have documents as their end-products (projects in the construction industry and many information technology projects, for example), most teams will have to produce periodic reports on their activities.
A team needs someone who is responsible for ensuring that the team is keeping to the schedule that the team members have set themselves and ensuring that they will meet the external deadlines that have been given to them. Such a person should monitor progress, ensuring that everyone is doing what they are supposed to and that all the tasks that need to be completed by a particular date are on schedule before the deadline and have been completed once the deadline has passed.
In a small team this may be undertaken by the team leader. In a large team the role of progress chaser may be supported by a timekeeper who monitors how much time is spent on each item in team meetings. In synchronous meetings it is easy to spend too much time on the first few items of a long agenda, leaving too little time to discuss the later items. A timed agenda allots time to each item. In asynchronous collaboration a similar function may be needed, although usually an end-time is set for each asynchronous discussion. In this case the timekeeper may need to allocate periods for discussion and ensure that these are coordinated with the milestones of the project.
In this section we have discussed the different functional team roles that team members can take on. In a small team, you may not need all of these roles all of the time, and the same person may fill more than one team role. However, the four functional team roles described above – of team leader, record keeper, progress chaser and document controller – are four roles that commonly are fulfilled by team members.
A theme within this course is the development of skills and techniques that are useful to team members as individuals, as team leaders and as team managers. Many of these skills are useful in other contexts, and you may have studied them as part of management or other professional development courses. In this section we consider two aspects of working in successful teams – decision making and trust – and how these can be more complicated in a virtual environment. By way of motivation, in Coar’s (2003) article ‘The sun never sets on distributed development’, he notes that one of the consequences of relying on email or other asynchronous communication media is the difficulty of coming to conclusions or reaching a consensus.
Revisit a recent decision you, or a team you are working in, has made. Look back on it as though you were once again in the position of having to make the decision. Write down some brief answers to the following questions.
While the answers to these questions will depend on the example that you chose, it is common to look back and recognise where there was insufficient or incomplete information at the time a decision was made. If this was not the case perhaps explicit steps were taken to ensure appropriate information was available.
Electronic communication can add an additional level of complexity to decision making. To ensure that all steps are complete in a virtual environment it is necessary to:
In an environment where the outcome of a decision must be made by a group of people, or even where it must be made by one person but affects others, it is important to prepare before reaching a decision. The following list sets out steps that should reasonably be taken before making a considered decision.
Figure 5 description
The figure shows a large arrow pointing from left to right with the arrow pointing towards text that says ‘Behind schedule’. Above the arrow is a branch that is attached to the arrow. This branch has a label that says ‘Unclear what tasks were’. Coming off this branch is a sub-branch with a label that says ‘Didn’t plan tasks well’, which in turn has a sub-sub-branch that has the label ‘Didn’t break down goals to tasks’. Below the arrow are two branches; the one to the left has a label that says ‘Key component ordered late’. This branch has a sub-branch with the label ‘No one told Purchasing of deadline!’ The right-hand branch below the arrow has a label that says ‘2 team members absent at key time’. This branch has a sub-branch with a label that says ‘illness’.
Making a decision can be, and often is, difficult, particularly if it involves reaching some accommodation or agreement with others, as it does in working in a team. There follows four decision-making models to reach a decision when a group of people is involved. However, first the group has to decide which model to follow.
The autocratic form of decision making applies where one person, usually the team leader or team manager, has the formal authority to take a decision to which others will be bound, or else one person has the personal charisma or personal authority – delegated to him or her by the others – to make decisions on the group’s behalf. The drawback, particularly when a decision is taken without consultation, is that some or all of the group can be alienated.
Majority rule doesn’t mean that everyone agrees, but the decision is based on a majority vote. The drawback of this model is that it is possible to become deadlocked if there is no majority: half for and half against. Should that occur, there needs to be some mechanism for breaking the deadlock.
This occurs where there is agreement for majority rules but the minority feels strongly enough about their side of the argument to wish to make known their disagreement. To do this, the minority writes what is known as a dissenting opinion: it states what a different outcome could be and the arguments as to why that outcome gained their support. In a team, if a minority feels sufficiently strongly about their view, allowing the minority to prepare a short report for inclusion with the main decision of their views and reasoning can be useful for group cohesion, and may also prove valuable should the group need to revisit the decision in the future.
The term consensus describes the quality or condition of being in complete agreement or harmony. In any group of more than a few, reaching a consensus requires a number of conditions or actions:
A chairperson is required to manage discussions, whether face-to-face or electronic. The chairperson needs to:
These points apply as much to online discussions using email and conferencing software as they do to face-to-face sessions amongst participants.
Describe the four models for decision making. Rank them in order of most inclusive decision making to least inclusive.
The four models are:
Consensus: A discussion is held, with a chair to ensure that all participants’ views are heard. Areas of common agreement are found and the discussion moves towards a common view which can be accepted by all. Only that which is agreed upon is communicated as a decision.
Majority rule with minority opinion: A vote is taken and the decision is that voted for by the larger number of participants. Those who do not agree can express their disagreement and give an alternative view.
Majority rule: A vote is taken and the decision is that voted for by the larger number of participants.
Autocratic: The decision is taken by the team leader or manager on the basis of their formal authority or by the person nominated by the rest of the participants.
These are listed from most inclusive to least inclusive, except that if the ‘autocratic’ decision is taken by one person nominated by the rest of the team then this is more inclusive than if taken on the basis of formal authority.
Trust between team members is an important ingredient for effective and efficient team working. But what is trust? According to Gignac (2005), trust is:
… a willingness to increase your vulnerability to another person whose behaviour you cannot control, in a situation in which your potential benefit is much less than your potential loss if the other person abuses your vulnerability.
Put another way, trust can exist when the members of the team are working in good faith, honouring their explicit and implicit commitments honestly, without taking advantage of other members of the team.
The benefits to a team if its members trust each other have been put succinctly by Fleming (2006), who claimed that trust was vital for any team to be successful. If team members trust each other, this can help to develop cooperation and collaboration between team members through the sharing of knowledge and experience. Trust between team members can also encourage them to be open and honest with each other. In the team context, it can promote new ideas and risk taking.
Conversely, mistrust within the team is burdensome because it leads to increased formality of procedures in order to reduce team members’ vulnerability to each other. If there is a lack of trust within the team, effort can be duplicated because team members do not trust each other to deliver on their promises. This can lead to increased checking up on members of the team and increases in their workload at the expense of the overall productivity of the team. Team members’ actions and interactions within the team can also become diverted into unproductive political activity, further lowering productivity within the team. Finally, negotiations within the team and with the client can become protracted. All in all, teams that don’t trust each other are uncomfortable environments in which to work.
Building trust in virtual teams is not easy, and maintaining trust and group cohesion can also be difficult if it is done purely at a distance.
In a seminal paper on the subject of trust in global virtual teams, written by Jarvenpaa and Leidner (1999), they quote a paper by Nohiria and Eccles (1992), who argue that ‘face-to-face encounters are considered irreplaceable for both building trust and repairing shattered trust’. In contrast, Lipnack and Stamps (2000) are more upbeat on the possibility of building trust online, preferring to consider that trust can be built more quickly face-to-face than at a distance.
This leads to the concept of swift trust, which refers to the way that virtual teams can work together fairly quickly once they are able to develop trust between team members. Swift trust is important because virtual teams are often put together for short-term task working before being disbanded and re-formed with different team members for another task. The ‘crisis’ element of the work means that there may be little time available to achieve the objectives set.
Not surprisingly, if group members have worked together before this helps to establish swift trust. Cooperation and trust can also be improved if members make a tangible contribution early on, such as a fast response to messages or the prompt completion of a task.
In this section we have explored two skills that are useful when working in a team: making decisions and trust. In the former, we have described one approach to making a decision and given four different models for making team decisions. We have also shown how decision making can become a more time-consuming, protracted and challenging process when working virtually. In the latter, we have given a definition of trust, described some of the benefits of working in a team where members trust each other and the drawbacks of working in a team where there is a high level of mistrust. We concluded the section with a brief discussion of the concept of swift trust.
Choosing the communication technologies that you are going to use is important to the effective progress towards team goals, but so is deciding upon how you are going to use them, so that you can communicate and collaborate effectively with other team members. Some of the issues that can arise include the following.
Some virtual teams have found that it was beneficial to structure their work to fit the team members’ location and collaboration technologies that were available to them. However, virtual teams may find that the current generation of communication and collaboration technologies are neither sufficiently flexible nor of high enough quality to adapt to their requirements. Here, the team has to adapt its working practices to suit the working environment.
How are you going to adapt your own working practices? Or, more to the point, what working practices – team rules and norms – are you going to adopt in order to facilitate productive, collaborative working? Examples of rules that your team could consider are as follows.
Working at a distance is very different from working physically collocated. You will have to rely on electronic means of communicating with the rest of the team: asynchronously, for example via messages posted to a forum, or synchronously using instant messaging, conference calls or other media. Scheduling your team activities may require patience as you work around your own and other team members’ time constraints, and wait for them to complete the activities that the team has assigned to them or post their responses to team discussions in an asynchronous forum. However, as shown by a survey of successful virtual teams (Majchrzak et al., 2004), one of the key factors for success is frequent communication. The communication media that you choose to use do not have to be technically sophisticated – your team just has to use them frequently.
Grateful acknowledgement is made to the following sources:
Course image: Foxcroft Academy in Flickr made available under Creative Commons Attribution 2.0 Licence.
Figure 2: © Kimble, C., Alexis, B. and Li, B. (2000) Effective Virtual Teams through Communities of Practice, Strathclyde Business School Management Science Working Paper No. 2000/9, Strathclyde Business School, Department of Management Science.
Figure 3: © Lipnack, J. and Stamps, J. (2000) Virtual Teams: Reaching Across Space, Time, and Organizations with Technology, 2nd edn, New York, John Wiley and Sons.
Figure 4: © Katzenbach, J.R. and Smith, D.K. (1993) The Wisdom of Teams: Creating the High Performance Organization, London, McGraw-Hill.
Table 1: © The Open University (2008) M865 Project Management, Unit 1 Project initiation, Figure 5.1, Milton Keynes, The Open University.
Table 3: © Fisher, K. and Fisher, M.D. (2001) The Distance Manager: A Hands-on Guide to Managing Off-site Employees and Virtual Teams, New York, McGraw-Hill.
iStock
Don't miss out:
If reading this text has inspired you to learn more, you may be interested in joining the millions of people who discover our free learning resources and qualifications by visiting The Open University - www.open.edu/ openlearn/ free-courses
Copyright © 2016 The Open University