DEV Community

Cover image for How to Disagree in English (Without Burning Bridges)
Jacques Roux
Jacques Roux

Posted on

How to Disagree in English (Without Burning Bridges)

Someone proposes an approach in a meeting. You know it won't work. You've seen it fail before.

What do you say?

If you're a native English speaker, you probably do this without thinking. You soften it. You hedge. You wrap your "no" in something that sounds like a "maybe."

If English isn't your first language, this is a minefield. Say too little and your objection gets ignored. Say it too directly and you're "difficult to work with."

I work with developers on this a lot. It's one of the hardest things to get right.


Why Direct Disagreement Hits Different in English

In many languages and cultures, saying "No, that won't work" is perfectly fine. It's efficient. It's honest. Nobody takes it personally.

In English - particularly in a professional setting - it often lands like a slap.

It's not logical. But it's real. English-speaking work culture has this unwritten rule: disagree with the idea, but make the person feel respected while you do it.

That means your actual words matter less than how you frame them.


The Anatomy of a Good Disagreement

Most effective disagreements in English follow a pattern:

1. Acknowledge first
2. Introduce your concern
3. Offer an alternative

That's it. Three steps. Skip step one and you sound combative. Skip step three and you're just the person who shoots things down.

Let's look at how this plays out.


5 Situations Where You Need to Disagree

1. Someone suggests a bad technical approach

This happens in every sprint planning and architecture discussion.

❌ "That won't scale."

❌ "No, we should use Redis instead."

✅ "I see the logic there. My concern is how it handles load at scale - what if we looked at Redis as an alternative?"

✅ "That could work for the initial phase. I'm a bit worried about performance down the line though. Could we compare it with a caching layer?"

What's happening: You're not saying they're wrong. You're saying you have a concern. That's a very different thing.


2. A senior or lead says something you think is incorrect

This is the scary one. You don't want to embarrass them. You also don't want to stay quiet and let a bad decision happen.

❌ "Actually, that's not how that API works."

✅ "I might be wrong about this, but my understanding is that the API handles it differently. Want me to double-check?"

✅ "Interesting - I had a slightly different understanding of how that endpoint behaves. Could be worth verifying before we commit to the approach?"

What's happening: "I might be wrong" is doing heavy lifting here. You probably know you're right. But that phrase gives the other person room to correct course without losing face.


3. Someone's idea is over-engineered

We've all sat through a proposal where someone wants to build a rocket ship when you need a bicycle.

❌ "That's way over-engineered."

❌ "We don't need all that."

✅ "I like the direction. I'm wondering if we could get to the same result with something simpler - just to get an MVP out first?"

✅ "Makes sense as a long-term vision. For the current sprint, what's the minimum we could ship?"

What's happening: You're not attacking the idea. You're reframing the scope. "I like the direction" costs you nothing and buys a lot of goodwill.


4. Pushing back on an unrealistic deadline

Your PM says the feature needs to ship Friday. It's Wednesday. The feature isn't built yet.

❌ "That's impossible."

❌ "There's no way we can do that."

✅ "I want to make sure we deliver this properly. With the current scope, Friday is tight. Could we either trim the scope or adjust the timeline?"

✅ "I'm on board with the priority. My concern is quality if we rush it. What if we shipped the core feature Friday and the rest next week?"

What's happening: You're not saying no to the deadline. You're saying yes to the goal and proposing a realistic path. That's way easier for a PM to work with.


5. You disagree in a meeting but someone already moved on

The moment passed. Everybody nodded. But you're not convinced.

❌ (Staying silent and complaining on Slack later)

❌ "Wait, I don't agree with what we just decided."

✅ "Before we move on - can I come back to the caching approach for a second? I want to make sure we've thought through the invalidation side."

✅ "Sorry to circle back, but I had a thought on the earlier point about the database schema. Can I share it quickly?"

What's happening: "Before we move on" and "sorry to circle back" are signals. They tell people you're about to reopen something, which gives them a second to shift gears. Without that signal, it feels abrupt.


Phrases Worth Memorizing

These are the building blocks. Mix and match them.

What you want to say How to say it
"You're wrong" "I see it a bit differently"
"That's a bad idea" "My concern with that approach is..."
"No" "I'm not sure that's the best path because..."
"That'll never work" "I think we might run into issues with..."
"I disagree" "I hear you - and I want to offer a different perspective"
"That's over-engineered" "Could we simplify this a bit?"
"That deadline is insane" "I want to set realistic expectations on the timeline"

The Words That Make It Work

A few small words change everything:

  • "I think..." - Frames your disagreement as a perspective, not a verdict
  • "My concern is..." - You're raising a risk, not delivering a judgment
  • "What if we..." - Turns your objection into a suggestion
  • "I might be wrong, but..." - Gives the other person room to save face
  • "Could we..." - Collaborative. You're on the same team.

Notice the pattern? First person. Collaborative language. Questions instead of statements.


When to Drop the Softening

Same as with code reviews - there are times to be blunt:

  • Security risk: "This exposes user data. We need to fix this before it ships."
  • Legal/compliance issue: "We can't store that data without consent. Full stop."
  • Production is on fire: "The API is down. Let's skip the discussion and revert."

When something is urgent or dangerous, being direct isn't rude. It's responsible.


The Real Skill

Here's what I've noticed after working with developers for years: the best communicators on a team aren't the ones who avoid disagreement. They're the ones who disagree in a way that makes the other person feel heard.

That's not about being fake. It's about being strategic with your words.

You can be honest and diplomatic at the same time. In English, you kind of have to be.


Quick Practice

Try rewriting these in your head (or in the comments):

  1. "No, microservices are the wrong choice here."
  2. "This estimate is way too optimistic."
  3. "Why would we use GraphQL for this?"
  4. "That feature is a waste of time."

Vocabulary from This Article

Word What it means Example
minefield a situation full of hidden dangers "Salary negotiation is a minefield."
hedge to avoid committing to a direct statement "He hedged by saying 'maybe' instead of 'no'."
combative ready to argue or fight "His tone in the meeting was combative."
save face to avoid embarrassment "The phrasing lets them save face."
goodwill friendly, positive feelings between people "'I like the direction' buys goodwill."
blunt very direct, without softening "She was blunt about the deadline."

Your Turn

What's your go-to phrase when you disagree with someone at work?

Or - have you ever stayed quiet when you should have spoken up? What happened?

I'd love to hear your stories in the comments.


I'm Jacques, an English teacher who works with developers. I help non-native speakers communicate with confidence in technical environments.

Top comments (0)