Building psychological safety as a technical discipline

Last year, during a retro, one of our developers said something that made me pause.
“I always wait until someone else speaks first. If no one says anything, I assume I shouldn’t either.”

That sentence said more about our culture than any dashboard ever could. And this was a good team, engaged, experienced, no obvious dysfunction. They had just quietly learned to wait.

Silence. Something about silence makes me sick. Zack de la Rocha said it first, but I’ve felt it in every meeting where no one speaks. Silence means problems are being discovered late, decisions are being made on incomplete information, and learning is being replaced by luck.

We describe psychological safety as a soft skill. I’ve come to see it as infrastructure: something that requires deliberate design, regular feedback, and ongoing maintenance.

The social architecture behind delivery

In Peopleware: Productive Projects and Teams, Tom DeMarco and Timothy Lister describe something most managers already feel in their gut. Software projects rarely fail because of code or tools. They fail because of the way people work together. The book came out in the 1980s, but its lessons still apply. Every time I see talented engineers hesitate to speak up, I think of their line:

The major problems of our work are not so much technological as sociological.

You can build the perfect process, yet if people hold back ideas or concerns, everything slows down. It’s not visible in Jira or your metrics, but you feel it in the room.
That’s the hidden architecture of delivery.

Treat it like an engineering system

If psychological safety behaves like a system, we can build it like one. Not with slogans or all-hands talks, but with habits that compound over time.

Retrospectives are diagnostics, not just process. Notice who speaks and who doesn’t. Notice whether the same people always go first. Notice whether critical feedback gets raised in the room or shows up in someone’s DM afterward.

Watch for delays in raising issues. When something goes wrong on a project, how long does it take for the team to surface it? A team with high safety surfaces problems while there’s still time to fix them. A team without it surfaces them at the demo.

Look at participation across your workflows. Who comments on pull requests? Who proposes changes in planning? Who stays silent in architecture reviews? The pattern across a few weeks tells you something about what feels safe.

The most important signal is how a manager reacts when things go wrong. That reaction defines the system more than any process does. If the first response is blame, people learn to hide problems. If the first response is curiosity, “what happened, what did we miss, what can we change,” people learn it’s safe to bring things forward early.

When managers create noise

A few years ago, I realized how fragile trust can be. During a review, I interrupted an engineer mid sentence to correct a detail. I thought I was being efficient. Later, she told me she stopped sharing early ideas after that meeting.

Looking for language to explain what went wrong, I read Radical Candor by Kim Scott. She worked at Google and Apple, and her book explains a simple idea: great leaders both care personally and challenge directly. It’s not about being nice or avoiding conflict. It’s about creating enough trust that people can be honest, even when it’s uncomfortable.

Since then, I’ve tried to listen longer before reacting. It’s slower in the moment, but faster in the long run.

Build for resilience, not perfection

We design systems that degrade gracefully, logging errors, retrying failed requests, and surfacing problems clearly rather than failing silently. Teams need the same design philosophy.

The goal isn’t to remove every risk or eliminate every mistake. It’s to make it easy to talk about risks early, surface mistakes quickly, and treat both as information rather than failure.

The developer who told me she stopped sharing early ideas after I interrupted her? She eventually came back to doing it. It took about three months of me consistently listening before she did. That’s how long it can take to rebuild something you damaged in an afternoon.

Psychological safety is invisible when it’s working. You notice it in the retrospectives that surface real problems, in the engineers who flag a risk before it becomes an incident, in the planning sessions where someone says “I think we’re underestimating this” and the room takes it seriously instead of moving on.

It’s infrastructure. It’s built slowly, damaged easily, and worth protecting deliberately.

Recommended reading