Book Review: The Five Dysfunctions of a Team

I was recently given a copy of this book (The Five Dysfunctions of a Team by Patric Lencioni) by a co-worker. It is a pretty easy read. The majority of the book is a narrative/story about “Kathryn” taking over as CEO of a company with a very dysfunctional senior leadership team. She walks her new team through their dysfunctions and points out ways to deal with them.

The 5 dysfunctions talked about in the book are: Absence of Trust, Fear of Conflict, Lack of Commitment, Avoidance of Accountability and Inattention to Results.
Reading through the examples displayed by the team described in the book, I could certainly see some of them in the teams I work with and have worked with in the past. “Kathryn” gives clear guidance on how to deal with these dysfunctions.

The last chapter or so steps out of the story and gives clear definitions, examples and suggestions for solutions to the various issues. It does not make the assumption that all teams are the same, but gives several different techniques to help overcome each of the dysfunctions, and points out that they are all inter-related. You rarely have only 1 of the dysfunctions, but instead have many or all but at different levels of dysfunction.

Given the relatively easy read and the quality of the information, I would recommend this to anyone who leads a team. It’s equally good if you are just part of a team and not leading it, so you can work toward avoiding the dysfunctions at least as 1 member of the team.

Advertisements

Challenge your preconceptions

I worked with a gentleman once upon a time whose ideals around software development were the polar opposite of mine.  He held a higher position in the company than me or my team and we often suffered from decisions he made.

For many years we worked at the same company, but never on a project together and for that I was thankful.  Then, one fateful day I was put on a project alongside him.  I was hoping that he would simply act as a domain expert and leave the software planning to me.

Alas, that was not meant to be.  I walked into his office to talk about how we were going to tackle this project, expecting to have to defend my approach and found out that he was very receptive to my ideas.  As we continued to work together, I was continuously surprised that we held the same views on a number of things.  There were still things that we held opposing views on, but there were certainly a lot more points where we agreed than I would ever have imagined.

Sound familiar?

Is there someone that you work with, or know, that you think is your opposite?  They don’t believe in anything that you do?  They are stubborn and unwilling to change or listen to your ideas?

I think we all have someone like this in our lives.  I would challenge you to get to know that person a little better.  Talk to them, take them to lunch (a group lunch might work well if there is a lot of animosity between the two of you).  Try to drop all of your preconceived notions about them and learn who they really are.  You probably have a lot more in common with them than you would ever have realized.

If you can see someone as “like you” rather than “other”, working with them will become much easier.  You will be more likely to empathize with them than demonize them.

Egoless programming == Jerkless Programming

As an agile enthusiast, I am a big proponent of the concept of egoless programming.  Jeff Atwood’s post The Ten Commandments of Egoless Programming sum up the concept quite nicely.

I got to thinking about this idea of egoless programming, and I have a problem with the name.  I really think we should call it something like “Jerkless Programming” or “Considerate Programming”.

The problem I have with the name “egoless” is that it ignores that the ego is not in and of itself bad:

From Dictionary.com, definitions 3&4:

egotism; conceit; self-importance:

Her ego becomes more unbearable each day.

self-esteem or self-image; feelings:

Your criticism wounded his ego.
As we can see, the ego is how you see yourself.  The word “ego” is often used when we mean that a person has an inflated ego (or they think more highly of themselves than others do).  These are the people I want to avoid working with.
The ego allows us to feel good about ourselves when we write good code, clean up technical debt, etc.  I want to work with people who have a healthy ego, and are working to nurture their self-esteem by caring for the code and the team.  If we tried to remove ourselves from our emotions, we would become drones and would have little drive to improve the structure of the code if it were working.
So, please, bring your ego’s to work!  Care for them, nurture them, but be realistic.  Look very closely at yourself in the mirror, listen to feedback and be a considerate teammate.

Mean teacher

At work, we just hired a couple of summer interns from the local high school.  It is my job to be their mentor and project manager.

Today we held our first estimation session, and after it was over I was aware that I had come off rather brusquely.  This is a personality trait that I am well aware of in myself and am working on.  I asked my colleague if he noticed it and said he did, but he is used to it.

So, I decided to apologize to the interns for my manner.  Their response:
“That’s ok.  We’ve had mean teachers before.”

Communication & Tone

I am part of a group of game masters who run events at conventions.  At one of the large game conventions, our group is allowed to break the rules somewhat.  Typically all board games go in area A, all role-playing games in area B and so on.  Since we have a large group that runs a variety of events and we run them back to back, we are allowed to have our own space and run all of our events there.

In the last couple of years one of our group has taken over as liaison between us and the convention.  He has been doing an incredible job, our relationship with the convention has improved tremendously.  A big reason for this is he understands the importance of tone.

Two examples

Example the first:
The Boss asks for a task breakdown for a project that is not yet well defined.

Response A:
I can’t get you that.  That project is not fleshed out!

Response B:
I can’t get you that, because the project is not defined well enough yet.  But, I can give you a high level idea of what broad-stroke things we will likely need to do.  It won’t be at a level where people can start working on it, but might be helpful for planning.

See the difference?  In both responses we are saying that we are unable to provide “The Boss” with what he/she is asking, but, in the response B, we are offering an alternative.  That little act shows that we are hearing the need and are willing to work with the other person.

Example the second:
The product owner suggests an enhancement and you see some problems that you will face down the road if you follow the path laid out.

Response A:
If we do that, then we will have to deal with issues A, B & C.

Response B:
If I understand correctly, we want to add this enhancement to allow customers to do x which they currently are doing manually.  With the current proposal, we may run into some issues.  Do you mind if I do a little research to see if there are alternative solutions that will allow us to achieve the same goal?

Again, in our second example, we are stating that there are issues with the current proposal, but we are offering to work with the other person to make sure their goals are met.

That was easy

Not so fast!  My contrived examples make it seem very easy, but in reality we need to check ourselves when we are in a conversation.  Emotions often get in the way and lead us to answer with response A.  We may very well want to help the other individual, but we are not expressing it to them, and they cannot read our minds.

The second example is especially problematic for software engineers used to working and speaking with other software engineers.  I know this is an issue I deal with.  I am used to pointing out issues we will face and having the rest of the team jump in with ideas to address the issues.  So much so, that I expect this same behavior no matter who I am speaking with.

We aren’t always going to have an alternate approach to suggest right then, but I think it is fair to ask for some time to do some research.

Where do I go from here?

Tone is important in all of our interactions, not just at work.  It takes a lot of self-awareness to notice when we are coming off with a negative tone.  But, with practice you can improve your communication skills, and come off as a winner instead of a whiner.