In my last blog post, I talked about people problems in software development and why addressing them is so important. This time I want to continue this discussion by talking about friction. The term “friction” describes any kind of interpersonal disagreement. Friction can be productive if it is used to generate better ideas. For example, if two developers disagree about how a certain feature should be built, they may come up with a better idea as a result of their discussion then what either of them had originally in mind. This is productive friction. Sadly, there is also a lot of unproductive friction in the workplace, i.e., disagreements about topics which aren’t all that important. Unproductive friction distracts people from productive work and causes resentment if arguments get too heated. Here are some examples of unproductive friction:

  • Arguing about seating in the office.
  • Arguing about whether the whole team has to do test-driven development (TDD).
  • Arguing about whether all team members should use the same setup for their local development environments.

In the grand scheme of things, the answer to any of these questions doesn’t matter. Discussing them can be beneficial if a quick decision can be reached, but any prolonged discussion will have more downsides than upsides. This kind of unproductive friction can be highly corrosive if there are lingering personal conflicts in the team and/or if you have team members who just like to argue.

Both productive and unproductive friction need to be managed. To keep friction productive, we need to make sure that the discussion stays on topic, remains civil and that the correct participants are involved. Participants in the discussion need to have at least somewhat compatible personalities and working styles. Otherwise, the discussion will devolve into unproductive friction very quickly. Also, the participants need to be qualified and familiar with the topic to generate better ideas. While we encourage productive friction, we want to minimize unproductive friction. To do this, we empower team members to work according to their individual needs. This should avoid many discussions where alignment in the team isn’t actually necessary (e.g., whether TDD is used). Also, we should timebox every discussion if we suspect that it’s unproductive. After the allotted time is up, we either have to make a decision or decide not to make one. Making the wrong decision is preferable to revisiting the same topics again and again because no shared position can be found in the development team. Last, as managers, we need to make sure that we don’t create any unproductive friction ourselves. We should let the team work as it sees fit even if it clashes with our own preferences as long as there is no clear problem. For example, let’s assume that we have on-call-duty on weekends and only a small subset of the team volunteers for this task. We might be tempted to force the rest of the team to participate to split the work more fairly, but this can cause unproductive friction if the team as a whole is fine with the status quo. Why rock the boat if the volunteers aren’t bothered by the on-call-duty or even need the extra money? As long as no one in the team asks us to do something, we should let things go their natural way to minimize unproductive friction.

Conclusion

Friction needs to be managed. Good managers will keep productive fraction productive and minimize unproductive friction. Individual empowerment is key to minimize unproductive friction. Often, it is not important that everyone in the team does things the same way.

If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.