One of the hardest adjustments for Vietnamese developers on international teams is learning that professional disagreement is expected, valued, and — when done well — is one of the most trust-building things you can do.
In many Vietnamese workplace contexts, public disagreement with a senior person signals disrespect, or risks making them “lose face.” The instinct is to stay quiet, nod along, raise concerns privately or not at all.
In international tech teams, the opposite dynamic operates. When you consistently agree with everything, people start to wonder whether you’re actually engaging with the problem, whether you’ve thought it through, whether you’ll push back when something goes wrong in production. Silence reads as absence of thought, not deference.
The language for productive technical disagreement is learnable. Here’s what it looks like.
The Frame: Disagree with the Idea, Not the Person
The foundational principle: every disagreement should be framed around the technical question, not around the person who proposed it. This isn’t just politeness — it’s the frame that keeps the discussion productive.
Person-focused (creates defensiveness):
“That won’t work."
"I don’t think that’s the right approach.”
Idea-focused (invites problem-solving):
“I want to understand this approach better — what happens if [specific scenario]?"
"I see a potential issue with [specific aspect]. Can we think through [specific scenario] together?”
The person-focused version attacks a position. The idea-focused version opens an investigation. The first makes people defend; the second makes people think.
Opening a Disagreement
The way you open matters. A poorly framed opening shuts down conversation; a well-framed one opens it.
Too blunt (shuts down):
“That’s wrong.” / “I disagree.” / “That approach has problems.”
Strong openers (opens up):
-
“I want to push back on this a little — not because I think it’s wrong, but because I want to make sure we’ve stress-tested it. What happens when [edge case]?”
-
“Can I raise a concern before we commit to this direction? I’m worried about [specific thing] — here’s my thinking.”
-
“I see it differently. My read is [your position], because [reason]. What am I missing?”
-
“I want to make sure I understand the tradeoff here — if we do X, we’re accepting Y risk. Is that right? Is that the tradeoff we want?”
The last one is particularly powerful: it names the tradeoff explicitly without saying the decision is wrong. It forces the room to confirm the cost, which often reveals that people hadn’t thought it through.
When You’ve Been Overruled
Sometimes you make your case and the decision goes the other way. How you handle this is as important as the disagreement itself.
Wrong response (passive-aggressive):
Silence. Saying nothing. “Fine.” / “Whatever you think.”
Also wrong (relitigating after decision):
Bringing it up again after the decision is made. Saying “I told you so” when it goes badly.
Right response — commit and document:
“Okay, I understand the decision. I want to note for the record that I see a risk around [X]. I’ll move forward on this, and let’s keep an eye on [specific metric] as we go. If we see [warning sign], that’s the trigger to revisit.”
This does three things:
- It commits you to the decision without pretending you agreed
- It creates a shared understanding of the risk
- It defines a forward-looking condition for revisiting, so “I told you so” becomes “we agreed we’d revisit this when…”
The phrase “for the record” is standard in English-speaking team culture and carries no aggressive connotation — it simply marks that something is being formally noted.
Building on Ideas You Disagree With
Sometimes the right move isn’t pure disagreement but a “yes, and” that shifts direction. This is especially useful when you think an idea is partially right but incomplete.
“I think you’re right that we need [X]. What I’m not sure about is whether [this approach] gets us there. What if we tried [alternative] instead — would that give us the same [benefit] without [the risk I see]?”
“That solves [problem A] well. I’m wondering if it creates [problem B]. Does anyone see a way to address both?”
This approach acknowledges what’s good about the proposal before introducing the concern. It’s not flattery — it’s accurate analysis, and it signals that you’re building on the discussion rather than tearing it down.
Probing Questions That Expose Weak Assumptions
Sometimes the most effective disagreement isn’t a counter-argument but a question that makes the room discover the problem themselves. This is particularly useful when you’re not certain you’re right, or when the person proposing has more authority.
“What’s our fallback if this takes twice as long as estimated?” “Have we seen this pattern work at our scale, or are we extrapolating from smaller systems?” “If this fails in production at 2am, what’s the recovery path?” “What does ‘done’ look like for this? How will we know it’s working?”
These questions aren’t rhetorical tricks — they’re legitimate engineering questions. Asking them is what separates a tech lead who’s engaged from one who nods along and hopes for the best.
🗣️ Key Phrases to Say Out Loud
-
“I want to PUSH BACK on this a LITtle” /aɪ wɒnt tə pʊʃ bæk ɒn ðɪs ə ˈlɪtl/ — Opens a disagreement; “push back” is the standard English phrase, not aggressive
-
“Can I RAISE a concern beFORE we comMIT to this diRECtion?” /kæn aɪ reɪz ə kənˈsɜːn/ — Signals you have a substantive objection, not just a quibble
-
“I SEE it DIFferently — my READ is…” /aɪ siː ɪt ˈdɪfrəntli maɪ riːd ɪz/ — “My read” is natural English for “my interpretation/assessment”; less confrontational than “I think you’re wrong”
-
“I want to NOTE for the RECord that I see a RISK around [X]” /aɪ wɒnt tə nəʊt fɔː ðə ˈrɛkəd/ — Commit-and-document language; formal but not adversarial
-
“What’s our FALLback if this TAKES TWICE as LONG?” /wɒts aʊər ˈfɔːlbæk/ — Engineering probe question; “fallback” is the natural technical term
-
“Does ANyone see a WAY to adDRESS BOTH?” /dʌz ˈɛnɪwʌn siː ə weɪ/ — Invites collective problem-solving rather than binary positions
-
“Let me MAKE sure I underSTAND the TRADEoff” /lɛt miː meɪk ʃʊər aɪ ˌʌndəˈstænd ðə ˈtreɪdɒf/ — Forces explicit acknowledgment of costs before committing
📚 Vocabulary
1. Push back /pʊʃ bæk/ (phrasal verb)
- Meaning: To express disagreement or resistance to an idea or decision
- Example: “The PM pushed back on the two-week estimate — she wanted it done in one.”
2. Tradeoff /ˈtreɪdɒf/ (noun)
- Meaning: A balance between two desirable but incompatible qualities; accepting a cost to gain a benefit
- Example: “The tradeoff of using Redis is operational overhead for persistence. Is that worth it here?”
3. Stress-test /strɛs tɛst/ (verb, figurative)
- Meaning: To examine an idea or plan under difficult conditions to find its weaknesses
- Example: “Before we commit, let’s stress-test this assumption: what happens at 10x load?”
4. For the record (phrase)
- Meaning: A formal way of noting something officially; used to mark a stated position
- Example: “I want to note for the record that we’re accepting this risk knowingly.”
5. Extrapolate /ɪkˈstræpəleɪt/ (verb)
- Meaning: To extend a conclusion beyond known data, assuming a trend continues
- Example: “We’re extrapolating from a 1,000-user benchmark to a 1-million-user system — that may not hold.”
6. Fallback /ˈfɔːlbæk/ (noun)
- Meaning: An alternative plan if the primary plan fails; a backup
- Example: “What’s our fallback if the third-party API goes down? We need a clear degradation path.”
7. Commit /kəˈmɪt/ (verb, in discussions)
- Meaning: To formally agree to a decision or course of action, accepting responsibility for it
- Example: “I’ll commit to this timeline, but I need two more engineers on it.”
🎯 Practice Now
Exercise 1: Open the Disagreement
Your team is proposing to skip load testing before a major release because “we’ve never had a performance issue.” Convert each of these blunt responses into a well-framed disagreement opener:
- “That’s a bad idea.”
- “We always have performance issues eventually.”
- “I don’t agree.”
Sample strong versions:
- → “I want to push back on this a little — we’ve been lucky so far, but this release is 3x the code change volume. What’s our fallback if there is a performance issue post-launch?”
- → “Can I raise a concern? Our previous releases were smaller. This one touches the payment flow. I’d feel better if we stress-tested the checkout path at least. What would that take — half a day?”
- → “I see it differently. My read is the risk profile on this release is higher than our previous ones. What would we need to see to feel confident skipping load testing?”
Exercise 2: Commit-and-Document
The team has decided to deploy on Friday evening despite your objection. Write and say aloud a commit-and-document response that:
- Accepts the decision
- Notes the risk formally
- Defines a forward-looking trigger for revisiting
Exercise 3: Full Discussion Role-Play
Read this dialogue aloud, playing both parts:
Tech Lead: “I want to push back on going with the NoSQL approach here. Can I raise a concern before we commit?”
Colleague: “Sure, what’s your concern?”
Tech Lead: “My read is we’re optimizing for write speed, but our main use case is complex queries across related data. NoSQL makes those harder. What I’m not sure about is whether write speed is actually our bottleneck — is it? Do we have metrics on that?”
Colleague: “Honestly, we don’t have data on that yet.”
Tech Lead: “Okay, then can we agree to do a quick spike this week — profile both approaches on our actual query patterns — before we commit to the data model? I want to make sure we’re solving the right problem.”
The goal in technical discussions isn’t to win arguments. It’s to make better decisions than any individual in the room could make alone. That only happens when everyone — including you — says what they actually think.
The English for that is learnable. The habit of using it is what separates tech leads who are present in discussions from those who are just attending them.