Organizational Resistance to Improvement Suggestions | Generated by AI
Question: For most honest and excellent engineers, is it sometimes hard for them to work in big corporations because they suggest many improvements, which implicitly means previous work had mistakes or imperfections?
Answer: Yes — this often happens, especially in large organizations. Not because excellent engineers are wrong, but because organizational dynamics are different from pure engineering logic.
Here’s why this friction occurs:
1. Improvements implicitly challenge past decisions
When an engineer proposes:
- refactoring architecture
- simplifying design
- removing unnecessary layers
- fixing long-standing technical debt
It indirectly signals:
- “This design is suboptimal”
- “We made mistakes earlier”
- “This could have been done better”
Even if that’s technically true, people may interpret it as:
- criticism of their past work
- questioning their competence
- threatening ownership or authority
So the resistance is psychological and political, not technical.
2. Big corporations optimize for stability, not perfection
Excellent engineers often optimize for:
- correctness
- simplicity
- elegance
- long-term maintainability
Large companies often optimize for:
- stability
- predictability
- low risk
- deadlines
- alignment across teams
So when someone says:
- “We should redesign this”
- “This abstraction is wrong”
- “This system is overly complex”
The organization hears:
- risk
- delay
- coordination cost
- migration effort
Even if the improvement is correct.
3. Ownership boundaries create friction
In big corps:
- every system has owners
- every decision has history
- every change affects multiple teams
An honest engineer may say:
- “This API design is flawed”
- “This caching layer is unnecessary”
- “We should remove this microservice”
But the owner hears:
- “You’re doing it wrong”
- “Your team’s work is flawed”
- “Your roadmap is wrong”
This creates defensive reactions.
4. Excellent engineers see problems earlier
Stronger engineers:
- detect complexity sooner
- notice architectural drift
- care about long-term cost
- dislike accidental complexity
Others may think:
- “It works fine”
- “Not worth changing”
- “Too much effort”
So the excellent engineer becomes:
- the one always pointing out problems
- the one pushing change
- the one creating discomfort
Which can be misinterpreted as:
- negative
- critical
- difficult
- not “team player”
5. Honest engineers don’t play politics
Some engineers soften suggestions like:
- “maybe we can consider…”
- “this is just a thought…”
- “not urgent…”
But very honest engineers often say:
- “This design is wrong”
- “This layer is unnecessary”
- “We should remove this”
- “This is over-engineered”
Technically clear — but socially risky.
6. Ironically, good organizations value this
High-quality engineering cultures want this behavior:
- pointing out flaws
- improving architecture
- reducing complexity
- removing bad abstractions
But weaker cultures interpret this as:
- complaining
- criticizing
- destabilizing
- over-engineering
So the same engineer:
- thrives in strong engineering orgs
- struggles in bureaucratic orgs
7. The best engineers learn how to introduce change
Top engineers don’t stop suggesting improvements — they adjust delivery:
Instead of:
- “This is wrong”
They say:
- “We can reduce complexity here”
- “This might simplify future work”
- “This reduces operational cost”
They frame improvements as:
- business value
- risk reduction
- velocity increase
- team benefit
Same idea — less resistance.
Summary
Yes — excellent and honest engineers often:
- see more problems
- suggest more improvements
- challenge existing systems
And in large organizations this can:
- imply past imperfections
- trigger defensiveness
- create friction
But this is also exactly how systems improve. The key difference is how the suggestion is delivered, not whether it is correct.