Difference of opinion in high-performing teams isn’t necessarily a bad thing. In fact, conflict is a necessary ingredient for learning teams. In his book The Fifth Discipline (Doubleday, 1990), Peter Senge describes the twin discourse activities of dialogue, where a team explores an idea from a number of perspectives, and discussion, where they attempt to reach consensus. If everyone agrees all the time, there isn’t any stimulus for growth.
On the other hand, conflict between strong personalities can be difficult to manage and can cause factions or cliques within a team and eventually tear it apart. As a software team leader, it’ll fall to you to make the big decisions: Which technologies should we adopt? Which of these competing frameworks should we choose? When the team senses change on the horizon, you’ll find strong advocates for different alternatives, which can paralyze the team.
When I find a team blocked on a decision, I’ll often suggest deferring the commitment by trying all the options simultaneously and letting the data inform the decision. On one occasion, a team leader asked me whether his experienced Java team should adopt Clojure or Scala as their “next generation” JVM language. The team had agreed they wanted to stay on the JVM but move beyond Java and had reached a stalemate over which direction to take. He was feeling pressured because, in his words, he had to make a decision imminently, both from a team health perspective and because stalling was beginning to impact their delivery. My answer surprised him:
“Should we go with Clojure or Scala?”
“Yes”
“Eh?”
There were six developers in his team, and I suggested they go with Clojure and Scala. And Java! At least for the next couple of weeks. One pair would learn Scala, one Clojure, and the third pair would stick with Java.
They’d all work on the same features, which means they’d be coding in a real domain rather than playing with code katas or tutorials, and within a couple of weeks they’d have some real data to make a decision with.
How easy was it to learn the language? How well was it suited to the problem at hand? How did each of the approaches compare with the others? How nicely did they integrate with the existing codebase? How important were each of these things in this context? They’d also have the Java solution as a control for comparison.
This approach uses an idea from the manufacturing industry called set-based concurrent engineering: several suppliers build the same thing—say, an airplane wing—in different ways, and after a while you choose one of them to take forward. You still pay the others—this exercise is at your expense rather than theirs—but it means that regardless of which you choose, you haven’t lost any time. You trade efficiency for effectiveness: it’s more expensive to get there, but you get there faster and you know you made a better decision. Many safety-critical industries mandate this approach for certain components.
The team leader added a nice twist to this. Halfway through, he got the pairs to switch around, and by the end of the experiment each pair had tried two of the languages. After several weeks, the team reached a strong consensus around one of the choices. They’d found it a better fit for their specific context, both in terms of the language itself and its libraries and toolchain. The team was unblocked and, what’s more, they’d reached the decision as a team and learned about the alternatives along the way.
This is classic learning mode advice. There are several key points here:
What about the big goal, our mantra as leaders: to grow the team to the point of self-organization?
At a higher level, as a leader, conflict is an indication that the team is missing a skill: how to make a decision when there are multiple good choices. If, as a software team leader, it falls to you to make the big decisions, what does that indicate about the team?
The team leader becomes the decision-making bottleneck. The question then becomes this: “Why does the team leader have to be the decision maker? What skill does the team leader possess that the team doesn’t?”
There are several possible influence forces that might be at play:
Assuming it’s the first two and not the third, to grow the team into a more self-organizing state, several actions might need to be taken:
It’s easy to focus on the day-to-day practices that optimize the team at a micro level, but attaining higher-level optimization by removing yourself as the bottleneck is key to make the team truly soar into new realms of productivity, loyalty, and passion.
DAN NORTH is an independent technology consultant who writes software and coaches teams and organizations in Agile and Lean methods. He believes in putting people first and writing simple, pragmatic software.
3.144.123.155