Did you ever wonder why you’re (again) in a meeting without a clear result? Do you feel like the topics got already discussed in a previous meeting? How often did your hear the sentence “Someone should work on that.”? Let’s be honest, our work family is sometimes a little dysfunctional. Join me in my personal reflection of the book The Five Dysfunctions of a Team: A Leadership Fable from 2002 by Patrick Lencioni, which helps to understand what’s happening.
Date | Change description |
---|---|
2017-12-08 | The first release |
As said in the overview, this book is not focused on software development as such, but on team internal interaction. As I’ve experienced software development as mostly driven by people interacting with each other, it makes sense to understand how we can socially fail as a team. Recognizing symptoms is also an important part of preventive social maintenance actions.
The book tells the story with an executive team of a company but you can map the behaviors and symptoms to your development team as well. The dysfunctions get described in depth and in a concise form. It lists symptoms of the dysfunctions, and more importantly, lists possible ways to resolve them.
If you’re not convinced by now, the next section will contain very specific examples from the book, which might give you a better understanding where I come from.
Well, it’s easy to pick the 5 most noteworthy things this time. I’ll start each point with a citation of the book and add my 2 cents right after it.
[...] teammates must get comfortable being vulnerable with one another. [This includes] weaknesses, skill deficiencies, interpersonal shortcomings, mistakes and requests for help.
I remember the kickoff meeting of an older project I was part of. When confronted with the questions and uncertainties we had, the technical lead said very often “I don’t know.”. This impressed me back then, as I felt that most people don’t (like to) admit missing knowledge or skill and simply wing it in the hope you don’t notice. Missing trust allows the next dysfunction to manifest.
[Teams] in productive conflict know, that the only purpose is to produce the best possible solution in the shortest period of time.
If you don’t trust your co-worker to have the best solution in mind, and that co-worker criticizes one of your ideas, you might get the impression that you get criticized as a person and defend yourself (in disguise of defending your idea). As the other person recognizes that the criticism doesn’t lead to a better solution but to hurt feelings, they stop doing it. So they try to find ways to work around each other. Questions for dedicated ownership, where you have the last say by definition, might arise. Discussions might come to a stop with a “Let’s take this offline.”, which then doesn’t happen. You’re not a team anymore, but a group of people which is not able to discuss the hot topics anymore, so you stagnate.
[...] causes of the lack of commitment are the desire for consensus and the need for certainty.
This is my favorite. It allows having meeting over meeting where we discuss (or better: talk) about the same problem over and over again without making a decision. Another form this can take is, having a list of work items where nearly every work item has the highest priority. If everything has a high priority, nothing has.
While this dysfunction is already harmful when happening on the low organizational level I work, imagine the pain when this happens through multiple levels of company hierarchy, where the negative impact get amplified with each level, and then it hits the practitioners by having no clear goals or visions.
My personal flaw here, is that I tried too often to reach a consensus with all participants in the past. I rarely succeeded with that approach. I’m still in the phase of trying different approaches.
[...] team members who are particularly close to one another sometimes hesitate to hold one another accountable [...]. [This] causes the relationship to deteriorate as team members begin to resent each other for not living up to expectations and for allowing the standards of the group to erode. [...] The enemy of accountability is ambiguity.
Did your team wrote some kind of guideline how the work needs to be done or which quality it needs to have? Is that document maybe two years old and it gets followed only sporadically or maybe not at all? Did you hear or say the sentence “Somebody should enforce this guideline somehow.”? The three dysfunctions from before brought you this mess.
As we are all very smart people, we create measurements or goals which are ambiguous. This avoids accountability right from the start, as an interpretation is needed. The pinnacle of this is, to never write anything down, but only do it verbally. Now you can use the powerful phrase “I did get that differently when we discussed this.”. I’m getting cynical here, but I think you get the idea.
[...] the tendency of members to care about something other than the collective goals of the group [...] [like] team status and individual status [...].
The fifth dysfunction can arise when your team doesn’t trust each other, doesn’t touch the hot topics, cannot make reliable decisions and creates ambiguity to avoid accountability. All you have left now is focusing on your personal status or keep the team status for the status’s sake. Results, which increase the value to your customers, are rare. The team members are working mostly on other stretch goals. The outcome decreases with every week.
This book gave me a lot of insights and I enjoyed reading and learning from it. Especially us IT folks, where work consists of interaction with many people, can benefit from reading it. It’s important to notice that a dysfunction is not standalone but influences the other dysfunctions as well.
Even if you cannot resolve the issues your team has, at least having a hint why it happens, can ease the pain. Go buy and read the book. It’s worth it.