Learning through doing: human factors and how teams can fail

By Rebecca Charles - January 16, 2018

On 28 March 1979, a partial meltdown of reactor number 2 at Three Mile Island Nuclear Generating Station led to radioactive gases being released into the environment, in what is cited as being the most significant nuclear accident in US history. In the middle of the night, on 26 April 1986, 31 immediate deaths were caused when the number 4 reactor exploded at Chernobyl Nuclear Power Plant. These two incidents were partially caused by issues with the teamwork and response of the control room crew, who were working at the time of the incidents. The iconic image of two plumes of smoke filling the sky off the coast of Florida was seen by viewers worldwide on 28 January 1986, when the Space Shuttle Challenger broke apart 73 seconds after launch. All seven crew members were killed immediately. One contributing factor to this incident was faulty decision-making at an organisational level, and a shifting level of acceptable risk.

On a lighter note, NASA managed to lose a space probe weighing in at a hefty 340kg, which had cost around $330 million, due to two teams working separately from one another and using different measurement units. The Mars Climate Orbiter had only completed 286 days of its mission when it approached Mars on the wrong trajectory due to the wrong measurements being used, entering the upper atmosphere of Mars and disintegrating.

While all of these incidents were made up of many complex issues and problems, they all had one thing in common: failures in teamwork or communication. Sometimes, these issues can appear to be so simple that it is hard to understand how they can happen - for instance, the use of different measurement units in the Mars Orbiter example. This was two highly-skilled scientific teams, who had been working on this for years. It would be picked up by someone, surely? It can be difficult to comprehend how these situations can develop, so trying to teach aspects of team cognition and team communication (especially if students have limited experience of working in teams) can be challenging.

The role of cognitive ergonomics

As part of our Safety and Human Factors in Aviation MSc, we teach a module on cognitive ergonomics. For the past couple of years, I have taught our students about the complexities of team cognition using a practical bridge-building exercise.

The students are split into four groups, which make up two teams (two groups in each team). Each group is placed in a separate room, and given written instructions. Using the same provided materials (a limited amount of paper, card, scissors and tape) they are tasked with building one half of a bridge based on the criteria they have been given, and are told that in 90 minutes they will be expected to meet with the other half of their team, and connect the bridge together. They are told they may communicate through written notes passed from door to door, but the notes cannot contain pictures. Each of the group members are given individual roles and responsibilities, such as the MD, who will get a bonus if the team completes on time; the designer, who will be sued if the design is sub-standard; and an accountant, who has to ensure the design is cost-effective. The bonus is proportional to the amount of materials left over.

Throughout the 90 minutes, all of the events are engineered to cause breakdowns in communication and ambiguity. Often, the teams produce radically different bridge halves. While this causes much hilarity, it helps to highlight what could potentially go wrong when teams are working together, but remotely.


After a coffee break, we settle into the lecture. I open with a very general: "How successful do you think your team were?" This builds into the five main issues that can be observed when considering team cognition:

1. Communication

When teams are not located together geographically, communication is often done through email, or phone, or Skype. This means that all communication is intentional. You can’t just walk by a colleague’s desk and ask casually what they are up to, or see a drawing on their desk and ask them to explain it. You have to be aware of the information you want to receive, in order to ask for it. In the class exercise, because the teams are given information regarding height, this is very rarely talked about. This leads to the bridge halves often being different heights.

2. No shared goals, or different goals

In order for a team to work efficiently, it has to be working towards the same goal, or series of goals. The team are all working towards a shared goal, to build one half of a bridge. But, by giving the team different roles, and different briefs, they are working towards different individual goals that often conflict with one another. Often, these individual goals can become so important that they morph into the shared goals without anyone noticing. This is especially apparent at higher levels of an organisation and is what happened in the Challenger example.

3. Different mental models

In this example, the teams were given different pictures of bridges. This was priming them to work towards that picture. This gave them a mental model of the bridge they were building, and without appropriate communication, they were unaware that the other team had a different mental model. The workers in the control room at Three Mile Island had a mental model that they were working to. The problem was, this was based on inaccurate information. They kept working using this mental model as their reference. It was only when a different shift came on that they noticed straight away that something was wrong. Unfortunately, by then it was too late.

4. Different approaches to tasks

Each group approached the bridge-building task in a different way, which is to be expected. The problems arise, however, when these approaches are not communicated among the team. It also becomes a bigger problem when these different approaches conflict with one another and have not been managed appropriately. In this example, one half of the team were approaching the task with strength a key factor, and the other, aesthetics.

5. Workload changes and changing goals

Workload throughout a project fluctuates, which can lead to periods of high and low demand. In addition, goals (whether team or individual) can evolve or change. In this example, the groups were given various instructions. They all received the same ones, but in different orders and at different times. This can happen in real life projects where information gets stuck in the system. That may be because of legislation, or it may simply be sat unread in somebody’s inbox. For example, the teams were given a memo that required them to make their bridge have a certain ground clearance. One group was given this information towards the beginning of the task meaning they incorporated this into their goals. The other group received this towards the end of the task. This affected their goals and priorities, and also increased their workload to try and alter their design to meet the specification.

Although the exercise is very engineered and forced, it provides an excellent way to give some understanding to a fairly abstract concept. By having the bridge example to keep coming back to during the discussions, it enables the students to be able to identify how these sometimes simple issues can lead to potentially catastrophic disasters. It is also some light relief on a Friday morning after a heavy-going module!