A team with no conflict will soon be no team

Two weeks ago I had a conflict with one of the guys on my team.

I was calling him out for taking on too many tasks. He was trying to do them in parallel and could not cope. He could not finish a single one of them, even though he gave it everything and worked late.

The reasons were perfectly valid: either an external contractor failed to do their part on time and had to be constantly poked with a stick, or a surprise turned up on the way and stretched the development.

Even so, I believe he could have got the work done faster if he had concentrated on one task and handed everything else over to the other team members.

Avoiding conflicts

I put that thought to him, after which we had roughly this conversation:

— ... so next time just say that you took on too much and cannot cope. There is no problem at all in taking somebody as a pair or simply asking for help.

— All that help stopped working in our team. You invite a person to help, and a couple of hours later they switch to some other task. Or they do nothing at all except watch me write code. There is no use in help like that. It is easier to do everything myself.

— Did you tell those guys that they behave incorrectly?

— Yes, I did.

— And what did they do?

— They keep doing it.

— Even after you tell them about it again?

— No, I only said it once.

— Why?

— Who am I to lecture other people?

That conversation alarmed me. If hidden conflicts like that have spread through our whole team like mould, over time it leads to total disconnection. People will stop wanting to help each other, to ask for help, to talk normally.

Follow that trend and the team stops being a team and turns into a bunch of "colleagues".

A team is a system

A company can organise software development in two ways:

1. hire a number of developers, use them as individual performers, give them individual assignments, collect the results into a product.

2. join people into a group, give them a shared context, a shared goal and shared responsibility.

The first approach is simple and controllable. The second takes a bigger investment to set up. Even so, the second way creates a system, which the first one cannot.

A system has properties and abilities that none of its parts has. And the system loses those properties and abilities if you split it into parts.

A car, for example, can take you from home to the office. A wheel, a steering wheel, an engine cannot. And if you split the car into its parts, it cannot take you anywhere either.

A human can read. An eye and a brain on their own cannot. Take the brain or the eyes out of a human and neither of them will read any more.

Conflict != quarrel

A team in tune can solve problems of a size and get through an amount of work that its members could not manage even added together while working individually.

A team cannot be called in tune (or a team at all) if it has no "blood" — collaboration. But collaboration between people is impossible without reaching agreement.

Team members can reach agreement by evolution, removing the disagreements that come up one after another. A disagreement is a conflict, and people tend to avoid conflicts.

The word "conflict" is not the equivalent of "armed conflict", "quarrel" or "argument". A conflict is merely a disagreement. A quarrel is a disagreement whose discussion got out of hand.

To keep the process of removing disagreements within the bounds of decency, one of Goldratt's thinking tools may come in handy — the "conflict resolution diagram", also known as...

The evaporating cloud

Let us imagine a simple example.

The director of a company that builds a payment system believes they need to build automatic card charging. In his view it makes the system more attractive to corporate clients, who need that ability to serve their own customers.

The development team lead is against it. He believes the feature will bring in little money while adding load to the system.

Both want what is best for the company. Both want the company to be profitable.

This conflict can be drawn:

That is the conflict resolution diagram.

Boxes

To draw it, we need the following parts:

1. The shared goal

If the parties to the conflict have no shared goal, they have no reason to come to an agreement. The shared goal can be distant or abstract, like "peace in the team", but if there is a closer and more concrete option, take that one.

2. The conditions for reaching the goal

These are the necessary but not sufficient components for reaching the goal. There can be (and most likely will be) more of them than the diagram shows. But right now only two matter for this conflict.

The conditions themselves do not conflict with each other. Both parties agree that they need both an attractive service and a stable system. What conflicts is only the ways of meeting those conditions.

3. The ways of meeting the conditions

Ways can conflict for two reasons:

• There are not enough resources for both: pick the first and there is no time or money left for the second (which is not the case in this example).
• Picking one logically rules out the other: we cannot build and not build automatic charging at the same time.

Arrows

Levels 1 and 2, 2 and 3 are joined by arrows that read as: X is needed in order to reach Y. For example: "Building automatic charging is needed in order to reach an attractive service, in order to make the company profitable."

The two conflicting ways are joined by a lightning bolt arrow, showing that these two conditions are incompatible. It reads as: "We cannot build the charging feature and not build the charging feature at the same time."

So the whole diagram reads like this: "To make the company profitable we have to provide an attractive service, and for that we need to build the charging feature. On the other hand, for that we need to keep the system stable, and for that we need to not build the charging feature. We cannot build the feature and not build it at the same time. And that is why we have a conflict."

Checking the logic

Every arrow has to describe a logical link. Every link has to be open to doubt. Behind each of them lie assumptions that may be wrong or simply unclear to one of the sides. They have to be written out.

"To provide an attractive service we have to build the charging feature because":

1. All our competitors already have this feature.
2. Two of our clients have already asked when we will finally have it.
3. Once clients start using this feature they will have to start using our other services too, such as "card tokenisation".
4. ...

"To keep the system stable we have to not build the charging feature because":

1. The chance of a successful automatic charge is around 5%, and clients pay us for a successful transaction, which means we will earn little.
2. The servers will be overloaded because the transaction volume goes up several times over.
3. ...

Some of the assumptions can be thrown out right away if they have nothing to do with reality. If an assumption looks like a half truth, it has to be rewritten so that everyone agrees with it.

For example:
"All our competitors already have this feature" → "Our biggest competitor has this feature".

Every arrow has to be tested for nonsense, the conflict one included. It may turn out that we actually have enough resources for both, it just was not obvious from the start.

Injections

When no nonsense is left among the assumptions, it is time to add injections. These are ways to make an assumption irrelevant by adding an extra condition to it.

For example:
"The servers will be overloaded because the transaction volume goes up several times over unless we buy enough capacity to support the new service".

Injections are written into the rectangle in the middle of the diagram.

An injection is a way out of the deadlock, an option nobody had noticed before. An injection does not have to be a clear action, it can be just an idea or a direction of thought. What matters is finding as many of those ways out as possible.

The conflict resolution diagram is only a way to hold a dialogue. It will not help if people are not ready to spend the time and the effort to describe their point of view or to look for injections.

Conclusion

Three days after that alarming conversation I discussed the importance of open disagreement in a team with one of the "offenders". I mentioned no details and did not even mention that there was a complaint against him. That was still enough for the "offender" to see his mistake. After that he apologised to his teammate and promised to do better.

The conflict was over. In fact it had never existed — there was only the fear of conflict.