The Most Dangerous Bug in Engineering Teams Is Silence

What separates great teams from average ones?

Most people expected the answer to be obvious.

Talent.

The strongest engineers. The most experienced technical leads. The smartest people in the room.

But that wasn't what Google found.

The strongest predictor of team effectiveness was psychological safety: whether people believed they could speak up, admit mistakes, ask questions, challenge ideas, and raise concerns without negative consequences.

The finding came from Project Aristotle, Google's multi-year research into team performance.

And yet, years later, psychological safety is still often treated as an HR topic.

A culture initiative.

Something discussed during an offsite.

I think that misses the point.

Psychological safety is not the soft side of engineering.

It is an engineering system property.

Because every engineering team depends on one thing before it can build reliable software:

Accurate information.

And silence is what happens when important information gets trapped inside people's heads.

The dangerous bugs are often the ones nobody reports.

Think about how we debug production systems.

A service is unhealthy. A metric stops moving. An alert fires.

The first question is:

"What signal did we miss?"

Engineering teams work the same way.

A developer sees a risk but does not mention it.

A reviewer does not understand a design but approves anyway.

An engineer notices a pattern causing repeated incidents but stays quiet.

A teammate is blocked for days but says everything is "on track."

The problem is not that the team lacks intelligence.

The problem is that the system is losing signals.

And when a system loses signals, failures become inevitable.

You can usually see psychological safety through the artifacts teams already create.

No surveys required.

Start with standups.

Every team has blockers.

That is not a sign of failure. Complex engineering work creates uncertainty.

The question is whether people surface it quickly.

On a healthy team:

That sentence starts collaboration.

On an unhealthy team:

The words sound fine.

The timeline quietly slips.

The blocker gets more expensive.

The team does not have fewer problems. It has fewer visible problems.

The absence of "I'm stuck" is not evidence that nobody is stuck.

It is evidence that saying it has a cost.

Code review is one of the best places to observe team safety.

Two unhealthy patterns appear repeatedly.

The first is silence.

A large change arrives. The reviewer leaves one comment:

"LGTM."

Not because they fully understand the design.

Because asking questions feels uncomfortable.

"What happens if this dependency is slow?"

"Why did we choose this approach?"

"Can you walk me through this tradeoff?"

Those questions are not challenges to the author.

They are how engineering works.

The second pattern is the opposite.

A review filled with dozens of comments about naming, formatting, and minor style preferences.

But no discussion about architecture, scalability, failure modes, or operational risk.

Nitpicks are easy.

They feel safe because they do not challenge decisions.

The important conversations are often the uncomfortable ones.

When reviews avoid those conversations, the questions do not disappear.

They simply move to production.

There is a moment in incident retrospectives where you can feel the room change.

Someone asks:

"Who wrote this code?"

Or:

"Who approved this change?"

The conversation immediately shifts.

People stop investigating and start defending.

The team is no longer trying to understand the failure.

It is trying to avoid becoming the failure.

But the most valuable information in an incident is not who made the mistake.

It is which assumption failed.

What did we believe would happen?

Why was that belief reasonable at the time?

What signal did we miss?

What system change prevents this class of failure?

The goal of an incident review is not to find the person closest to the problem.

It is to make sure the organization learns faster than it fails.

A blameless process only works when the room is actually safe.

Otherwise, you get a meeting that is technically blameless but emotionally defensive.

The timeline gets documented.

The action items get assigned.

The important sentence never gets spoken:

"Here is what I misunderstood."

That sentence is where learning begins.

Design reviews are another powerful signal.

Watch what happens when a senior engineer presents an idea.

Do people ask difficult questions?

Do people challenge assumptions?

Does someone junior feel comfortable saying:

"What happens when this queue backs up?"

"What happens during a partial failure?"

"Are we assuming this dependency is always available?"

On a strong team, disagreement moves in every direction.

Experience earns influence, but it does not create immunity from questions.

On an unsafe team, disagreement only flows downward.

Senior people challenge junior people.

Junior people approve senior people's ideas.

The result looks like alignment.

But sometimes it is just silence wearing alignment's clothes.

We measure everything in engineering.

Latency.

Availability.

Error rates.

Deployment frequency.

Incident recovery time.

But we rarely measure the signals that create those outcomes.

Consider these as team health indicators:

How often does someone say "I'm blocked"?

How many risks are raised before implementation starts?

How many design reviews contain meaningful questions?

How many incident retrospectives identify failed assumptions?

How often does someone challenge a decision regardless of seniority?

These are not culture metrics.

They are system health indicators.

A team that cannot surface reality cannot improve reality.

The good news is that improving this does not require becoming a manager.

Small behaviors change the system.

Ask:

"What are we missing?"

before asking:

"Are we good?"

Ask:

"What could fail?"

before asking:

"When will it be done?"

When someone raises a concern, pay attention to your reaction.

That moment teaches everyone watching.

"Good catch. Let's explore it."

Creates a very different environment than:

"Why didn't we think of this earlier?"

Credit people for finding problems, not just solving them.

The person who finds the issue early saved the team time, even if they did not write the fix.

And one of the simplest habits:

Speak last.

When the most senior person shares an opinion first, many people unconsciously adjust their thinking around it.

Questions create space.

Answers close it.

The best leaders create environments where the best idea wins, regardless of who said it.

We spend our careers building reliable software systems.

We add observability.

We remove single points of failure.

We improve feedback loops.

We design for failure.

Teams need the same thinking.

Silence is a missing signal.

A missing signal becomes a hidden risk.

A hidden risk eventually becomes an incident.

The most dangerous bugs in software are not always the ones with obvious errors.

They are the ones nobody notices until it is too late.

The same is true for engineering teams.

The question is not whether your team has problems.

Every team does.

The question is:

Does your team know how to surface them before they become expensive?

What is one signal that told you a team was safe enough to speak honestly?

Originally published at https://www.linkedin.com.