From Psychological Safety to Dependability: How Teams Learn to Deliver
In the first part of this series, we explored psychological safety - the foundation that allows teams to speak openly about risks, doubts, and mistakes. But safety alone is not enough. Teams can feel safe, have great discussions, and still fail to deliver.
This is where the second factor identified in Project Aristotle comes into play: dependability.
Many teams work hard. Few are truly dependable.
What Dependability Really Means
In the context of Project Aristotle (conducted by Google), dependability means that team members can rely on each other.
In practice:
- commitments are met,
- work is delivered on time,
- quality is predictable,
- risks and delays are communicated early.
Dependability is not about perfection. It is about predictability.
A dependable team is one where you don't need heroics to feel confident about delivery.
What Dependability Is Not
This distinction matters, especially in engineering teams.
Dependability is not:
- working late nights to "save" a sprint,
- saying yes to everything and hoping it works out,
- overloading yourself to protect others,
- constantly firefighting.
A team can look extremely busy - and still be unreliable.
Hero culture often hides poor dependability instead of fixing it.
Why Teams Struggle With Dependability
Most teams don't fail because they don't care. They fail because of structural and cultural issues.
Common causes include:
1. Overcommitment
Teams promise more than they can realistically deliver. Estimates become wishes, and deadlines become pressure tools.
2. Lack of psychological safety
Without safety, people delay bad news. Problems are raised late, when options are limited and stress is high.
3. Blurry ownership
If responsibility is unclear, commitments feel optional. Tasks move forward, but accountability does not.
4. Rewarding heroics
When saving a project is praised more than preventing failure, teams learn the wrong lesson.
Dependability cannot exist without psychological safety - but safety alone does not create dependability.
What Dependability Feels Like for a Team Member
For an individual contributor, dependability means:
- expectations are clear,
- commitments are realistic,
- asking for help is acceptable,
- delays are discussed early, not hidden.
In dependable teams, planning feels calm. In unreliable teams, planning feels like gambling.
The difference is not effort - it is trust.
The Cost of Low Dependability
When dependability is missing, the consequences are very real:
- constant replanning and priority changes,
- erosion of trust between teams,
- increasing technical debt,
- burnout caused by last-minute pressure,
- reduced influence of the team within the organization.
A team that cannot be trusted to deliver gradually loses autonomy - even if it is highly skilled.
The Role of the Tech Lead in Building Dependability
Dependability does not emerge by accident. It is actively shaped - and Tech Leads play a central role.
A Tech Lead supports dependability by:
- pushing for realistic commitments, not optimistic ones,
- clearly distinguishing estimates from promises,
- encouraging early communication of risks,
- protecting the team from chronic overcommitment,
- valuing consistency over heroics.
Perhaps most importantly, Tech Leads model what it means to renegotiate commitments when reality changes.
Tech Lead Anti-Patterns That Undermine Dependability
Some behaviors quietly destroy reliability, even when intentions are good:
- "Let's take more - we'll figure it out"
- ignoring early warning signs of delays,
- changing scope without renegotiating deadlines,
- praising last-minute saves instead of prevention,
- treating missed commitments as personal failures instead of system signals.
These patterns create pressure, silence, and eventually distrust.
Dependability Builds on Safety - and Enables Impact
Psychological safety allows teams to speak honestly. Dependability ensures that honesty turns into results.
Without safety, teams hide problems. Without dependability, teams talk - but don't deliver.
Together, these two factors form the bridge between healthy collaboration and real impact.
What's Next?
Dependability answers the question: "Can we rely on this team?" The next factor from Project Aristotle explores something equally important: "Do we know what is expected of us?"
In the next article, we'll look at structure and clarity - and how unclear roles and expectations quietly sabotage even strong teams.
Comments