Five-tier pyramid representing trust as the foundation of zero trust

Zero Trust Requires a High-Trust Team

By Resolute Security

Field notes from a senior-led security practice

If you’ve spent any time in business books, you’ve probably read Patrick Lencioni’s The Five Dysfunctions of a Team. It’s been around for twenty years and it still holds up. It’s a parable about a fictional executive team learning to function, and the core idea is a pyramid: dysfunctions stack, and you can’t fix the top layer without first fixing the bottom.

The five dysfunctions, in order:

  1. Absence of trust
  2. Fear of conflict
  3. Lack of commitment
  4. Avoidance of accountability
  5. Inattention to results

Now: Zero Trust is the cybersecurity buzzword of the last five years. Reductively, it means “stop trusting your network just because something is inside it.” Every connection, every user, every device has to be verified, every time. It’s a sound architectural model. Most enterprise security strategies are some version of it.

What almost nobody tells you is that implementing Zero Trust at a real organization requires an enormous amount of human trust. The irony is delicious and the practical consequences are brutal. Let me walk through Lencioni’s five dysfunctions and show you, one by one, how they kill Zero Trust projects.

Absence of trust kills your asset inventory

The first job in a Zero Trust deployment is figuring out what you actually have. Every system, every service, every weird application someone in marketing is running on AWS without telling anyone. This requires people to be honest about the things they’re running without permission.

In low-trust organizations, they won’t tell you. They’ve been burned before, IT shuts down anything they don’t recognize, so they hide it. You’ll get an inventory that’s missing 40% of the actual environment. Six months later, when Zero Trust is deployed and you’ve broken a critical workflow no one mentioned, you’ll learn about it in the worst way.

You can’t fix this with technology. You fix it by being the kind of leader people are willing to tell the truth to.

Fear of conflict kills your policy design

Zero Trust requires a thousand small policy decisions. Who needs access to what? Under what conditions? Should this device class be allowed to reach this data class? Most of these decisions involve trade-offs between security and convenience. Reasonable people will disagree.

In a team that avoids conflict, those disagreements never surface. Policies get drafted by IT in isolation, get rubber-stamped by leadership, and the first time the head of sales actually encounters them in the wild, the entire project becomes “stupid IT bureaucracy.” It dies.

Healthy disagreement at the policy design stage produces policies people will actually follow. Teams that can’t fight constructively produce policies people will quietly route around.

Lack of commitment kills your rollout

Zero Trust isn’t a project. It’s an ongoing posture change. Every new system, every new vendor, every new device class has to be evaluated through the same lens.

Teams that don’t truly commit to decisions, Lencioni calls this the “artificial harmony” pattern, where everyone nods in the meeting and then does what they want, will half-implement Zero Trust and then quietly revert when it’s inconvenient. The shiny new identity provider gets deployed. Six months later, the CFO’s laptop has been given a permanent bypass because she “needs to get work done.”

That’s how you end up with the worst of both worlds: the cost of Zero Trust, none of the security benefit.

Avoidance of accountability kills your monitoring

A working Zero Trust environment produces a lot of signals. Anomalous logins. Unusual data access. New devices appearing on the network. Somebody has to look at these. Somebody has to act on them.

In teams that avoid accountability, “somebody” becomes nobody. Alerts pile up. The first time a real incident happens, the post-mortem reveals that the warning fired at 11:43 AM and nobody opened the console until 6:00 PM. Worse, no one is sure whose job it was.

This isn’t a security problem. It’s a management problem wearing a security costume.

Inattention to results kills the whole thing

The final dysfunction. Teams that focus on individual department wins instead of organizational results will measure Zero Trust by output metrics: “We deployed the new MFA system. Phase 2 complete.” Without ever asking the actual question: are we being attacked less? Are we detecting things faster? Are our recovery times shorter?

You can spend $400,000 on a Zero Trust deployment that makes you no safer. I’ve seen it.

The servant-leader angle

The hardest thing about all of this is that none of it is fixable from inside the IT department. The dysfunctions Lencioni describes are leadership dysfunctions. The architecture is a downstream consequence.

If you’re a leader at an SMB and you’re trying to make security work, your most important security investment isn’t a tool. It’s the work of becoming the kind of leader people will tell the truth to, fight productively with, commit to decisions in the room with, hold themselves accountable to, and align on outcomes with. That’s the foundation. Everything else stacks on top.

Zero Trust requires a high-trust team. The irony is the lesson.

Further reading