TL;DR
Lencioni’s pyramid of team dysfunction maps directly to why so many engineering teams struggle with velocity and quality—they’re not actually teams, they’re collections of smart individuals avoiding hard conversations. I’ve learned that technical brilliance without trust and conflict resolution creates exactly the organizational debt this book diagnoses.
About the Book
“The Five Dysfunctions of a Team” presents Lencioni’s foundational model through the story of CEO Kathryn Petersen rebuilding her dysfunctional executive team at DecisionTech. The five dysfunctions form a pyramid: absence of trust at the base, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results at the top. Lencioni’s central thesis is that teams fail not from lack of talent, but from behavioral dysfunction that prevents them from working cohesively toward shared goals.
The book argues that vulnerability-based trust—where team members can admit mistakes and weaknesses—is the foundation for everything else. Without it, teams can’t engage in productive conflict, which means they can’t achieve genuine commitment to decisions, which eliminates accountability, which ultimately leads to prioritizing individual concerns over collective results.
Where This Resonates With My Experience
Build the Team Before It Is Needed aligns perfectly with Lencioni’s trust-building framework. He writes:
“Remember, teamwork begins by building trust. And the only way to do that is to overcome our need for invulnerability.”
I’ve seen this firsthand when rolling out AI-powered code review tools across engineering teams. The teams that succeeded weren’t necessarily the most technically sophisticated—they were the ones where engineers felt safe saying “I don’t understand this recommendation” or “I think the model got this wrong.” This mirrors a lesson I learned the hard way: technical initiatives fail more often on trust than on technology. My rule now is that any AI tool rollout requires explicit vulnerability exercises before deployment.
Communicate Directly Without Hesitation maps to Lencioni’s emphasis on productive conflict. As he puts it:
“Teams that engage in productive conflict know that the only purpose is to produce the best possible solution in the shortest period of time.”
This reinforced something I’ve observed repeatedly—the highest-performing product teams I’ve built have been the ones where engineers will directly challenge product decisions in planning meetings, not the ones where everyone nods politely and then works around decisions they disagree with. When we were deciding whether to build our own ML infrastructure or use vendor solutions, the breakthrough came when my most senior engineer finally said, “I think you’re wrong about build vs. buy, and here’s why.” That conflict led to a hybrid approach that saved us six months.
Face Up to the Truth & Adapt Plans connects to Lencioni’s commitment dysfunction. He emphasizes:
“If people don’t weigh in, they can’t buy in.”
This gave language to a pattern I’d noticed but hadn’t articulated well. In quarterly planning, I’ve learned that silence during decision-making always becomes resistance during execution. Now I explicitly ask, “What concerns aren’t we voicing?” before finalizing roadmaps.
Where I Push Back
I’m more skeptical of Lencioni’s optimism about conflict resolution in high-stakes technical environments. He advocates for extensive team-building exercises and suggests:
“The key is to make it safe for everyone to bare their souls.”
While I agree with vulnerability-based trust, I won’t scale this approach across all technical teams because the time investment doesn’t always justify the returns. In my experience, some engineering teams function well with task-focused trust—they trust each other’s technical judgment without needing deep personal vulnerability. I’ve seen forced team-building exercises backfire when engineers viewed them as performative rather than genuine.
I also push back on the book’s assumption that all team members want the same level of interpersonal connection. Lencioni writes about teams needing to “know one another on a personal level,” but I’ve found that some of my strongest contributors prefer to maintain professional boundaries. My approach is to create psychological safety around work decisions and technical discussions rather than requiring personal disclosure.
How This Influenced My Leadership
- I started conducting “pre-mortems” where teams explicitly discuss what could go wrong with major technical decisions, making Lencioni’s productive conflict concept concrete for engineering contexts
- I implemented “commitment checks” in planning meetings—before finalizing any roadmap decision, I ask each team member to state their level of commitment and any remaining concerns
- I changed how I handle technical disagreements, now insisting that dissenting opinions be fully aired in the room rather than allowing them to surface later in Slack or one-on-ones
- I developed a personal heuristic: if a team meeting ends without any disagreement being expressed, I’ll schedule follow-up conversations to surface what wasn’t said
Who Should Read This
This book is essential for any leader inheriting a dysfunctional technical team or building teams from scratch. It’s particularly valuable for engineering managers who are strong technically but struggle with team dynamics, and for product leaders who need to coordinate across multiple engineering teams. If you’re dealing with teams that have talent but can’t ship consistently, or if you notice decisions getting relitigated after meetings, this book provides a clear diagnostic framework.
Rating
Strong Alignment