When Fear Makes Good Engineers Go Quiet

Aug 30

8 min read

AI is not only changing how quickly we work. It is changing what people believe they are allowed to admit while they work.

There is a moment I recognize from more than twenty years in technology.

Someone is looking at a piece of code.

Perhaps they wrote it. Perhaps a colleague did or they googled the solution ... Perhaps, now, an AI generated most of it in seconds.

Something does not feel quite right.

They cannot yet explain why.

There is no failing test they can point to. No obvious vulnerability. No neatly packaged evidence that will justify delaying the release. Just experience tugging quietly at their sleeve, asking them to look again.

So they have a choice.

They can say:

I do not understand this well enough to approve it yet.

Or they can stay silent.

We like to believe that choice belongs to the individual. That careful engineers speak up and careless engineers do not. That courage is a personality trait some people bring to work and others somehow forgot to develop.

But that moment does not begin with the engineer.

It begins much earlier, in every message the organization has sent about what it values.

🖤 What happens when leaders repeatedly celebrate speed but barely notice prevention?

🖤 What happens when AI is introduced through stories of replacement rather than possibility?

🖤 What happens when people are told to experiment, but mistakes are remembered longer than learning?

🖤 What happens when an engineer who asks for more time must build a courtroom case, while the person pushing for the deadline needs no evidence at all?

By the time someone chooses silence, leadership may already have made honesty too expensive.

Fear changes the meaning of competence

One of the most seductive promises of AI is that we will no longer need to spend so long not knowing.

Ask the question. Generate the answer. Produce the code. Summarize the system. Create the test. Move on.

There is enormous value in that. I use AI. I teach leaders about AI. I believe it can make us more capable.

But real engineering has never been the absence of uncertainty.

It is the discipline of working responsibly inside it.

Good engineers do not know everything. They notice what they do not know. They test assumptions. They follow the uncomfortable thread. They recognize when an answer is plausible but not trustworthy. They understand that a green check mark can tell us a test passed, but not whether we tested the thing that mattered.

That requires the freedom to be unfinished for a while. Yet in a fearful organization, uncertainty begins to look like incompetence.

If an AI can offer an answer immediately, the human who says, “I need to investigate,” can appear slow.

If a colleague can generate a feature in an afternoon, the person asking how it behaves under failure can appear obstructive.

If leadership has already announced the productivity gains, the engineer who questions whether those gains are real can appear resistant to change.

So people learn to perform certainty.

They approve what they only partly understand.

They present generated output as finished thinking.

They replace “I do not know” with language that sounds reassuring enough to keep the work moving.

And the organization mistakes confidence for competence.

This is where fear becomes more than an emotional wellbeing issue. It becomes an information-quality problem.

The truth is still present in the organization. People can feel the gaps. They can see the fragility. They know where the rushed decisions are buried.

But the truth can no longer travel.

Silence is not the absence of insight

Leaders often discover risk very late and ask why nobody raised it earlier.

Usually, somebody did.

Perhaps not in a steering committee or a status report. Perhaps it appeared as hesitation in a refinement session. A question in a pull request. A sentence that began, “This may be nothing, but…” A request for another day of testing. A concern softened so carefully that it became easy to ignore.

Sometimes people raise a risk once, watch how the organization responds, and learn everything they need to know.

Was curiosity welcomed?

Was the concern explored?

Or did the room immediately ask them to prove the danger, defend the delay and personally absorb the cost of being right?

Psychological safety is often described as feeling comfortable enough to speak.

I think that description is too gentle for what is at stake.

In engineering, psychological safety is part of the organization’s sensing system.

It determines whether weak signals reach the people who can act on them. It determines whether uncertainty is examined or hidden. It determines whether a near miss becomes shared learning or a private secret.

Silence does not mean there was no insight.

It may mean the system trained people not to offer it.

We are separating responsibility from power

There is another contradiction beneath the pressure to move at AI speed.

We tell engineers that AI can perform more of the work.

Then we tell them they remain fully accountable for everything it produces.

Accountability matters. A human cannot mindlessly merge generated code and point at the tool when something breaks.

But responsibility without the authority to slow down is not accountability.

It is exposure.

If an engineer is responsible for understanding the code, they need time to understand it.

If they are responsible for security, they need the authority to challenge a deadline.

If they are responsible for quality, prevention and maintenance must count as work, not as inconvenient detours from delivery.

If they are responsible for the consequences of AI use, they need approved tools, clear boundaries, and a safe way to reveal how AI contributed.

We cannot remove people’s discretion in the name of speed and then rediscover their accountability when something fails.

Yet that is exactly what many organizations are in danger of doing.

The deadline is decided elsewhere. The productivity target is decided elsewhere. The tooling may be selected elsewhere. The message about keeping pace with AI comes from elsewhere.

But when the vulnerability reaches production, responsibility suddenly becomes very personal.

“Who approved this?”

“Why didn’t engineering catch it?”

“Why wasn’t this escalated?”

This teaches a devastating lesson: you may not have the power to make the work safe, but you will carry the blame if it is not.

No wonder people protect themselves.

Fear does not always look like panic

When we picture fear at work, we may imagine visible distress: conflict, exhaustion, someone saying they feel unsafe.

But organizational fear is often much quieter and much more productive-looking.

It looks like the engineer who works late to review code privately because asking for more time would expose them.

It looks like the team that quietly uses an unapproved AI tool because the official process cannot meet the expectation placed upon them.

It looks like a pull request receiving a quick approval because everyone else is also under pressure.

It looks like tests written to confirm that generated code works, rather than to challenge how it might fail.

It looks like a concern reclassified as “technical debt” so that today’s deadline can remain untouched.

It looks like impressive velocity.

Until it does not.

That is why speed driven by fear is so dangerous. The damage can remain invisible while the dashboards look healthy.

Work is moving. Tickets are closing. Output is increasing. The organization congratulates itself on successful AI adoption.

Meanwhile, understanding is thinning.

Small uncertainties are accumulating.

Review is becoming theatre.

And people are learning that care is something they must practice secretly, if they have time for it at all.

What we measure becomes moral

Metrics do more than show people how the organization is performing. They teach people what a good person does here.

If we celebrate only what ships, the person who prevents a failure becomes invisible.

If we count generated output but not the effort required to verify it, verification begins to look like waste.

If we praise the leader whose team moves fastest, without examining what that speed leaves behind, speed becomes a virtue in itself.

This is how a delivery preference becomes a moral hierarchy.

Fast people are committed.

Cautious people are resistant.

Confident people are capable.

People with questions are falling behind.

Once those meanings take hold, no AI policy will be enough to make usage safe. The written rules may say “human oversight required,” while the lived culture says “do not be the human who slows us down.”

Culture will win.

It nearly always does.

Trust is part of the technical architecture

We often treat trust as something soft that leaders attend to after the serious engineering decisions have been made.

I believe that is a profound category error.

Trust shapes what information enters the system.

Trust affects whether people expose mistakes early, while they are still inexpensive.

Trust determines whether engineers reveal how they are really using AI, allowing the organization to learn and create better guardrails.

Trust gives people permission to distinguish between code that exists and code they are prepared to stand behind.

That makes trust part of security.

Part of quality.

Part of resilience.

Part of every technical decision that depends on a human being saying,

“Wait. We need to look at this again.”

The strongest organizations will not be those where nobody makes a mistake with AI.

That organization does not exist.

The strongest will be those where mistakes, uncertainty, and unexpected consequences become visible quickly enough to learn from them.

That visibility cannot be automated into existence.

Leaders have to make honesty survivable.

The leadership work is not reassurance

It is tempting to respond to fear by telling people not to be afraid.

“AI is here to support you.”

“People will always be important.”

“We value quality too.”

Those messages may be well intended. But people do not decide whether they are safe by listening only to what leaders say.

They watch what happens next.

They watch what happens when a deadline is challenged.

They watch whether the person who admits they do not understand generated code is coached or judged.

They watch whether leaders sacrifice scope when responsible review needs more time or quietly sacrifice the review.

They watch who is rewarded, what is measured and whose discomfort matters.

Trust is not created by reassurance. It is created by evidence.

So the leadership work is concrete.

Make room in plans for verification, not merely generation.

Ask what became less understood as delivery became faster.

Reward the discovery of risk before it becomes an incident.

Treat “I don’t know yet” as the beginning of responsible inquiry, not an admission of inadequacy.

Give engineers genuine authority to stop or slow work when the consequences justify it.

Examine whether your AI targets are increasing capability or simply transferring anxiety down the hierarchy.

And when the same unsafe behavior appears across several teams, resist the convenience of blaming several individuals.

Look for the instruction the system is giving them.

The question beneath the question

The obvious question for leaders is:

How do we help our people move faster with AI?

But perhaps the more important question is:

What must remain true while we move faster?

Can people still tell the truth?

Can they still exercise judgment?

Can they still ask for time without defending their worth?

Can they still care for the parts of engineering that are difficult to count?

Can they still challenge the machine, the deadline and us?

Because the real danger is not that AI becomes capable enough to replace human judgment.

It is that fear makes human beings too quiet to use it.

And then, one day, leaders will stand in the consequences of that silence and ask why nobody warned them.

The answer may be painful.

They did.

We just created an organization in which warning us no longer felt safe.

At Avagasso, I work with leaders who want to create more than output. Leaders who want to build the trust, courage and human conditions that allow people to think clearly, speak honestly and take real responsibility, especially while technology is changing around them.

Explore The Leadership Leap, The Leadership Landing Program, and The Leadership Boost at avagasso.com.

Human leadership is not the counterweight to technological progress.

It is how we make that progress worth trusting. 💚🔥🐉