Chapter 12. Channel conflict into learning

by Dan North

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.

Roy’s analysis

This is classic learning mode advice. There are several key points here:

• Conflict and discussion are part of the six influence forces (how peers react and pull each other in different directions).
• Parallel learning (set-based work) is a great technique, but it can’t be done in survival mode.
• Unblocking a team might mean that the team doesn’t know how to unblock itself, which we’ll discuss in the next paragraphs.

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:

• Often, the team leader is the appointed technical entity with accountability for the state of the software and its sustainability; therefore, they’re responsible to make the decision. Of the six influence forces we discussed earlier in the book, this would fall under environmental motivation. Others might not want to make a decision in this case, because it’s “not their place.”
• The team leader knows (personal ability) about the set-based approach and can direct the team to follow that approach.
• The team culture might be “wait for someone else to decide” (social ability and social motivation), impelling the team leader to be the one to make the decision.

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:

• Teach the team about this technique. Of the six influence forces, this falls under personal ability.
• At the organizational level, enable the team to follow the path of parallel learning when needed, without waiting for the team leader to suggest or instruct it. This can be as simple as “Guys, if I’m not here, next time something like this happens, feel free to take the same approach! You’ll have my full backing even if management breathes down your neck, because this is the right thing to do.” If management does continuously breathe down your neck, you might not be in learning mode, but in survival mode, and you need to push to get back into learning mode.

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.

Exercises

• What other types of events get your team “stuck” to the point where you have to intervene?
• What crucial skill do you bring to the table that results in the team depending on you to solve a problem?
• Is it a skill that you have, or is it a skill that they lack? For example, if people don’t get along with each other, is it up to you to play mom and dad, or can you encourage people to speak with each other and try to solve their differences using some practices that you can teach them?

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.