Why Psychological Safety is a Productivity Metric

25 Nov 2025

In this series, we’ve explored the visible friction in software teams: the flow killers, the product mistakes, and the technical debt that slows everything down.

But there is one final category of waste that sits underneath all the others. It’s the hardest to see and often the most damaging:

cultural waste.

When a team’s culture is anxious, fearful, or disempowered, every other waste grows. Cognitive load rises. Communication becomes muddled. Rework becomes inevitable. Even simple work feels harder than it should.

This final post looks at the human cost of waste.

1. Psychological Distress

This is the cost of burdening the team with unhelpful stress.

Psychological distress is intrinsically wasteful. Some pressure can be energising, but everyone has a limit. Beyond that limit, stress becomes distracting and draining. It makes people anxious, overwhelmed, and unmotivated. When a developer is worrying about interpersonal conflict or fearing blame for a mistake, they are not solving problems, they are managing their own safety.

Common causes of this waste:

• Rush mode: A constant state of emergency where everything is a priority 1.
• Low morale: Often linked to a lack of agency, unclear expectations, or feeling undervalued.
• Interpersonal conflict: Unresolved friction that drains emotional energy.
• Fear of failure: A culture where mistakes are punished rather than treated as learning opportunities.

How to reduce this waste:

• Prioritise Psychological Safety: Build an environment where team members feel safe to take risks and be vulnerable in front of each other.
• Review your “Rush Mode”: If everything is urgent, nothing is. Protect focus time.
• Team Essentials: Run sessions to define team norms and address interpersonal friction early.

2. Disempowerment (The Process Waste)

This is the waste created when smart people are treated like cogs in a machine.

Many organisations still operate on a “demand–deliver” model. Decisions flow top-down, and teams are expected to execute without context or autonomy. When this happens, you’ll get process waste: pointless documentation, unnecessary approvals, and rigid adherence to ceremonies over value.

It also creates the handoffs problem. Tom and Mary Poppendieck estimated that around 50% of knowledge is lost with each handover. After five handovers, you’re left with roughly 3% of what you started with.

In other words, every handoff is a knowledge leak.

How to reduce this waste:

• Empower teams: Shift from top-down instruction to clear, mission-based goals. Let teams decide how to deliver.
• Eliminate handoffs: Move towards cross-functional teams where design, code, and deployment happen together.
• Question the ceremony: If a meeting, document, or ritual doesn’t add value, remove it. Don’t let the framework/methodology become the work.

Conclusion: Waste Reduction IS DevOps

We started this series by defining waste as friction.

Whether it’s a messy backlog, a confusing codebase, or a fearful team, waste is what stops us from delivering value.

Reducing that waste isn’t a side quest, it is DevOps.

Good DevOps practices like automation, continuous delivery, small batches, and blameless culture are essentially waste-reduction strategies.

By identifying these nine wastes, we stop treating symptoms and start curing the disease.

1. See the waste.
2. Name the waste.
3. Remove the waste.

“If we can see the waste, we can name it.”
“If we can name it, we can remove it.”

That is how you build a high-performing team.