I stayed quiet in meetings for years


Hello Reader,

A few months ago, I spoke with an engineer who described a design review he could not stop thinking about.

It was a standard meeting. A dozen people on the call, a couple of senior voices leading the conversation and a solution that already felt decided before anyone joined. Halfway through, he noticed a scaling issue that would only show up during edge cases.

He thought about bringing it up then he looked at the room. A senior engineer had already said it looked good. The meeting was running fine and everyone wanted to move on to the next item on the agenda so he said nothing.


A few months later, the system failed in production. During the postmortem, someone asked why the issue had not been raised earlier. He sat there knowing he had seen it coming and feeling that familiar mix of frustration and self blame.

When he told me the story, he said something that stuck with me: "I did not stay quiet because I did not care. I stayed quiet because I did not know how to disagree without making things worse."

Most engineers have a version of this story.


The false choice engineers learn early

Somewhere along the way, many engineers internalize a simple rule:

You can speak up and risk being seen as difficult or you can stay quiet and keep the peace.

Neither option feels great.

Staying quiet leads to decisions you do not believe in. Speaking bluntly can damage trust and relationships that matter long term. Over time, silence starts to feel like the safer bet even when it costs the team.

The problem is not that engineers avoid disagreement. It's that disagreement is rarely taught as a skill. It's treated like a personality trait—something you either have or you don't.

The quiet cost of staying silent

The impact of this does not show up immediately. It shows up months later when systems fail in predictable ways. It shows up when engineers disengage and shift into execution mode, doing what is asked without feeling responsible for the outcome. It shows up when teams start confusing smooth meetings with good decisions.

Everything feels aligned but very little is actually examined. The people who do speak up without a framework often pay a different price. They get labeled as blockers or pessimists, even when their concerns are valid. Eventually, they stop being invited into the conversations where their perspective would have mattered most.

What changes when disagreement feels safe

The engineers with the most influence are not the ones who avoid disagreement, they are the ones who know how to shape it. They understand that disagreeing with a decision is not the same as opposing a person. They focus less on being right and more on making risks visible. Instead of arguing opinions, they talk about constraints, tradeoffs and failure modes.

They do not say that something is wrong, they explain what happens if the system is pushed, scaled, or stressed in a specific way.

When disagreement is framed like this, it stops feeling personal. It becomes part of doing good engineering work.

A more useful way to disagree

You do not need to become more outspoken. You need a structure that makes your disagreement easier to hear.

Start by anchoring the conversation to a shared goal like reliability, delivery speed, cost, or customer impact. Make it clear that you are optimizing for the same outcome as everyone else.

Then name the risk without attaching it to a person. Talk about what the system does under certain conditions rather than who proposed the approach.

If you can, offer a path forward. It does not have to be perfect. Even a rough alternative signals that you are contributing not blocking.

Finally, be intentional about timing. Some conversations are better had one on one before a decision is made. Public alignment and private dissent is not avoidance, it is often the most effective path.

Engineers who learn this are rarely described as difficult. They are described as thoughtful, reliable, and worth listening to.

Disagreement is not what limits most engineering careers.

Unspoken insight is.

Learning how to disagree safely is not about being nicer or more political. It is about making sure the problems you can see do not stay invisible.


That is all for this week.

The Modern Engineer

Join 1k+ other forward-thinking professionals who receive the weekly newsletter, where I provide actionable strategies, insights and tools to escape the grind and build influential, future-proof careers. Sign up and I will send yoy a FREE copy of my 5-Stage playbook to multiply your impact and build a career that AI can't replace.

Read more from The Modern Engineer

Hello Reader, A few years ago, I proposed adding automated rollback capabilities to our deployment pipeline. The system was fragile—on-call rotations were painful, incidents were frequent, and small changes could break the entire workflow. The refactor wouldn't ship new features, but it would make everything more reliable six months from now. The response was polite: "Sounds sensible. Not right now. Let's revisit next quarter." Next quarter came with new deadlines, new priorities and other...

Hello Reader, I spoke with an old friend last week. He told me he spent 4 years as a senior engineer watching less experienced engineers get to the next level ahead of him. His designs were cleaner. His solutions were faster. His technical reviews were thorough. But he kept getting the same feedback: "You need to be more visible and strategic" He thought that meant talking more in meetings. He was wrong. What he lacked was influence at work The Real Problem Here’s what actually happens when...

Hello Reader, Understanding this distinction would have saved me years of frustration in my engineering career. Every organization has two kinds of engineers. There are functional engineers and there are vital engineers. Most people never realize this, and it keeps them stuck far longer than necessary. I learned this the hard way, after confusing output with outcome for a long time. At first glance, functional engineers look impressive. They deliver tickets, close incidents, follow processes...