case study - apollo & fallacy complexes

IT Management teams are often classic cases of the Apollo Syndrome. This was a term coined by Professor Belbin in the 1970s. It explains why a team of very capable people can perform badly.

I recall one such team that was struggling with several problems, including:

low morale in the workforce

high stress levels

dissatisfied customers

missed deadlines

insufficient resources

and other related problems.

It became clear that they were alternating between the Apollo and Fallacy team complexes.

Apollo Complex

The Apollo Complex is related to the use of the Scientist team role. One characteristic of this role is a focus on inconsistencies. Finding flaws is a skill that can be useful in IT. To make large computer systems reliable, one has to be able to see all the flaws in advance.

But in this management team the Scientist team role was overused. They criticised each other’s ideas so much that the ideas had no chance to develop. They frequently had circular and unproductive arguments. Their focus on flaws was inhibiting team progress.

Fallacy Complex

Eventually the team’s behaviour would flip from the Apollo Complex into the Fallacy Complex. This type of problem was also observed by Professor Belbin in his research (though not named).

After some time in Apollo discussion, typically around half an hour or more, the team leader would intervene. He would point out what was happening, i.e.: that the discussion was not productive.

At this point, everyone would usually go quiet. They knew the leader’s observations were correct. But no-one knew how to stop the argument, or they saw other team members as being the argumentative ones. (Such a response suggests the behaviour is unconscious).

The team leader would then make the decision. The team would go along with this because there was no better alternative.

Overuse and Under-use

The team therefore went from one extreme to another. Before, ideas were killed off before they were allowed to develop. After, the one idea was accepted with no discussion. There was no analysis of the consequences, so the idea had a high risk of failure. It also had no real buy-in from the rest of the team.

Solution

There were two main options for dealing with this situation.

The first was to work with the team to change their individual and collective behaviours. This would have involved bringing their behaviours into consciousness. This is a long term solution and some may have found it difficult. Some people cannot or will not face the contents of their unconscious personality. For others it is relatively easy.

The second option was a safer one, more reliable and relatively quick: to introduce and facilitate a standard team decision-making process. This would force a balanced use of the Scientist role.

The two approaches are complementary. One changes the person inside to change the outward behaviour. The other changes the outward behaviour to change the inner personality. It also helps them adapt better to the circumstances, even if they are unable to change quickly enough.

This second solution involved using a standard team decision-making process. This was strictly enforced, e.g.: when ideas were being suggested, no evaluation of those ideas was allowed. Also, they weren’t allowed to say why someone else’s idea wouldn’t work, they could only suggest a different idea that they thought would work.

It took some time to get them to follow the process. Some wanted to skip steps (e.g.: skip ‘clarify the problem’ and go straight to ‘brainstorm ideas’ ). Others found it hard not to criticise others ideas. This required some strong facilitation to make the process succeed.

The outcome was that they agreed some good, well-developed actions to address their problems. Within a few months of the workshop, morale and stress levels had improved, and the customers were gaining more confidence in their service.

Conclusions

The solution in this example was a simple process. But when a team develops complexes they stop doing the simple things.

The principle they had to learn was also simple: use a team role when appropriate, and don’t use it when it isn’t.

(Return to team or team roles )