I was talking to my friend Penny the other day about a team she coaches. She has a problem I’ve seen on many teams: a smart guy (or gal) who dominates the team.
I’ll call Penny’s team member Bob. Most of the time Bob is an asset to the team. But when the team needs to decide on a technical solution under time pressure, he’s not.
How can this be?
Dominating the Flow of Ideas
When it comes time to solve a technical problem, Bob always offers his idea first. Then, Bob dominates the conversation with a constant stream of words, leaving no opening for another to insert facts, ideas, points of view. When someone speaks up, Bob cuts him off.
When Bob finishes, and another team members asks a question, Bob implies that the other person doesn’t understand. He even hints they might be too stupid to see the brilliance of his ideas.
When another team member proposes a different idea, Bob shreds it. He points out the flaws in the other person’s idea, while pointing to the strengths of his own idea.
When he does let others speak, it’s pretty clear that he isn’t listening to learn. Bob is figuring out how to score his next point.
How a Dominant Person Can Hurt a Team
I don’t believe Bob has bad intentions. I believe he wants to be helpful, and believes he is. Bob is helping the team in many ways, but he’s also hurting the team. Here’s how:
1. The team don’t have enough ideas. Due to Bob’s style, there is seldom more than one idea (Bob’s) that receives serious consideration. That’s not enough. Even if Bob is smart, so are the other people on the team. But Bob is a fast thinker. He’s the best at argument and debate. However, that’s not the same as having the best ideas.
2. Over time, Bob’s style will wear down the other team members. It’s really not terribly satisfying to be browbeaten. At some point, other people will stop offering ideas. They’ll acquiesce rather than endure another argument with Bob.
3. As long as Bob’s ideas prevail, others don’t have a chance to develop their ideas.They are deprived the opportunity to learn, think about problems and risks, and increase their capability. Over the long run, that’s bad for the individuals involved, bad for the team, bad for the organization. Teams do better when participation is roughly equal.
Make it Easier for All to Raise Ideas
Penny has given Bob feedback on the effects of his behavior. For a short time, Bob altered his behavior. But when there’s pressure to come up with a solution, Bob falls back on his old behavior. Chances are, Penny won’t get Bob to change that. Bob’s is acting out of his natural tendencies. Furthermore, he believes that competition and argument forge the best ideas.
However, Penny can change the process so that the team has sufficient ideas to consider, and that credible ideas receive due consideration.
Separate generating ideas, explaining ideas, exploring ideas, and evaluating ideas. Up until now, these distinct processes overlap and slosh together (with Bob center stage).
Equalize participation. From what Penny has told me, I suspect Bob is a strong extravert and the other team members are introverts. That means that Bob is very comfortable thinking out loud, and the other team members need a bit of time to organize their thoughts. Before they have time to do that, Bob is on a roll. One way make room for more participation is to start the process with a few minutes of silent brainstorming. Then, ask each person explain (orally or through sketching) the essentials of his or her best idea.
Apply the Rule of Three. If you don’t have at least three ideas, you don’t have enough ideas, and you probably don’t understand the problem. You may end up with deciding the first idea that came up is the best one…but you may not, or you may refine the first idea based on further discussion.
Test for agreement. Some teams get carried away with voting. But when a decisions are routinely highjacked by one individual, it can help to test for agreement using a gradient of agreement or fist of five.
Establish a small set of tests for technical solutions. In this team, some of the tests that make sense might be:
The solution …
- is the simplest thing that can work.
- doesn’t increase technical debt.
- can be implemented in the timeframe required by service level agreements.
Bob may have the best ideas on the team. We don’t really know if that’s the case. No one else’s ideas receive full consideration. We do know he doesn’t have a perfect record. Some of his fixes don’t work the first time. Some of his fixes break something else. If the team had a process to consider and refine ideas, that might not happen as much.
It may sound like it will take more time to separate generating ideas from explaining, exploring, and evaluating them. It may seem like a lot of effort to find more than one idea and test the ideas for soundness and test the level of support for a given idea.
But in years of observing teams, I find that slowing down and separating the steps of the choosing a solution helps the team speed up. A mashup process forced by a dominant individual may appear to save time in the very short-term. That’s seldom true if you account for all the time costs and other effects incurred.