What AI Does to the Five Dysfunctions of a Team


A few weeks ago our bi-weekly “connection hour” at Checkr went back to Patrick Lencioni. Our first session had been on The Ideal Team Player — humble, hungry, smart — which is a book about what makes a great individual teammate. This time we picked up its older sibling, The Five Dysfunctions of a Team, which is about what breaks a team as a whole. I have read it twice, but both times were several years ago, and I deliberately didn’t reread it before the session. I wanted to see what had actually stuck, and then hold that against the way our team works today, with AI agents sitting in every code review and half our meeting notes being written by software. What stuck was the pyramid. What surprised me was how differently each layer of it reads now.

For anyone who hasn’t read it (or, like me, read it long enough ago that the details have faded), Lencioni’s model is a pyramid of five dysfunctions, each resting on the one below it. Absence of trust is the foundation: people who can’t be vulnerable with each other. That produces fear of conflict, where a team settles for artificial harmony instead of honest debate. Without real debate you get lack of commitment, because nobody truly weighed in, so nobody truly bought in. That leads to avoidance of accountability, since it is hard to hold a peer to a decision they never really agreed to. And at the top sits inattention to results: individual status and ego quietly outrank the collective outcome.

The book was written in 2002. Not one of the five is about tooling. That is exactly why I think it is worth asking what happens to each layer when a large part of the team’s daily output is now produced with — and sometimes by — AI.

Trust: vulnerability gets cheaper and harder at the same time

Lencioni’s trust is not predictive trust (“I know you’ll ship on time”). It is vulnerability-based trust: I can say “I don’t know,” “I was wrong,” or “I need help” without it costing me anything.

AI changes the economics of that in two directions. On one hand, saying “I don’t know” is cheaper than it has ever been, because the gap between not knowing and knowing is now often a two-minute conversation with a model. Nobody needs to protect their ego over an unfamiliar library or an obscure part of a legacy codebase anymore. That should make vulnerability easier.

On the other hand, AI gives everyone a very good mask. An engineer who is struggling can produce polished, confident-looking pull requests, design docs and status updates without ever admitting to a human that they are struggling. The output looks like competence. The team never gets the signal that someone needs help, and the person never gets the experience of being helped. I think managers now have to actively create the moments where people show their actual understanding — walking through a design live, explaining a change in their own words — not because we distrust the work, but because those are the moments where vulnerability-based trust actually forms.

Conflict: the machine is the most agreeable person in the room

Fear of conflict is the dysfunction I worry about most in this new era. Lencioni’s argument is that healthy teams have passionate, unfiltered debate about ideas, and that the absence of it is a symptom, not a virtue.

Here is the problem. Most AI assistants, by default, are extraordinarily agreeable. Ask one to critique your plan and it will find three thoughtful concerns and then tell you the plan is strong. Ask it to write the counter-argument and it will, politely, and then reassure you. If a team member increasingly pressure-tests their ideas against an AI before bringing them to the group, the ideas arrive pre-validated, pre-rehearsed, and much harder to challenge. The human debate that should have happened got replaced by a rehearsal with an audience that was never going to say no.

We have started to treat this deliberately. A model is an excellent devil’s advocate if you make it one — “argue that this design is wrong and will hurt us in production” is a very different prompt from “review this design.” But even then, the AI’s disagreement doesn’t carry the weight of a colleague’s. Someone on the team looking at you and saying “I think this is a mistake” is doing something the tool structurally cannot, which is risking a relationship for the sake of the outcome. That is the conflict Lencioni is talking about, and no amount of AI critique substitutes for it.

Commitment: it is easy to mistake a generated plan for a decision

Lack of commitment, in the book, comes from ambiguity: people leave a meeting unclear on what was decided, or clear on what was decided but not having actually bought into it, because their perspective never really got heard.

AI has made a specific version of this much more common. A meeting ends, the AI note-taker produces a crisp summary with a section titled “Decisions” and another titled “Action Items,” and everyone reads it and nods. But the summary reflects what was said, not what was agreed. A confident statement from a senior person in minute twelve becomes a “decision” in the recap even if two people in the room disagreed and didn’t push back. The artifact looks like commitment. It isn’t.

The same thing happens with plans. It has never been easier to produce a thorough-looking roadmap, RFC or project plan. The document quality has gone up dramatically. But a beautifully structured plan that one person generated in an afternoon has none of the buy-in that a rougher plan argued into shape by the whole team has. Lencioni’s fix for lack of commitment is clarity plus closure: at the end of a discussion, explicitly restate what was decided and who is responsible. I would add a 2026 amendment — someone human should read the AI’s “Decisions” section out loud and ask, “Did we actually decide this?”

Accountability: more to review, and a convenient third party to blame

Avoidance of accountability is about peers being unwilling to call each other out on behavior or performance that hurts the team. Lencioni notes, correctly, that this is uncomfortable, and that most teams route around it by making the manager the sole enforcer.

AI adds two wrinkles. The first is volume. When individual output multiplies, the amount of work each person is nominally accountable for multiplies too, and the surface area for things going wrong grows with it. In a domain like ours, where a mistake in a criminal background check can materially affect someone’s ability to get a job, “the model wrote that part” is not an answer anyone will accept from us. The human who shipped it owns it. Every team using these tools has to say that explicitly, because the default drift is toward diffused responsibility.

The second wrinkle is subtler. AI is a very convenient third party. “The agent introduced that regression” is a sentence that sounds like an explanation and functions as an excuse. Peers who would never blame a colleague for a bug find it easy to blame the tool, and easy to let a colleague blame the tool. I think the accountability conversation has to move upstream: not “who wrote the bug” but “who reviewed it, who tested it, and what did we decide about how much we trust generated changes in this part of the system.” Those are peer-to-peer questions, and they are exactly the kind Lencioni says healthy teams are willing to ask each other.

Results: personal productivity is not a team outcome

The top of the pyramid is inattention to results: the team’s members care more about their own status, their own department, or their own career than about the collective goal.

The AI version of this dysfunction is the cult of personal throughput. It is very tempting, and very visible, to measure how much an individual produces now — lines of code, pull requests, docs, tickets closed. Those numbers are going up almost everywhere, and people are understandably proud of them. But none of them are the result. The result is whether the product is more accurate, more reliable, and more useful to the customer than it was last quarter. A team where everyone is individually two times more productive and the system is no more trustworthy has not improved; it has just generated more material for someone else to verify.

Lencioni’s prescription here is a public scoreboard tied to collective outcomes, and I think that is more important now, not less. The team should be looking at the shared metrics — quality, latency, incidents, customer impact — far more often than it looks at anyone’s individual output. Otherwise the tooling quietly rewires what people optimize for.

The pyramid still holds

What struck me most, coming back to the model after years away from the book, is how little it needed updating. Every one of the five dysfunctions is a human dynamic, and every one of them is made easier to hide by tools that produce confident, polished output on demand. AI does not create these dysfunctions. It laminates over them.

That leaves managers with a job that has arguably gotten harder. The signals we used to rely on — the rough draft, the hesitant question, the plan with obvious holes — were unpleasant, but they were honest. They told us where trust was thin, where debate hadn’t happened, where a decision was really just a strong opinion. As those signals get smoothed away, we have to go looking for the real ones deliberately.

So the question I’ll leave you with is the one I’m still sitting with: in your team, when the AI writes the summary, the plan, and the code, what is left that only a human can be vulnerable about — and are you making room for it?

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.