Paula’s post on groupthink got me thinking about agreement. Not only about the potentially dangerous effect of unexamined agreement within a group, e.g. the groupthink that Paula discussed, but also the equally dangerous effect of presumed agreement. A team composed of multiple professional tribes often doesn’t agree even when there appears to be a “consensus”. However, they may not be completely aware of this until the project has an unpleasant outcome.
You’ve just initiated a new direction for your product, and you’re assembling the team. If you’re like me, you prefer that all contributors, regardless of professional role, really work as a team, and not as semi-detached departmental representatives. Before the formal kick-off of the initiative, I like to have a relatively informal concepts meeting to talk about what we are doing and why. It requires a whiteboard, and it requires that the terms we throw around with confidence are actually defined, even (gasp) defined in writing.
Why? Admittedly, many people, feeling impatient with the urgency of “getting things done” chafe at the idea of yet another terminology exercise. They may protest “we all know what X means; can’t we just get on with it?”
But sharing a word is not the same as sharing a meaning.
A common problem in new or even old teams is what I call “Presumed Agreement”: the presumed agreement of meaning based solely on an agreement of words.
On a consulting assignment many moons ago, this phenomenon was brought into stark relief for me. The project in question was in turmoil. The sponsoring executive was on the verge of firing the contractors, but wondered how to professionally recover from terminating such an expensive, vaunted project. Meanwhile, pretty much every tribe within the project was blaming the other. The phrases I was hearing included “They didn’t deliver what we expected”, “They don’t get it” and the like. Long story short, I convened a meeting of all project members, set rules such as “all attendees have equal voice, whether VP or contract programmer”, and announced that the first exercise was one of terminology clarification. Much groaning and skepticism ensued.
Company Engineer: “But we all know what ‘X’ means! That’s not the problem!”
Me: “Really?”
Contract Programmer: “Sure.”
Project Manager: “Of course!”
Me: “Okay. But I need to be certain. How about you write your definition of X on the white board so everyone can see it?”
(Irritated and incredulous murmurs across the room)
Contract Programmer: “Alright, but this is going to be a waste of time.”
(He writes his definition in big, impatient letters and turns to face the room)
Company Engineer: “That’s NOT what X means!”
(The room is now in an uproar)
Suffice it to say that the terminology exercise was taken seriously, and in a half-day we had a refreshed, concise, and most importantly, actually agreed-upon lexicon for the project. By the end of the second half-day we had identified and patched all the conceptual holes that the previously only presumed agreement had left in the project and which had been at the root of so much waste, angst and distrust. Understanding was achieved and morale lifted. The project recovered and was successfully managed to completion.
I can’t emphasize enough how important the detection and cure of presumed agreement is. After that experience, I wondered how many projects are believed to have failed for all kinds of highly analyzed and subtle reasons, the kind that Harvard Business might cover, when the actual root cause was something as basic as terminology.
So how does presumed agreement relate to tribes? I’d say that it is the tribal nature of professional roles that helps to guarantee dialect differences in the understanding of common words, and if these differences are not surfaced and dealt with early and often for each new project, they will fester and potentially render the entire effort futile.
Trevor Rotzien
the product manager
Notes:
I discovered after the fact that my conception of “presumed agreement” is a kind of “bypass”, as defined by Isa Engleberg: “Another barrier to language is bypassing. Bypassing occurs when group members have different meanings for different words and phrases and thus miss each others meanings. To overcome the risk of bypassing it is important to look to what the speaker wants and not always at what the speaker says.”
Engleberg, Isa N. Working in Groups: Communication Principles and Strategies. My Communication Kit Series, 2006. Pages 126-129.
If you find the problem of miscommunication and biases in groups as fascinating as I do, try searching on any of these concepts (that I may cover in future posts):
- Abilene Paradox
- Bandwagon Effect
- Deformation Professionnelle
- False Consensus Effect
- Herd Instinct
- Interloper Effect
- Need For Closure
- Pseudoconsensus
