The Five Dysfunctions of Software Teams, Part 1: Absence of Trust

The Five Dysfunctions of Software Teams, Part 1: Absence of Trust

This is the first post in a six-part series exploring The Five Dysfunctions of a Team through the lens of modern software engineering.

I recently read The Five Dysfunctions of a Team because a company I interviewed with said they base their culture on it. I was curious whether it would feel like generic leadership advice or something that actually mapped to real work.

It resonated with me more than I expected, especially as an individual contributor.

Not because the ideas were flashy or new, but because they described patterns I have seen repeatedly in engineering organizations that otherwise look healthy. Smart people. Reasonable processes. Solid intentions. And still, things quietly break down.

The first dysfunction, absence of trust, sits at the base of Lencioni’s model. If it is present, everything above it struggles. In software teams, it often shows up in subtle, normalized ways.

What lack of trust looks like in engineering

On software teams, lack of trust rarely looks like open hostility. It looks like:

• Engineers avoiding areas of the codebase they do not “own”

• Over-reliance on one or two people who “know how it works”

• Pull requests that get approved without meaningful review

• Bugs fixed in isolation instead of discussed in the open

• Retrospectives that stay shallow and polite

None of this feels dramatic. That is why it is so dangerous.

How this breaks agile in practice

Agile assumes trust. Not as a nice-to-have, but as a prerequisite.

Consider what agile asks teams to do:

• Share unfinished work early

• Inspect and adapt frequently

• Surface blockers quickly

• Learn from failure without blame

Without trust, those practices turn into rituals instead of tools.

Daily standups become status reporting instead of problem solving.
Sprint reviews show only safe, polished work.
Retrospectives avoid the real issues because no one wants to look incompetent or difficult.

The process keeps running, but the learning stops.

The myth of the “strong IC”

As individual contributors, many of us learned that being good means being self-sufficient. You debug alone. You figure it out. You do not slow others down with questions.

That mindset feels professional, but it creates brittle teams.

When trust is low:

• Knowledge stays siloed

• Onboarding takes forever

• Bus factor drops to one or two people

• The team cannot respond well to change

Ironically, the more everyone tries to look strong individually, the weaker the team becomes.

Trust is built through small, visible behaviors

Trust on engineering teams is not built through offsites or trust exercises. It is built in the work.

From an IC perspective, that looks like:

• Asking questions early, especially basic ones

• Narrating your thinking in pull requests

• Admitting when you broke something, quickly and publicly

• Pairing or mobbing on risky changes

• Writing down what you learn instead of keeping it in your head

These actions feel vulnerable, especially in cultures that reward speed and certainty. But they are exactly what allow agile practices to work as intended.

Blamelessness is not about being nice

Blameless postmortems are often misunderstood as being soft. They are not.

They are about shifting focus from “who messed up” to “how did the system allow this to happen.”

When teams trust each other:

• Incidents become learning opportunities

• Engineers speak honestly about near-misses

• Fixes address root causes, not just symptoms

Without trust, postmortems become performative or avoided entirely. The same failures repeat under new names.

A practical takeaway for ICs

You do not need to be a manager to improve trust on your team.

Pick one behavior and practice it consistently:

• Ask the question you think you should already know

• Say “I do not understand this yet” in a design discussion

• Call out uncertainty instead of masking it with confidence

Agile is not about moving fast. It is about learning fast.
Learning fast requires trust.
And trust starts with individual contributors being willing to be seen as human.

---

Up next: Part 2 will look at Fear of Conflict, and how avoiding disagreement in design reviews and architectural discussions quietly erodes software quality.

Series note:
This post is part of a six-part series applying The Five Dysfunctions of a Team to software engineering, with a focus on how these patterns show up in day-to-day work for individual contributors.

If this resonated, the next post explores Fear of Conflict and how avoiding disagreement in design reviews, pull requests, and architectural decisions quietly degrades code quality and team health.

You do not need to be a manager to influence any of this. You just need to notice the patterns and decide how you want to show up in them.