Five Dysfunctions of a Team

The Pyramid Nobody Wants to Climb

Every team I’ve ever coached has had at least one moment where the room goes quiet and someone says, “We’re fine. Everything’s fine.” And I think - okay, we’re about to find out which dysfunction we’re standing on.

Patrick Lencioni published The Five Dysfunctions of a Team in 2002 as a leadership fable - a story about a fictional CEO trying to turn around a dysfunctional executive team. The book reads in an afternoon, which is part of its genius. But the model buried inside that fable has outlasted hundreds of heavier management texts because it names something every team member already feels but can’t quite articulate.

Here’s the thing about Lencioni’s model: it’s a pyramid, and it’s sequential. Each dysfunction builds on the one below it. You can’t fix accountability problems if people won’t commit. You can’t get commitment if people won’t argue. You can’t get honest arguments if people don’t trust each other. The pyramid forces you to work from the bottom up - which is exactly what most teams don’t want to do, because the bottom is where the uncomfortable stuff lives.

The model isn’t agile-specific. Lencioni wasn’t writing for Scrum teams or product organizations. He was writing for any team, anywhere, that needed to function as more than a collection of individuals sharing a Slack channel. But the overlap with what agile coaches encounter daily is so direct that this has become one of the first frameworks I reach for when a team tells me they’re “fine.”

Five Layers, One Foundation

The pyramid has five levels. Each one is a dysfunction - a failure mode that prevents the team from reaching the next level of cohesion. They stack. You can’t skip ahead. And the foundation determines everything.

Dysfunction 1: Absence of Trust

This is the base of the pyramid, and it’s the one most teams misunderstand.

Lencioni isn’t talking about predictive trust - “I trust you’ll deliver your code by Friday.” He’s talking about vulnerability-based trust. The willingness to say “I don’t know,” “I was wrong,” “I need help,” or “That thing I said in the meeting was defensive and I’m sorry.”

Teams without vulnerability-based trust spend enormous energy on self-protection. People manage their image instead of solving problems. They position themselves in meetings. They rehearse what they’ll say before saying it. They avoid asking questions that might make them look uninformed - which means the uninformed decisions just keep getting made.

You can spot low trust in the small moments. When someone says “That’s an interesting approach” and means “That’s a terrible idea but I’m not going to say so.” When a developer doesn’t mention they’re stuck until the standup three days later. When the product owner hedges estimates upward because they don’t trust the team to deliver what they committed to.

(This is also why those “trust fall” exercises miss the point so completely. Physical trust and vulnerability-based trust have almost nothing to do with each other. I’ve never seen someone catch a colleague in a trust fall and then suddenly feel safe admitting they have no idea how the deployment pipeline works.)

The antidote isn’t a single exercise. It’s consistent behavior over time - the leader going first in showing vulnerability, people experiencing that honesty doesn’t get punished, and small acts of candor becoming normal rather than heroic. Lencioni suggests personal history exercises, behavioral profiling tools (like MBTI or DiSC), and direct conversation about working styles. All useful. But none of them stick without a leader who models the behavior.

Dysfunction 2: Fear of Conflict

This is the one that makes polite people uncomfortable just reading about it.

When trust is absent, people avoid conflict. Not the destructive kind - nobody’s arguing for more shouting matches. Lencioni means ideological conflict. Passionate, unfiltered debate about ideas, direction, and decisions. The kind of argument where two people disagree strongly, hash it out, and leave the room with a better solution than either of them walked in with.

Teams that fear conflict produce artificial harmony. Meetings are pleasant and unproductive. Decisions happen in hallways after the meeting, between the two or three people who actually have opinions but didn’t feel safe voicing them in the room. Retrospectives surface only the safe topics - “The build was slow” but never “The product owner changed priorities three times and we need to talk about that.”

Here’s the paradox that took me years of coaching to internalize: teams that argue well are teams that trust each other. The arguing is evidence of the trust, not a threat to it. When I watch a team go at it over a technical decision - voices raised, whiteboards getting messy, people interrupting each other with better ideas - I’m watching a team that feels safe enough to be honest. That’s health.

The coach’s job here is to mine for conflict, not suppress it. When a team is too quiet, something is being left unsaid. Asking “Does anyone disagree?” is usually too weak. Try “What’s the strongest argument against this approach?” or “If this decision turns out to be wrong, what will we wish we’d talked about today?” Those questions make disagreement the expected response rather than the disruptive one.

Dysfunction 3: Lack of Commitment

Commitment doesn’t require consensus. This distinction is the heart of Lencioni’s third dysfunction, and it’s the one I find myself explaining most often in coaching sessions.

When teams fear conflict, decisions either don’t get made or get made without real buy-in. People nod in meetings and then quietly pursue their own priorities afterward. The sprint goal gets “agreed to” in planning, but three days in, half the team is working on something else because they never actually believed in the plan - they just didn’t want to argue about it.

Lencioni’s insight is that people don’t need to get their way to commit. They need to be heard. If I’ve made my case passionately, the team has genuinely considered my perspective, and we’ve decided to go a different direction - I can commit to that direction wholeheartedly. I was heard. The decision was informed by my input. I disagree but I’m in.

That’s fundamentally different from the team that skips the debate, picks the safest option, and moves forward with everyone privately skeptical. The first team has commitment. The second has compliance. They look identical in the meeting. They look completely different a week later.

The practical fix is clarity and closure. Lencioni recommends that at the end of every meeting or decision point, someone states explicitly: “Here’s what we decided. Here’s the deadline. Does everyone understand and commit?” Not “Does everyone agree?” - that’s a different question. Commitment means “I will act as if this is my decision, even if I would have chosen differently.”

(In Scrum terms, this maps directly to the Sprint Goal conversation. A Sprint Goal that nobody pushed back on is usually a Sprint Goal that nobody cares about. The pushback is what creates the commitment.)

Dysfunction 4: Avoidance of Accountability

When people haven’t genuinely committed to a plan, they won’t hold each other accountable to it. Why would they? They didn’t buy in. Calling out a teammate for not delivering feels unreasonable when you secretly think the whole plan was flawed to begin with.

Accountability in Lencioni’s model isn’t about the manager watching performance metrics. It’s about peers - teammates holding each other to the behavioral and performance standards the team has set. It’s the developer who says to another developer, “You committed to having that endpoint ready by Wednesday and it’s Friday - what happened?” It’s the Scrum Master who says to the product owner, “You agreed not to change priorities mid-sprint, and you just did.”

Teams that avoid accountability rely entirely on the leader to be the disciplinarian. That’s exhausting for the leader and infantilizing for the team. It also doesn’t scale - the leader can’t be in every conversation, can’t see every missed commitment, can’t catch every time someone lets quality slide because “it’s good enough.”

The most accountable teams I’ve worked with have something in common: they made their standards explicit. Not in a policy document nobody reads, but in a working agreement that lives on the wall (or the Miro board, or the team wiki) and gets referenced regularly. When the standard is visible and shared, holding each other to it feels like teamwork, not policing.

One subtle point here: accountability has to flow in every direction. Senior to junior, junior to senior, across roles. The moment accountability only flows downhill, you’ve lost it. If the newest team member doesn’t feel empowered to say “We agreed to pair on complex stories and we haven’t been doing that,” then the accountability is performative.

Dysfunction 5: Inattention to Results

The top of the pyramid. When teams don’t hold each other accountable, individual priorities overtake collective goals. People optimize for their own career, their own metrics, their own comfort - not for the team’s outcomes.

This doesn’t mean people are selfish. It usually means the team’s goals aren’t clear enough or compelling enough to override the natural pull of individual concerns. A developer focuses on learning a new framework instead of finishing the feature that would actually move the sprint goal forward. A product owner optimizes for stakeholder approval instead of user value. A Scrum Master prioritizes their own certification study over the team’s retro prep.

Lencioni distinguishes between two distractions: team status and individual status. Team status is when people care more about being on a “good” team than about what the team actually produces. Individual status is when personal recognition, career advancement, or ego takes priority over collective results. Both erode outcomes.

The fix is radical clarity about what the team is trying to achieve, measured in ways that everyone can see. Not individual velocity. Not individual story points. Team outcomes. Did we hit the sprint goal? Did the feature ship? Did the customer problem get solved? When the scoreboard is collective, the behavior becomes collective.

(This is one of the reasons I’m skeptical of individual performance metrics in agile teams. The moment you measure individuals, you incentivize individual optimization. Lencioni would call that building Dysfunction 5 into your measurement system.)

The Pyramid as a Diagnostic

One of the reasons this model has legs with agile coaches is that it gives you a sequence. When a team is struggling, the instinct is to attack the most visible symptom. Results are bad? Let’s set clearer goals. Nobody’s being accountable? Let’s add more tracking. Decisions aren’t sticking? Let’s make the product owner more decisive.

Lencioni’s pyramid says: go lower. The visible problem is rarely the root cause. It’s a symptom of the dysfunction below it, which is a symptom of the dysfunction below that.

A team with terrible sprint outcomes (Dysfunction 5) that you try to fix with better goal-setting will fail if the real problem is that people won’t hold each other to their commitments (Dysfunction 4). And accountability interventions will fail if people never genuinely committed to the plan (Dysfunction 3). And commitment work will fail if people won’t debate honestly (Dysfunction 2). And conflict work will fail if there’s no trust (Dysfunction 1).

You almost always end up back at trust. Which is inconvenient, because trust is the hardest one to build and the easiest one to destroy.

This isn’t to say you have to achieve perfect trust before addressing anything else. The pyramid is a model, not a recipe. But it does suggest that if you’re coaching a team and nothing seems to stick, check the foundation. There might be a crack in the base that’s undermining everything above it.

What It Looks Like in the Room

Janelle had been a Scrum Master at a fintech startup for about eighteen months when her company acquired a smaller payments company and merged the two engineering teams. On paper, the combined team was a powerhouse - nine developers, a dedicated QA engineer, two product managers, and enough domain expertise to build practically anything in the payments space.

On paper.

The first two sprints after the merge were chaos. Not the productive kind. The legacy team (Janelle’s original group) had strong opinions about architecture. The acquired team had strong opinions about everything else. Sprint planning felt like a hostage negotiation. Standups were status reports delivered to the ceiling. Retros produced action items that evaporated by Monday.

Janelle’s first instinct was accountability. She tightened up the working agreements, added explicit definition of done criteria, and started tracking commitment versus delivery. Reasonable moves. None of them worked.

The problem was obvious once she stopped treating symptoms. These two groups didn’t trust each other. Not because anyone was untrustworthy - because they were strangers. They’d been thrown together by a business decision, told they were “one team now,” and expected to function like they’d been building together for years.

She scrapped the accountability push and went to the base of the pyramid.

She started with a personal maps exercise - a lightweight Lencioni technique where each person shares a few things about themselves beyond work. Hometown, number of siblings, first job, an unusual challenge they’d faced. Nothing earth-shattering. But a developer named Terrell from the acquired team mentioned that he’d been the primary caregiver for his father during a long illness, and the room shifted. The legacy team had assumed Terrell was disengaged because he left standup quickly and rarely spoke up. It turned out he was managing a crushing personal load and had learned to be efficient with his words, not absent with his attention.

That one moment didn’t fix everything. But it cracked the surface.

Over the next three sprints, Janelle introduced structured conflict. She would present two competing approaches to a technical decision and explicitly ask each sub-group to argue for the approach they liked less. It felt artificial at first - because it was. But it broke the pattern of the legacy team proposing and the acquired team silently accepting (or silently resenting).

By sprint six, something had changed. The two product managers - Elena from the original team and Marco from the acquired side - started having real arguments about priority in refinement. Not polite disagreements. Actual debates with evidence and counterarguments and occasional frustration. After one particularly heated session about payment retry logic, Marco turned to Janelle and said, “That’s the first time I’ve felt like my perspective actually mattered here.”

Commitment followed naturally. When people had genuinely debated the sprint goal and influenced its direction, they owned it. Elena stopped hedging priorities. Marco stopped quietly working on his own backlog items. The team started finishing sprints - not perfectly, but together.

Accountability became organic rather than enforced. Pair programming happened because people wanted it, not because a working agreement mandated it. When someone fell behind, the first question from teammates was “What do you need?” not silence.

By the end of the quarter, the combined team had shipped a unified payment processing pipeline that neither original group could have built alone. Sprint velocity had stabilized. The retros were loud and useful.

At the quarterly review, Janelle’s engineering director asked what she’d done to “fix” the team. She said, “I stopped trying to fix the top of the pyramid and started at the bottom.”

He looked at her blankly. She sent him the book.

Where the Model Has Edges

No framework is complete, and Lencioni’s has some edges worth knowing about.

The model was developed primarily from executive team dynamics. Lencioni’s consulting work focused on leadership teams - small groups of senior leaders who meet regularly and make strategic decisions. Scrum teams, product teams, and cross-functional delivery teams operate differently. The power dynamics are different. The meeting cadences are different. The nature of the work is different.

That said, the five dysfunctions show up everywhere I’ve looked. The manifestations change - a VP’s fear of conflict looks different from a junior developer’s fear of conflict - but the pattern holds across levels and industries.

The model is also deliberately simple. Five layers, one direction, clear causality. Reality is messier. Trust and conflict aren’t purely sequential - they feed each other in loops. A team can have pockets of high trust between certain members and low trust between others. You can have commitment on some goals and not others. The pyramid is a useful simplification, not a perfect map.

Lencioni himself acknowledges this. The model is a diagnostic starting point, not a comprehensive theory of team dynamics. Pair it with other lenses - Tuckman for team development stages, Emotional Intelligence for individual readiness, the Empathy Map for understanding stakeholder perspectives - and you get a richer picture than any single model provides.

One more thing: the model assumes the team is worth fixing. Not every group of people assigned to work together is actually a team, and not every team can be saved by working through the pyramid. Sometimes the composition is wrong. Sometimes the organizational context makes trust impossible (when management punishes vulnerability, no amount of personal history exercises will overcome it). Sometimes the answer is to change the system, not coach the team harder.

The Uncomfortable Truth at the Bottom

I’ve taught this model in dozens of A-CSM classes, and the moment that lands hardest is always the same. Someone - usually a Scrum Master who’s been grinding on accountability for months - looks at the pyramid and says, “We’ve been working on the wrong layer.”

That’s the gift of the framework. Not that it tells you what to do - but that it tells you where to look. And it almost always points you somewhere less comfortable and more important than where you were already looking.

Teams don’t fail because people are incompetent. They fail because the foundation was never built - or was built and then neglected. Trust erodes quietly. Conflict avoidance becomes culture. Ambiguity replaces commitment. And by the time you notice the results are suffering, the root cause is four layers down.

The good news? The pyramid works in both directions. When you invest in trust, conflict becomes possible. When conflict is healthy, commitment becomes real. When commitment is real, accountability becomes natural. And when all four are in place, the results tend to take care of themselves.

Lencioni’s model is simple enough to draw on a napkin and powerful enough to change how a team works. In twenty-plus years of coaching, I haven’t found many tools that fit that description. Keep this one close.

Go Deeper

• Lencioni, P. (2002). The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass. The original book. Read the fable first, then the model summary in the back. It takes about three hours and it’s worth every minute.

• Lencioni, P. (2005). Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators. Jossey-Bass. The practical companion. If the first book is the diagnosis, this one is the treatment plan - exercises, assessments, and facilitation guides.

• Lencioni, P. (2012). The Advantage: Why Organizational Health Trumps Everything Else in Business. Jossey-Bass. Lencioni’s synthesis of his broader body of work, including the Five Dysfunctions model in the context of organizational health.

• The Table Group. tablegroup.com. Lencioni’s consultancy, with free resources including team assessments, podcast episodes, and articles on applying the model.

The Five Dysfunctions of a Team is a registered trademark of The Table Group, Inc. Use of the model in this article is for educational purposes. This article is not affiliated with or endorsed by Patrick Lencioni or The Table Group.