Skip to main content

How teams work

Completion requirements
View all sections of the document
Printable page generated Thursday, 28 March 2024, 8:55 AM
Use 'Print preview' to check the number of pages and printer settings.
Print functionality varies between browsers.
Unless otherwise stated, copyright © 2024 The Open University, all rights reserved.
Printable page generated Thursday, 28 March 2024, 8:55 AM

How teams work

Introduction

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.

Learning outcomes

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.

1 Different types of team

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.

1.1 Project teams

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.

The functional 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.

The matrix team

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.

A matrix project structure
Figure 1 A matrix project structure

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.

The contract team

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.

1.1.1 Project teams in practice

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.

Show description|Hide description

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.

Table 1 Some strengths and weaknesses of different structures for project teams
StrengthsWeaknesses
Functional teamHandles 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 teamAcceptable 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 teamEasy 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.
(The Open University, 2008)

1.2 Operational teams

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.

SAQ 1

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.

  • a.Processing applications for entry to a professional society.
  • b.Devising an information security policy for an organisation.
  • c.Designing and developing a new production line in a manufacturing company.
  • d.Installing a new production line in an engineering firm.
  • e.Improving the methods of research and development of a car manufacturer.
  • f.Developing software for patient admissions in a hospital.
  • g.Introducing an automated warehousing system at all the depots of a supermarket chain.
Answer
  • a.This involves a set of routine tasks that the organisation must be equipped to perform; hence it would be carried out by an operational team.
  • b.This is likely to involve a project team structure. Inputs to formulating the strategy would be needed from various areas, plus professional and technical inputs.
  • c.Inputs from various different specialists at different stages would be needed, suggesting that a matrix project structure is most likely.
  • d.Installing production lines is likely to happen quite often in this industry, but the work is likely to be the responsibility of one department: engineering. This suggests using the existing functional organisation, so this is likely to require a functional project team.
  • e.This could be the responsibility of either a functional or a matrix project team. Making incremental improvements would be the responsibility of the various line managers for the different functions involved. However, if new systems or radical change (e.g. process improvements or changes or business process re-engineering) were involved, a project structure would be needed – probably of a matrix type because of the various different professional interests (such as academic, legal and regulatory, formulation and analysis).
  • f.This is likely to be the responsibility of a functional team, possibly with baton passing, or with a project manager or coordinator if it is part of a wider project. The question did not mention a new system, so the straightforward computerisation of an existing system with known requirements is implied – hence the choice of a functional approach.
  • g.The supermarket is unlikely to have the necessary expertise in warehouse automation (i.e. using robots for simple, repetitive tasks). The design and implementation of the automated warehousing system will require specialist resources and hence a contract team is most likely.

1.3 Self-managed teams

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 work done and setting team goals
  • how work is achieved – which processes are used and how work is scheduled
  • internal performance issues – distributing the work and the contribution made by each member of the team
  • decision making and problem solving.

1.3.1 Leading a self-managed team

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.

Show description|Hide description

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.

Table 2 The roles of a team leader in a hierarchical team and a self-managed team
The team leadership role in a:
Hierarchical teamSelf-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.
(Based on the Self-directed Teams topic, Good Practice Ltd.)

1.3.2 Benefits of self-managed teams

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):

  • Cost savings: Organisations such as RCAR Electronics in the USA reported annual savings of $10 million following the implementation of self-managed teams.
  • Innovation: Team members have the freedom to review and improve working practices.
  • Effective decision making: Self-managed teams can develop quicker or more effective decision-making skills.
  • Increased productivity: Teams work towards a common goal and are responsible for their own actions. When successful, self-managed teams can be 15–20 per cent more productive than other types of team.
  • Improved customer satisfaction: Self-managed teams benefit organisational performance through improved sales figures and customer service. Companies have reported significantly lower customer returns and complaints.
  • Commitment: Team members can become more involved in projects as a direct result of having increased autonomy and responsibility.
  • Motivation: Team members have shared or equal responsibility so members are accountable for their actions.
  • Increased compatibility between employers and employees: Self-managed teams can relieve stress for the leader, who is then able to concentrate on other tasks. The team is mutually supportive and members learn from each other instead of approaching the team leader for advice.

1.3.3 Potential problems with self-managed teams

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.

1.4 Communities of practice

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.

Summarised from Wenger (2009)

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.

Activity 1 Communities of practice

Given the above description of communities of practice, identify those communities of practice to which you belong.

Discussion

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.

Author’s reflection

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.

SAQ 2

  • a.What are the main advantages for team members of belonging to a self-managed team?
  • b.What are the three conditions for a group to be designated a community of practice?
Answer
  • a.Team members can 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 others’ skills.
  • b.A community of practice is (1) a group of practitioners in (2) a domain who (3) build relationships that enable them to learn from each other.

1.5 Summary of Section 1

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.

2 Types of virtual team

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.

The space, time and culture classification of virtual teams
(Adapted from Kimble et al., 2000)
Figure 2 The space, time and culture classification of virtual teams

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.

Activity 2

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.

Show description|Hide description

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.

Table 3 Examples of virtual teams
TypeTimeSpaceCultureExampleChallenges
1DifferentSameDifferentCustomer service teamInteraction between organisations or cultures
2DifferentDifferentDifferentGlobal team
3SameDifferentDifferentRegional services
4DifferentSameSameWarehouse teamInteraction between shifts
5DifferentDifferentSameMultinational organisation
6SameDifferentSameOU Regional CentresInteraction at a distance
7SameSameSameProject teamNot a virtual team
8SameSameDifferentContract teamNot a virtual team
(Based on Fisher and Fisher, 2001)

Discussion

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.

Author’s reflection

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!

2.1 Summary of Section 2

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.

3 Team formation

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.

3.1 Stages in the development of 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.

3.1.1 Forming

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.

Features of this stage
  • Team members try to get to know each other. In collocated teams, this often takes the form of a workshop with ice-breaking and social activities that are designed to help the team members to get to know one other. Facilitators with experience of building teams may be brought in to run these introductory workshops.
  • The team attempts to understand the task or project that they have been assigned. This understanding will include trying to scope and define the boundaries of the task.
  • Individuals within the team will be trying to work out what role they want to play in the team, and what roles they want other team members to play. For example, you might be asking yourself ‘who do I want to lead the team?’ and perhaps ‘who do I not want to lead the team?’.
  • As well as establishing what roles team members will take on, the team will also begin to establish some rules by which the team will operate.
Advice for a virtual team
  • Individually, you may experience some anxiety and uncertainty over what the project involves, what the other team members will be like, and frustration over the slow start to the project. Often, there is a feeling of wasted time since there may appear to be little progress on the task that the team has been set. But please be patient. It does take time for people to get to know one another, to begin working together and to build up levels of trust with one another. Time spent on this stage can be recouped later through more effective communication.

3.1.2 Storming

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.

Features of this stage
  • A feeling of lack of progress on the task can trigger this phase of team development. Often, the first deadline that the team has to meet is looming and team members realise that the task is harder than they thought. This puts pressure on the team and the initial politeness and diffidence in addressing one another is lost.
  • Sometimes, differences of opinion over the task can arise, and individuals’ personalities can clash as team members overcome their tentativeness and begin to assert themselves. Team members can even become hostile as a way of expressing their individuality in a reaction against the team culture that is beginning to form. Or they may question the role they have been asked to perform in the team, or the tasks they have been given.
  • Discussion often centres on team process issues, such as team rules (how the team is going to operate) and team roles (who is in charge and who is going to do what).
  • There may not be much progress on achieving the project goals (outputs)!
Advice for a virtual team
  • In an online, shared discussion forum, it is easy for members who feel that they are on the receiving end of unwarranted or personal criticism to become defensive. Unfortunately, this can lead to them withdrawing from the discussion until the debate has become less heated and less personal. It may require a personal, private approach (via email or a phone call rather than in an open discussion forum) to bring them back into contributing to the team.
  • When communicating by electronic means (particularly if you can’t hear or see the recipient), you lose much of the feedback about how your message is being received, since a person’s tone of voice and their body language are very expressive and reveal much about their emotional state.

3.1.3 Norming

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.

Features of this stage
  • The team should reach agreement upon the process issues that it may have begun debating in the previous phase of team development. Specifically, the team should agree the ways of working and interacting with each other (team rules), and individual team members should agree to the roles that they are going to take on in the team and the tasks that they will perform (team roles).
  • The team also reaches agreement upon the nature of the task and how they are going to tackle it. With their growing sense of identity and purpose, the task ‘belongs’ to the team and is not something that has been imposed upon them. The team often develops its own common language to facilitate communication within the team.
  • There is real progress on the task that the team has been assigned.
Advice for a virtual team
  • A useful team rule to establish is how frequently team members should check the team forum and their personal email for messages. This depends on how much time you are devoting (or expected to devote) to the team tasks. If you are in a work situation and the team’s work is your major task then you might need to check for messages from the team several times a day. If you participate in the team in your spare time then less frequently, perhaps once or twice a week, may be enough.
  • It is also useful to establish when individual team members will be able to contribute to the team – their typical working patterns. This helps other team members to know when and how to contact each other, potentially reducing discord within the team.
  • Check that each member of the team has a common understanding of the team tasks, and that everyone is clear about the team rules and language.

3.1.4 Performing

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.

Features of this stage
  • The focus of the team has shifted from team process issues to the task that the team is undertaking.
  • Individuals within the team know how to work with each other and how the team as a whole operates.
  • The team is in a much better position to solve problems as they arise, rather than being thrown into disarray by unanticipated problems.
  • There is a lot of progress towards the final project goals.
Advice for a virtual team
  • In a virtual team, you lack many of the informal cues that are important for keeping a team working productively and easily together, such as how busy someone is, what they are working on and when they might be on holiday, ill, or otherwise unable to contribute to the team.
  • Instant messaging software such as AOL Instant Messenger (AIM), Windows Live Messenger (otherwise known as MSN) and Yahoo! Messenger can be used to indicate team members’ availability and willingness to communicate. These indicators can be used to give a sense of the presence or an awareness of other members of the team in their physical absence. A more recent phenomenon, that of the Web 2.0 website Twitter, can provide a similar function: short updates on what a team member is doing, or thinking, at any moment in time.
  • In the absence of these tools, an alternative or supplementary approach to using software that gives presence and awareness cues is just to give rather more explicit indications of how you are progressing. For example, it is helpful to your other team members to let them know when you will be unable to contribute to the team’s work because of holidays or other time commitments.

3.1.5 Adjourning

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.

Features of this stage
  • The team may become even more effective as it makes a concerted effort to complete the task before the final deadline. However, there is a possibility that the team could become less effective as members regret the end of the task and the breaking up of relationships that have formed between the members of the team.
  • The task is completed, the project comes to an end and the team disbands.
Advice for a virtual team
  • In order to overcome this stage, try to identify some means of moving on, of keeping in touch and of keeping working relationships going, perhaps by something as simple as agreeing to keep in contact by email, or creating an archive as a permanent record of the work the team has done together.

3.2 Implications of the team development model

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).

The S-shaped curve of team development
(Adapted from Lipnack and Stamps, 2000)
Figure 3 The S-shaped curve of team development

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.

The team performance curve
(Redrawn from Katzenbach and Smith, 1993)
Figure 4 The team performance curve

Tuckman’s model of team development has a number of other implications and consequences of which it is useful to be aware:

  • The duration and intensity of the different stages can vary between teams. Some teams may have a very smooth and rapid passage through the first few stages of the model whereas others may have a much more difficult passage.
  • Teams usually have to progress through the earlier stages of development in order to reach the performing stage, so don’t become discouraged if your team doesn’t work too well at first.
  • It is possible for a team to return to a previous stage of development. This may happen if new and significant issues arise in the team, or if team members leave or new members join the team.
  • A team may never complete its journey through the five stages of development. If the team is together for only a short time, if it has taken a long time to develop, or if the team has returned to previous stages of development, then it may never reach the performing stage of team development.
  • The model has been presented in terms of a series of discrete, identifiable stages. However, the stages may merge into one another or be repeated as issues recur or new ones emerge.

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.

SAQ 3

Briefly describe each stage of Tuckman’s model of team development.

Answer

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.

3.3 Summary of Section 3

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.

4 Functional team roles

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.

4.1 Allocating team members to roles

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.

Team leader

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.

Record keeper

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.

Document controller

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.

Progress chaser

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.

4.2 Summary of Section 4

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.

5 Decision making and trust

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.

Activity 3

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.

  • What techniques (if any) did you use in determining what the problem was? Do you think they were effective?
  • What information did you have at the time?
  • What information do you now think you should have had before making the decision?
  • What alternatives did you think you had at the time?
  • Are there any additional alternatives you can think of now that you didn’t consider but wish you had?
  • How did you evaluate these alternatives then, and how would you evaluate them if you had another chance?
  • How did you know when a decision had been reached?
  • If the decision involved electronic communication, either to gather information, to make the decision or to communicate it, were any additional steps required to ensure the process was completed?

Discussion

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:

  • identify what decision it is that needs to be made and, if this requires examination of a problem, consult with all stakeholders to do this
  • ask for, and set deadlines for receiving, information from all relevant parties
  • ask for a ‘nil return’ if there is no information to send and chase if no response is received
  • evaluate appropriate techniques for considering alternatives and evaluating them; ensure that all relevant people are party to this
  • ensure there are explicit methods for making the decision, for recording it and communicating it to relevant parties.

5.1 Preparing to make a decision

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.

  1. Set a deadline by which time the decision must have been made. Communicate the deadline to everyone involved and then enforce this deadline.
  2. Ensure that the problem is defined and that the required decision is clearly expressed. Avoid making a decision about a symptom (for example, ‘we are late’) when a decision about a problem is needed (‘we need to improve our planning’). Figure 5 shows a simple cause-and-effect diagram to find the reasons for a symptom. Whilst this shows quite specific reasons, it points to a general lack of proper planning. In this example, the symptom ‘Unclear what tasks were’ was in turn caused by ‘Didn’t plan tasks well’, which in turn was caused by ‘Didn’t break down goals to tasks’. A line is drawn from each cause to a more specific cause.
  3. Determine options for solving the problem. For each option determine its benefits and any problems it may cause; for example, an ‘ideal’ solution may take too long if you are under pressure and would be discarded as a result. Options can be ranked according to their feasibility and their desirability.
A cause-and-effect diagram to find the reasons for a project being behind schedule
Figure 5 A cause-and-effect diagram to find the reasons for a project being behind schedule

5.2 Reaching a decision

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.

Autocratic

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 rules

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.

Majority rules with minority opinion

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.

Consensus

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:

  • being willing to accept that rejection of one’s own proposals or ideas is not equivalent to rejection of oneself and does not demean one’s worth within a group
  • striving to find, in discussion with the other members of the group, areas of common agreement
  • ensuring that those who don’t initially agree have a chance to have their say
  • ensuring that everyone has the chance to think about their response to counter-suggestions, changes in wording, and so on
  • seeking to build on areas of agreement to achieve even wider agreement
  • willingness to continue the discussions in this vein until a consensus is reached
  • communicate as a decision only that which is supported by the consensus.

A chairperson is required to manage discussions, whether face-to-face or electronic. The chairperson needs to:

  • ensure that everyone has a fair say (both by asking those who dominate a discussion to give way to others and by inviting those who seem reluctant to join in to express their views)
  • ensure that personality clashes don’t occur or are quickly diffused by reminding the participants that the discussions are intended to reach a consensus, not score debating points
  • remind the participants of the value and importance of goals to be reached.

These points apply as much to online discussions using email and conferencing software as they do to face-to-face sessions amongst participants.

SAQ 4

Describe the four models for decision making. Rank them in order of most inclusive decision making to least inclusive.

Answer

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.

5.3 Trust in teams

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.

Gignac (2005, p. 62)

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.

5.3.1 Swift trust

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.

5.4 Summary of Section 5

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.

6 Team rules

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.

  1. The difficulty of scheduling synchronous meetings. Given the complexity of working with people who may be in different time zones, or working for several teams, it is likely that team members may have such different and busy schedules that it may be difficult to schedule a time when the whole team may be available for a synchronous meeting. Consequently, it may be easier to collaborate using asynchronous communication media such as email, wikis and forums, where team members can contribute at a time which suits their own schedules. If the team does arrange synchronous electronic meetings, then good minutes (or notes) of the meeting should be taken so that those people who were not able to participate in the meeting know what was discussed, and the decisions that were taken (just as you would at a face-to-face meeting in the workplace).
  2. Recognising that progress may be slow for a variety of reasons. You may find yourself waiting for someone else to complete their part of the project before you can move forward to the next stage. If so, please be patient. Alternatively, if other members of the team are waiting for you, please keep them informed of your progress. It can be extremely frustrating not knowing what progress is being made elsewhere, especially when deadlines are looming.
  3. Allowing extra time for decision making. In full-time work, meetings can be a significant decision-making tool. Given the difficulty of organising meetings (see the first point above), decisions will probably be taken by more protracted asynchronous discussions. This will tend to slow down the decision-making process because you will have to wait for members of the team to read, and respond to, messages posted to asynchronous forums. One way in which you can help to keep the decision-making process moving forward is to set (sensible) time limits by which every team member should have read, and responded to, issues posted for discussion so that decisions can be taken. The paper by Coar (2003) has a very helpful discussion on the difficulties of reaching a consensus via asynchronous communication methods such as email.
  4. Partitioning the work, so that you are not dependent on working very closely with remote team members on a difficult problem. In the context of software engineering, the design of the software could be partitioned into loosely coupled modules, each module being assigned to one team member or to one location if some team members are collocated. This method of working requires a subsequent integration phase, which can take a substantial amount of time and must be scheduled for. This issue is discussed in more detail in Turnlund (2003) and Hohmann (1997).

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.

  • How frequently are you going to ask that team members check their email and team forum? Once a week, twice a week, daily, or at the beginning and end of each working day?
  • What communication and collaboration media are the team going to use?
  • Should the team set guidelines on when team members might expect to have received a reply to messages posted to a forum or by email?

Conclusion

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.

Glossary

adjourning
The final stage in Tuckman’s model of team development. Team members anticipate the project coming to an end and the team being disbanded.
Autocratic
The decision is taken by the team leader or person nominated by the team, see decision-making models.
baton passing
Baton passing describes the process whereby project work can be handed from one functional team to another in order to complete the work. This is most common in organisations in which the functional divisions are relatively rigid.
Consensus
The decision is made by agreement of all, see decision-making models.
contract team
A contract team is a team that typically is brought in from outside an organisation in order to perform the project work.
decision-making models
The four models are: Consensus – by agreement of all. Majority rule with minority opinion – the decision is that voted for by the larger number of participants. Those who do not agree can express their disagreement, i.e. their dissenting opinion, and give an alternative view. Majority rule – the decision is that voted for by the larger number of participants. Autocratic – the decision is taken by the team leader or person nominated by the team.
dissenting opinion
Those who disagree with the majority, i.e. who have the minority opinion, can express their disagreement as the dissenting opinion, see decision-making models.
document controller
A functional role. The document controller coordinates the production of team documents and reports. In small teams this role could fall to the record keeper or team leader.
dual reporting lines
A person has dual reporting lines if they report to one manager for some aspects of their work and to another manager for other aspects of their work. This can occur in matrix teams.
forming
The first stage in Tuckman’s model of team development. In this stage, team members meet (face-to-face or virtually) and begin to get to know each other.
functional team
A functional team is a team in which work is carried out within a functionally organised group, in which people work together to carry out the same or similar functions.
leadership role in a self-managed team
The leadership role in a self-managed team is a supporting role, involving identifying the long-term career and personal development needs of the team.
life cycle
In the context of teams, a team’s life cycle describes the way in which teams form and develop.
Majority rules
The decision is that voted for by the larger number of participants, see decision-making models.
Majority rules with minority opinion
The decision is that voted for by the larger number of participants. Those who do not agree can express their disagreement, i.e. their dissenting opinion, and give an alternative view, see decision-making models.
matrix team
In a matrix team, individual staff report to different managers for different aspects of their work – to the project manager for their work on the project and their line manager for other aspects of their work.
norming
The third stage in Tuckman’s model of team development. The team has established itself and team members are beginning to work productively together.
performing
The fourth stage in Tuckman’s model of team development. The team are working productively together, getting on with the task, producing results, with good working relationships between members of the team.
progress chaser
A functional role. The progress chaser is a team member who is responsible for monitoring progress and ensuring that the team is keeping to schedule.
record keeper
A functional role. The record keeper is someone who takes notes in meetings, keeps a record of what decisions have been taken, who is doing what, and the date of the next meeting.
role allocation
The process of allocating roles to individuals within the team.
self-managed team
A self-managed team is a team in which members of the team take collective responsibility for ensuring that the team operates effectively and meets its targets.
storming
The second stage in Tuckman’s model of team development. This stage in team formation can be characterised by spirited discussions and arguments among the team members.
swift trust
In some virtual teams there is no time to build trusting relationships. The team must start work immediately without taking time to build relationships between team members.
team development
The fourth phase in the life cycle for virtual team management developed by Hertel et al. (2005). This phase takes place during the definition and execution phases of the project life cycle.
team leader
A functional role. The person who leads the team. Even in democratic teams where decisions are taken by the whole team, someone has to take responsibility for chairing meetings. This normally falls to the team leader.
team rules
An agreed set of conventions for the ways in which team members work and interact with each other and for conducting the business of the team.
timed agenda
A timed agenda allots time to each item on the agenda in order to ensure that later items on the agenda are allocated adequate time for discussion.
timekeeper
A functional role. In a synchronous meeting, a timekeeper will help to keep meetings running to time, particularly if the meeting is following a timed agenda.
trust
If you trust someone, then you show 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 (definition based on Gignac, 2005).
Tuckman’s model
Tuckman’s model of team formation. A model of team formation and development that has five stages: forming, storming, norming, performing and adjourning.

References

Becker, J.D. (2003) ‘Collaborative technologies and virtual teams: which is more important – the ‘Technology’ or the ‘Team’?’, Decision Line, vol. 34, no. 4, pp. 8–10.
Coar, K. (2003) ‘The sun never sets on distributed development’, ACM Queue, December/January 2003–2004, pp. 33–9.
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.
Fleming, I. (2006) The Virtual Teams Pocketbook, Alresford, UK, Management Pocketbooks Ltd.
Gignac, F. (2005) Building Successful Virtual Teams, Boston, Artech House.
Hertel, G.T, Geister, S. and Konradt, U. (2005) ‘Managing virtual teams: a review of current empirical research’, Human Resource Management Review, vol. 15, pp. 69–95.
Hohmann, L. (1997) Journey of the Software Professional: A Sociology of Software Development, New Jersey, Prentice Hall.
Howell, R.T. (2001) ‘Fostering self-directed team members’, The Journal of Technology Studies, vol. XXVII, no. 1, http://scholar.lib.vt.edu/ejournals/JTS/ (accessed November 2009).
Jarvenpaa, S.L. and Leidner, D.E. (1999) Communication and trust in global virtual teams’, Organization Science, vol. 10, no. 6 (November/December), pp. 791–816.
Katzenbach, J.R. and Smith, D.K. (1993) The Wisdom of Teams: Creating the High Performance Organization, London, McGraw-Hill.
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.
Lipnack, J. and Stamps, J. (2000) Virtual Teams: Reaching Across Space, Time, and Organizations with Technology, 2nd edn, New York, John Wiley and Sons.
Majchrzak, A., Malhotra, A., Stamps, J. and Lipnack, J. (2004) ‘Can absence make a team grow stronger?’ Harvard Business Review, vol. 82, no. 5, pp. 131–7.
Nohiria, N. and Eccles, R.G. (1992) Face-to-face: making network organizations work, in Nohiria, N. and Eccles, R.G. (eds) Networks and Organizations, Boston, MA, Harvard Business School Press, pp. 288–308.
Tuckman, B. (1965) ‘Developmental sequence in small groups’, Psychological Bulletin, vol. 63, pp. 384–99.
Tuckman, B. and Jensen, M. (1977) ‘Stages of small group development revisited’, Groups and Organization Studies, vol. 2, pp. 419–27.
Turnlund, M. (2003) ‘Distributed development lessons learnt’, ACM Queue, vol. 1, pp. 26–31.
Wenger, E. (2009) Communities of Practice: A Brief Introduction, http://www.ewenger.com/theory/ (accessed May 2009).

Acknowledgements

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