Even if they make others unconformtable!

After a long career in software and systems engineering, one of the hardest lessons I’ve learned is this: your technical instincts matter, and staying silent when you believe something is wrong can cost everyone dearly.

The Cost of Staying Silent

Early in my career, I was terrified of speaking up when my gut told me something wasn’t right. I learned this lesson during a production incident that should have been resolved in hours, not days.

Our queue system, which processed thousands of messages per minute, suddenly started failing intermittently. No configuration changes. No deployments. Just mysterious, sporadic failures that brought our system to its knees.

The company spent four days investigating. We suspected the servers first, then the software, and finally turned to the network. The entire development and DevOps organizations agreed on one thing: the network team was overconfident about their infrastructure. When we raised network concerns, they categorically denied any issues. To be fair, there weren’t any obvious indicators pointing to network problems.

Note: This isn’t meant to be an incident management story—the incident response experts at uptimelabs.io could probably identify numerous process issues with how we handled this situation. But that’s not the point I’m making here.

My manager asked me to write a script to help diagnose the issue. I created a Python script on a Windows server in the same network to test queue connectivity. The first thing I did after writing the script was run pip install for dependencies.

It failed with RST packet errors.

Right then, I knew we had a network issue. But I caved. What did I know about networks? I was fresh out of university with only theoretical knowledge and Cisco Packet Tracer labs under my belt. I never spoke up.

That was my first mistake.

Three days later, the datacenter team finally identified a malfunctioning network switch at the gateway—a single port sending RST packets and causing all our problems. If I had raised my concerns on day one, we could have solved this immediately instead of having engineers work sleepless nights for three days.

The Pattern of Self-Doubt

Looking back over several years and countless similar situations, I see a clear pattern: I kept caving on things I believed were right, and it made a huge difference—always for the worse.

Whether it was tool selection, framework choices, or implementation decisions, staying silent when my technical instincts screamed “this is wrong” consistently led to problems down the road.

Making Hard Decisions: The Right Way

I’ve learned that making hard decisions is not only important—it’s easier than caving in and regretting it later. But there’s a right way to do it.

Wrong approach: “Can we change this tool? It’s causing a lot of overhead.”

Right approach: “I’m moving from X to Y due to these specific reasons. If anyone has objections, please speak up now.”

The difference is ownership and clarity. You’re not asking permission; you’re making an informed decision and opening the floor for technical discussion.

This approach will make your life easier as an engineer and help your team avoid unnecessary pain. Communication is key—you need to clearly explain your reasoning, but you shouldn’t let fear of conflict override sound technical judgment.

Navigating the Social Dynamics

Of course, this approach can backfire. Colleagues might see you as arrogant or hot-headed. The challenge is making hard decisions while maintaining good working relationships and team cohesion.

The key is understanding that technical courage isn’t about being confrontational—it’s about being constructively assertive. When you make a decision, lead with data, past experience, and clear technical reasoning. Make it about solving the problem, not about being right or proving your expertise. People respond better when they understand you’re trying to prevent future pain, not just flex your technical knowledge.

You also need to choose your battles wisely. Not every technical disagreement needs to be a hill to die on. Save your political capital for decisions that truly matter to system reliability, performance, or maintainability. If you’re constantly pushing back on every small decision, people will tune you out when something critical comes up.

Building relationships before you need them is crucial. When people trust your technical judgment and know you’re not trying to show off, they’re more likely to listen when you do speak up. This means being collaborative on day-to-day work, acknowledging others’ expertise, and admitting when you’re wrong.

Finally, acknowledge uncertainty when it exists. Saying something like “Based on my experience with similar systems, I believe X will cause problems, but I could be wrong” is often more persuasive than absolute statements. It shows intellectual humility while still conveying your concerns.

I sometimes fail to follow these. After all, we are only human. But we need to learn from mistakes.

The Role of Company Culture

The best companies create cultures that encourage this kind of technical courage, and it’s not something that happens accidentally. It requires intentional effort from leadership and team members alike.

Psychological safety is the foundation. Engineers need to know they won’t be punished for raising concerns, even if they’re wrong. This means celebrating the times when someone’s gut instinct saves the day, but also not penalizing people when their concerns turn out to be unfounded. The goal is to create an environment where people feel safe to speak up.

Healthy technical disagreement should be normalized and modeled by senior team members. When experienced engineers disagree constructively, it shows the team that different perspectives lead to better solutions. It’s not about winning arguments; it’s about finding the best technical path forward.

Companies that do this well also prioritize learning from both successes and failures. When someone’s technical instinct prevents a major issue, the team discusses what happened and why. When concerns turn out to be unnecessary, that’s also valuable learning. This creates a feedback loop that helps everyone calibrate their technical judgment over time.

Clear decision-making processes also help. Everyone should understand who has the authority to make certain technical decisions and how those decisions get communicated. This reduces ambiguity and makes it easier for people to know when and how to raise concerns.

The Bottom Line

In a work environment, when your gut tells you something is technically wrong, don’t cave. Your instincts are often based on pattern recognition from years of experience—note that I did not say industry experience. The experience from your university or even personal day-to-day life is still experience, even if you can’t immediately articulate why something feels off.

The cost of being wrong is usually much lower than the cost of staying silent when you’re right. And as you gain experience, you’ll get better at distinguishing between valuable technical intuition and unfounded concerns.

Your technical judgment matters. Use it.