The Five Dysfunctions of a Team

What it’s about

Patrick Lencioni tells the story of a new CEO taking over a struggling tech company’s executive team, a group of talented people who don’t function as a team. Through the fable he builds a model of five dysfunctions stacked like a pyramid: absence of trust, fear of conflict, lack of commitment, avoidance of accountability and inattention to results. Each one makes the next possible.

What I learned

Trust is the foundation. Lencioni means vulnerability-based trust: being able to say “I was wrong” or “I need help” without it being used against you. Without it, everything above it is performance.

Conflict is healthy. Teams without trust avoid disagreement, so decisions get made in corridors and nobody challenges a bad idea in the room. Productive conflict about ideas is a sign of a healthy team, not a broken one.

Commitment needs to come after debate. People can commit to a decision they argued against, as long as they were heard. Skip the debate and you get polite agreement and quiet non-commitment.

Peer accountability beats top-down accountability. The strongest teams hold each other to standards, rather than waiting for the manager to.

Collective results over individual status. When people optimise for their own team or their own reputation, the shared outcome suffers.

What I applied

The book was given to me at Elanco, early in my career. I used it to think about team dynamics on a large, distributed web team, and it was the first time I started deliberately thinking about what kind of leader I wanted to be, before I had the title.

Those thoughts got sharper in a mentoring session a couple of years later, where we talked about growing a team that shares knowledge. The lessons I wrote down then line up with Lencioni’s pyramid almost exactly: empower people rather than force them; lead by example, because people copy what you do, not what you delegate; build a coaching culture that knows who wants to grow and who is happy where they are; and be consistent and predictable, with regular check-ins that aren’t overbearing and no micromanagement.

I got to test them when I chaired a cross-team UI guild at Sky. The hard part wasn’t the agenda; it was creating enough trust for engineers from different teams to disagree openly about technology choices and to admit where their own codebases were struggling. Writing the problems down first, keeping a regular, predictable format and including team health checks did more for that trust than any single decision (Chairing a Cross-Team UI Guild).

Where it connects

Chairing a Cross-Team UI Guild · Pair Programming · Communicating with Stakeholders · The Phoenix Project · Building Digital Culture