The Engineer Who Stayed Quiet
What happens when engineers choose to stay quiet at the wrong moment.
Dear Readers,
In this post, I will talk about:
Why software engineers usually get fired?
Kunal’s story: how not surfacing a design risk led to a failure in production.
The difference between invisible work and visible communication.
A simple challenge to make your thinking louder in everyday updates.
Most engineers don’t lose their jobs because they wrote bad code. They lose them because they stayed quiet.
I used to work with an engineer named Kunal.
Kunal wasn’t the loudest voice in the room. In fact, he was the kind of engineer every manager loves: reliable, never missed deadlines, never complained. But that reliability came with silence.
When requirements were vague, he just assumed and started coding.
When timelines were unrealistic, he pulled late nights instead of pushing back.
When he noticed flaws in the design that might cause scaling issues down the line, he kept it to himself.
Each time, silence felt easier than debate. Until it wasn’t.
Three months later, exactly what Kunal had feared came true. The API couldn’t handle the surge in traffic. Latency spiked. Upstream services started failing. Customers complained. Leadership was in midnight war-room calls. And the hardest part? Kunal had seen it coming all along. He just never said it out loud.
That’s when I realized something important:
You can ship bugs and still keep your job. But if you don’t communicate risk, you become the risk.
Invisible work doesn’t get you promoted.
Invisible problems get you replaced.
And the truth is, many of us have a little bit of Kunal in us. We notice risks but tell ourselves, “I’ll just work harder to cover it up.” We think silence will protect us, but it only isolates us.
The best engineers I’ve seen don’t just write great code. They make their thinking visible. They clarify the scope. They surface risks early. They translate technical trade-offs into business clarity. And because of that, people trust them.
If you want to become indispensable, don’t just improve your coding skills. Improve how loudly and clearly you share your thinking.
So here’s a small challenge for you this week: in your next standup or update, don’t just share what you did. Share one risk you see, one trade-off you’re making, and one thing you need clarity on.
Small, consistent signals build big trust.