Consider the Following…
You are presiding over a team meeting as a project manager, or you are a business analyst working with a group of stakeholders to come up with a challenging problem or solution. The people assembled at the table in the conference room, a diverse bunch of people, are voicing their opinions, none of which seemingly agree with anyone else. Factions seem to grow as members voicing their opinion are joined by others voicing the same or similar opinion against those who hold different opinions. From their body language you could tell that agreement seems distant: several are turned slightly away from the table so that their shoulders face the other people at the table, a couple surreptitiously looking into their laps at their cell phones, James seems to find something more interesting on the ceiling and has an expression of forced tolerance. At times it seems that amongst all of the eight people at the table there are 12 different opinions. It has been going on for longer than you planned. You are beginning to get concerned that a collaborative conclusion will not be reached, and that is what all of the management books tell you to strive for. Then Charlene says, “what if we do this?” Sven says, “yes, that might work…” Amal chimes in with a modification to the suggestion. The tone of the meeting seems to change. Everyone sits forward, even James. Others begin to chime in and the dwindling disagreement seems to be centered on variations to the same idea most of which are either agreed with by the group or dispensed with. Within 10 minutes everyone is in agreement that Charlene’s idea will work as the solution to the problem you are facing. Even James. Naturally, you are pleased. You have presided over collaboration in action. Not only did the team resolve a sticky problem, but they collaborated. You end the meeting on a high note and call it a day. A very successful day. You go back to your office and send out an email to those present at the meeting summarizing the proceedings and draft an email to be sent to various management types announcing the solution.
The next day you come into the office and are met with Charlene who says that she got the email about the meeting and is wondering who on earth came up with this stupid idea? Before you can remind her that she did, James and Sven brace you in the corridor and say that that idea will never fly. Katerina, normally quiet and impartial appears to be quite upset that we are even thinking about this idea and brings up several significant objections to it. You tell them that we will reconsider the idea later on today and pass the message to the other team members. You repair to your office and collapse in your desk chair staring at your monitor thankful that by habit you create drafts of any correspondence to management and then review them in the morning. Your email announcing the solution is still safely in your draft folder. You stare at the ceiling looking for the answer: “what on earth just happened?”
What happened was an example of Group Think.
The Many Faces of Group Think
While Group Think takes many forms, this one is particularly insidious because it certainly seems like collaboration has been reached and it is a time of celebration rather than one of concern.
The term “Group Think” was coined by Irving Janis in 1982 who describes this particular cognitive bias as “a deterioration of mental efficiency, reality testing, and moral judgment that results from in group pressures”. In other words, the members of the team relinquish their individual identities and opinions in favor achieving an agreed-on result. Or as Gary Klein, author of Sources of Power, says, “we can say that the idea captured the team”.
It may feel good when your entire team seems to be in perfect harmony, all singing the same song, and coming to what appear to be collaborative conclusions and consensus-based solutions. It certainly is a lot easier to manage a team that has no conflict. Remember, however, that there is no innovation without conflict. As Alfred Sloan, the CEO who built General Motors, once reportedly said during a meeting in which everyone agreed with little discussion: “Gentlemen, I take it we all are in complete agreement on the decision we’ve just made. Then, I propose we postpone further discussion until our next meeting, to give ourselves time to develop disagreement – and perhaps gain some understanding of what the decision is all about”. Or words to that effect.
In this era of team-above-all agile software development, individualism seems to be frowned upon. While the concept is valid and teamwork does produce significantly better results, sometimes the "team movement" plays out like the 1950s conformity trend: “go along to get along”, or “don't rock the boat”. We have seen many examples of the manifestation of team above all, both good and bad. It takes a lot for an individual to do what they think is right in the face of a larger group doing something different. Social ostracism and peer pressure are powerful persuaders. And in a culture where interruption, not to mention disruption, is considered an enemy of productivity and progress, it becomes nearly impossible. Unfortunately, reasonable discussion and dissension is often classified as team disloyalty. And many project managers are so afraid of conflict and their inability to resolve conflict among the team members and peers, they do everything they can to suppress disagreement and produce collaboration. Which often results in Group Think.
Legitimizing Disagreement
So, the question becomes: what can we do to keep a collaborative effort from sliding into Group Think? Can we promote viable and objective disagreement over the facts of the issue and not find ourselves in serious conflict or open warfare?
Perhaps the best way of combating Group Think is by assigning a “Devil’s Advocate” to each meeting. The role of the devil’s advocate is to offer an alternative to any solution or idea, question the basis for the proposed solution, and to point out negative aspects of any solution or idea offered by anyone in the meeting. The devil’s advocate is a way of legitimizing disagreement. Clearly such a role is not something that most people would volunteer for, at least openly, because there is always the chance that one of the contrary comments might be taken personally. To offset this dynamic, you announce to everyone at the meeting who the devil’s advocate is going to be and what the devil’s advocate is supposed to do. And, it is always good to rotate the role of devil’s advocate through every member of the team. While it doesn’t completely eliminate disjointed noses, it will minimize the emotional impact.
If you do not wish to assign a devil’s advocate, or the team members resist the role, then take upon yourself to encourage alternate opinions, as well as, dissent and objective criticism. That is, dissent and criticism of the ideas not the people who are voicing the ideas. Even though the facilitator is supposed to remain neutral and not get involved in the discussion, you may find it appropriate to ask questions that might lead to some discussion of alternatives.
Everyone has an opinion and wants to voice it, and you as the moderator or facilitator are more than happy to get everyone’s opinion. However, in the dynamics of teams, there are some who have more assertive personalities and when they voice their personal opinion, as opposed to an objective opinion based on the content of the discussion, people may go along with the stronger personality or they simply have no desire to confront that person. There are other dynamics at play as well including strong friendships, office alliances, position jockeying and so forth which typically eclipse objective considerations. A suggestion to minimize the effect of personal opinions is to hold all personal opinions of whether you are in favor or against a particular issue until after all the discussion has been made. This requires that you, as moderator, monitor all of the comments and censor those which may be personal, informing the speaker that they can voice their personal opinions at the end.
A telltale sign of a personal rather than objective opinion is any comment that starts with “I think” or “I believe” or “I feel” and so forth. Also when you hear extreme descriptors being used such as “never”, “always”, “we should do this...”, “we have to do that...”, or when a comment is directed at an individual, “You always pick the more technical approach. We should be doing the right approach, technology aside.” If necessary, you may even resort to the Delphi approach of submitting anonymous evaluations of a proposal by paper ballots. This generally eliminates any influence of personality on the decision-making process.
If you have a large enough team and enough time, you might consider splitting the team into smaller groups discussing the same topic with different leaders. Unfortunately, while this is a very good alternative, each of the group may become very possessive of their solution and when the team reconvenes as a whole, you may have an “us” versus “them” situation.
Collaboration is not about resolving conflict. It is about surfacing team members’ alternate opinions or their concerns with the overall groups’ decisions. And it also does not mean that everybody must be happy with the final decision. Everyone should understand what the decision is, why the choice was made, and have a very good feeling that all aspects of the issue, both pro and con, were given adequate discussion. In other words, once a decision is made everyone should be in agreement that they are behind the decision and will work to make the decision successful. Collaboration is achieved and group think is avoided when every person voices their view of the issue and is allowed to retain their personal view even when the final decision or conclusion varies from that view.
Author: Steve Blais, PMP, PMI-PBA
Steve Blais, PMP, PMI-PBA, is an author, consultant, teacher and coach who has nearly 50 years’ experience in Information Technologies working as a programmer, project manager, business analyst, system analyst, general manager, and tester. He has also been in an executive position for several start-up companies. He develops business analysis and agile processes and trains business analysts, project managers, and executive for organizations around the world. He is the author of Business Analysis: Best Practices for Success (John Wiley, 2011) and co-author of Business Analysis for Practitioners: a Practice Guide (PMI, 2014) and a contributor to the Business Analyst Body of Knowledge, V3 (IIBA, 2015).