Mark Needham

Thoughts on Software Development

The 5 dysfunctions of teams in code

with 5 comments

I recently came across an interesting post by my colleague Pat Kua where he talks about how some patterns he’s noticed in code can be linked to Conway’s law which suggests that the structure of systems designed in organisations will mirror the communication structure of that organisation.

I recently read a book called ‘The Five Dysfunctions of Teams‘ which describe some behaviours in teams which aren’t working in an effective way.

Playing the devil’s advocate I became intrigued as to if there is some sort of link between these dysfunctions and whether they manifest themselves in our code as anti patterns.

The five dysfunctions are:

  1. Absence of Trust – team members are unwilling to be vulnerable within the group
  2. Fear of Conflict – team cannot engage in unfiltered and passionate debate of ideas
  3. Lack of Commitment – team members rarely have buy in or commit to decisions
  4. Avoidance of Accountability – team members don’t call their peers on actions/behaviours which hurt the team
  5. Inattention to Results – team members put their individual needs before those of the team

Absence of Trust

I think having null checks all over the code is the most obvious indicator that people don’t trust the code that they are working with.

If the person writing the code had faith in their colleagues who had written the code they now need to interact with then I think it would be more likely that they would trust the code to do the right thing and they wouldn’t feel driven to such a defensive approach.

Fear of Conflict

Fear of conflict in a team seems to manifest itself most obviously in code when we have a lot of duplication happening – there are several reasons why duplication can happen but I think one of them is when people aren’t engaging in discussions when they disagree with something that a colleague has written and therefore end up writing their own version of something that’s already been done.

This probably manifests itself even more obviously when you end up with multiple different frameworks all in the same code base and all doing the same thing just because people don’t want to engage in a conversation to choose which one the team is going to use.

Lack of Commitment

This is one which seems to overlap a lot with the previous two although perhaps one specific way that this would manifest itself in the code might be if we see sloppy mistakes or lack of care being shown with the code – an example of this could be changing the name of a class but then not ensuring that all the places where the old name was used in variables have been changed accordingly.

This leaves the code in a half baked state which becomes quite difficult for other people to work with and they have to do some clean up work before being able to effectively make changes to the code.

Avoidance of Accountability

The coding anti pattern that stands out for me here is when we allow people to write code without tests and then check those into source control.

From my experience so far this never seems to work out well and I think it shows a lack of respect for the rest of the team since we don’t have an easy way of verifying whether this code actually works and other people can’t make use of it elsewhere in the code base with any degree of confidence.

Inattention to Results

Team members putting their individual needs before the team manifests itself in code when we end up with code that has been written in such a way that only the person who wrote it is really able to understand it.

I think this manifests itself in ‘clever code‘ which is fine in your own projects but in a team context is very detrimental as you become a bit of a bottleneck when people want to make changes in this area of the code and can’t do it because they can’t understand what’s going on.

Something else that falls under this dysfunctions is when there is a convention for how to do certain things in the code but we decide to go off and do it our own way. Now granted sometimes it’s fine to do this if you’re working the code towards a better state and the rest of the team are aware you’re trying to work towards this goal but otherwise it’s not a very effective approach.

In Summary

I found it quite intriguing that in my mind at least some of the problems we see in code do seem to have some correlation to the problems that we see in teams.

One thing I remember from reading Gerald Weinberg’s ‘The Secrets of Consulting‘ is his claim that ‘no matter what the problem is it’s always a people problem‘ – if indeed this is true then in theory problems that we see in code should be indicative of a people problem which I think probably to an extent is true.

I think certainly not all problems in code are linked to the dysfunctions of teams – certainly some anti patterns creep into our code due to a lack of experience of team members of how they to do things better but then again maybe that’s indicative of the team not having senior members working closely enough with their colleagues!

Maybe we can therefore work out how we can therefore identify ways that we can improve our team by starting with a look at the code.

Be Sociable, Share!

Written by Mark Needham

May 28th, 2009 at 5:44 am

Posted in Coding

Tagged with ,

  • Andy Marks

    Hiya Mark,

    I too have recently read the book and loved it for the accessible tone and brevity. Kudos for making the connection to coding.

    Given the definitions of the dysfunctions above, I might re-cast a couple slightly:

    – Lack of commitment. Some people in team not using agreed upon patterns or layers when coding. Or not refactoring towards agreed technical vision

    – Avoidance of accountability. When the team doesn’t call out (name and shame, if you will) devs who commit code without tests.


  • Your point of Absence of Trust was where I was coming from with ‘Returning null considered dishonest‘.
    Null checks are a symptom of the fact that you can’t trust that you’ll get back what you want.
    I asked for a Drink and you gave me a null!

  • I love the way you illustrate “people problems” (and, particularly, “team problems”) with code symptoms. It’s definitely a major tool in my consulting tool-kit: “Look at code and ask youself, ‘how did it happen to come out this way?'”

    I want to pick a nit with you statement about “code that has been written in such a way that only the person who wrote it is really able to understand it.” There’s a dangerous assumption there, that the person who wrote such code actually understands it. It’s an assumption that’s more often false than true.

    Overly complex code that nobody but the writer has ever reviewed is extremely likely to be wrong. Indeed, for several reasons, it’s more likely to be wrong than code that’s produced in full cooperation with the team. I’m sure you know this, but it’s easy to forget in the heat of the battle with the person who won’t let others see what s/he’s doing.

    So, when someone claims to be the only one who understands the code they wrote, get rid of the code, then get rid of the person who wrote it.

  • As I read this, I thought of Fowler’s/Beck’s code “smells,” and also Steve McConnell’s good code attributes (cohesion, appropriate coupling, no duplication, good encapsulation…) from his book, _Code Complete_.

    You’ve mapped code dysfunctions to the human drivers (confusions or dysfunctions) that produce such code.

    Very nice! I’ll be pointing to this a lot. Thanks!

  • Hendry Betts


    What a GREAT POST! Thank you. But I have to raise a point about fear of conflict. That is a management issue. If ideas are not encouraged and passionate discussion not fostered (by management) then there is no knowledge of how to get an idea “on the floor.”

    I love the rest of this article and agree that bad code directly relates to bad teams… but more importantly, bad management.