One of the biggest myths in the software industry is that great engineering teams are built by hiring great engineers.
They aren't.
I've worked with incredibly talented developers who eventually became disengaged, indifferent, and unwilling to contribute beyond the bare minimum. I've also worked with average developers who grew into exceptional engineers because they were surrounded by a culture that rewarded curiosity, ownership, and continuous improvement.
The difference was never talent.
The difference was culture.
The Toxicity Nobody Talks About
When people hear the term toxic workplace, they usually imagine shouting managers, impossible deadlines, public humiliation, and constant pressure.
Those environments certainly exist.
But some of the most damaging engineering cultures are far more subtle.
On the surface, everything appears professional. Meetings are calm. Nobody raises their voice. Everyone speaks politely. The company presents itself as collaborative and mature.
Yet beneath that polished exterior exists a culture that quietly destroys accountability and discourages anyone from caring too much.
A Simple Pull Request That Revealed a Bigger Problem
Recently, while reviewing a pull request, I asked a few straightforward questions:
- Why are we passing an empty string to a component that doesn't function without an ID?
- Why is a skeleton component living in a file where it doesn't logically belong?
- Could this conditional statement be simplified for readability?
These weren't major architectural concerns.
They weren't requests to redesign the application.
They were ordinary engineering discussions—the kind that happen every day inside healthy teams.
When Ownership Disappears
What happened next was far more interesting than the code itself.
Instead of discussing whether the observations were valid, the conversation immediately shifted toward ownership.
Who originally wrote the code?
Who moved the code?
Who was responsible for introducing it?
The discussion was no longer about improving the software. It became an exercise in distancing people from responsibility.
And that is one of the earliest warning signs of a toxic engineering culture.
In healthy teams, once code appears in your pull request, you own it.
It doesn't matter whether you originally wrote it. It doesn't matter who committed it first. What matters is whether the code deserves to exist in its current state.
The goal is improvement.
The goal is quality.
The goal is collective ownership.
Toxic teams think differently.
In toxic environments, survival becomes more important than ownership. Engineers learn that admitting flaws creates risk while avoiding responsibility creates safety. Over time, that behavior becomes normalized.
People stop asking:
"Can we improve this?"
And start asking:
"How can I avoid being associated with this?"
Death by a Thousand Compromises
Software systems rarely collapse overnight.
They decay slowly.
A redundant condition remains because nobody wants to touch it.
An unnecessary abstraction survives because nobody wants to revisit it.
A poorly organized file structure grows larger because nobody wants to challenge it.
Technical debt accumulates not because engineers fail to recognize problems, but because the culture actively discourages solving them.
The Most Dangerous Phrase in Engineering
During the review, one response stood out.
A discussion about simplifying code was quickly dismissed as:
"Personal preference."
At first glance, the phrase seems harmless.
Sometimes it is.
But in many organizations, "personal preference" has become a convenient escape hatch for avoiding technical discussions altogether.
Once a topic is labeled subjective:
- No evidence is required.
- No trade-offs are discussed.
- No reasoning needs to be presented.
- No improvement needs to happen.
The conversation simply dies.
Over time, organizations become intellectually stagnant.
Code reviews stop being collaborative quality exercises and become ceremonial approvals.
Engineers stop challenging decisions because experience teaches them that meaningful discussions will be dismissed before they begin.
Everyone remains "productive."
Tickets get closed.
Pull requests get merged.
Velocity charts look great.
Meanwhile, quality quietly declines.
The Leadership Failure
The most revealing moment came later.
After attempting to discuss these concerns with leadership, I received a response that can be summarized as:
"If you care about it so much, do it yourself."
That single response revealed a much bigger problem than any code review ever could.
Leadership is not about agreeing with every suggestion.
Leaders are allowed to disagree.
Leaders are allowed to prioritize delivery over refactoring.
Leaders are allowed to reject ideas.
Those are legitimate business decisions.
But leaders cannot dismiss the act of raising concerns itself.
The moment initiative becomes an inconvenience, organizations start teaching employees not to take initiative.
The moment curiosity becomes annoying, people stop asking questions.
The moment ownership becomes a burden, people stop taking ownership.
And eventually, the company gets exactly what it trained its people to become.
The Illusion of Alignment
Many leaders mistake silence for success.
Pull requests receive fewer comments.
Meetings become shorter.
Disagreements disappear.
Everyone appears aligned.
But often, what has actually disappeared is engagement.
The most dangerous moment in any company is not when engineers complain.
It's when they stop complaining.
Complaints mean people still care enough to fight for a better outcome.
Silence often means they have accepted that nothing will change.
By the time leadership notices the consequences:
- The best engineers have mentally checked out.
- Technical debt has accumulated for years.
- Product quality has declined.
- Delivery slows despite increasing effort.
The organization begins searching for technical explanations to what is fundamentally a cultural problem.
Final Thoughts
Toxic companies rarely fail because they hire bad engineers.
More often, they fail because they systematically teach good engineers that caring is a waste of time.
Every ignored concern.
Every dismissed discussion.
Every attempt to avoid ownership.
Every leader who responds with "Do it yourself then" instead of engaging with the problem.
These are not isolated incidents.
They are symptoms of a culture that rewards compliance over excellence.
And once an organization successfully teaches its engineers that caring is pointless, recovering from that lesson becomes far more difficult than fixing any bug, refactoring any system, or rewriting any codebase.
Top comments (0)