Engineering Scepticism Is a Feature, Not a Bug

Engineers are trained to find flaws. When you present a proposal, design, or decision to an engineering audience, you will face objections. This is healthy — good objections surface real problems before they become costly mistakes.

But for many non-native English speakers, objections feel confrontational and are hard to respond to in real time. You need two things: vocabulary to understand the type of objection, and sentence patterns to respond to it clearly and confidently.

The Three Main Types of Technical Objection

1. Technical Validity Objections

The engineer believes your technical claim is wrong.

“That approach won’t scale — you’ll hit a ceiling at around 10,000 concurrent users.” “That’s not how the database handles transactions. You’re assuming linearisability, but the default isolation level is read committed.”

These objections challenge a factual or technical assertion. They require either agreement, evidence, or clarification.

2. Complexity Concerns

The engineer agrees with the goal but believes the proposed approach adds too much complexity.

“This adds three new abstractions to the codebase. I’m not convinced the benefit justifies the overhead.” “We could solve this more simply with a two-line change to the existing service.”

These objections are about trade-offs, not facts. They require a comparison, not a correction.

3. Trade-Off Challenges

The engineer believes you have not considered the full cost of the proposal.

“What’s the operational cost of running this? You’ve covered the build time, but not the on-call burden.” “You’re optimising for write latency here, but the read path is already our bottleneck.”

These objections reveal a missing dimension. They are often the most valuable objections to receive.

Response Patterns

Acknowledge First

Before responding to any objection, acknowledge it. This is especially important in English-language meetings, where jumping immediately to a counter-argument reads as defensive.

Situation	Acknowledgement phrase
The objection has merit	”That’s a fair point — let me address it directly.”
You need time to think	”That’s a good challenge. Can I come back to that once I’ve finished the context?”
You partially agree	”I think you’re right that X is a concern, though I’d push back slightly on Y.”
The objection is out of scope	”That’s an important issue, but I think it sits outside the scope of this proposal. Can we take it to a separate thread?”

Responding to Technical Validity Objections

Your position	Response pattern
You agree	”You’re right — I misstated that. The correct behaviour is [X], and that actually strengthens the argument because…”
You disagree and have evidence	”I understand the concern, but the benchmarks we ran show [X]. I can share the test setup if it would help.”
You need to check	”I want to be precise about this rather than speculate. Let me verify and follow up with the correct answer.”

Responding to Complexity Concerns

The key is to make the trade-off explicit rather than defending the complexity abstractly.

“You’re right that this introduces additional abstraction. The reason we chose it over the simpler approach is [X]. If the complexity cost is higher than that benefit, I’m open to revisiting — but I wanted to name the trade-off clearly before we decide.”

Responding to Trade-Off Challenges

When an engineer names a dimension you have not addressed, treat it as a contribution, not an attack.

“That’s exactly the kind of consideration this discussion should surface. We haven’t fully costed the operational overhead yet. I’d suggest we add that to the decision criteria before we finalise the approach.”

Phrases for Maintaining Productive Dialogue

Situation	Phrase
Slowing down a fast-moving disagreement	”Let’s make sure we’re working from the same understanding before we go further.”
Requesting specificity	”Can you help me understand the specific scenario you’re concerned about?”
Separating signal from noise	”Is this a blocking concern for you, or is it something we should note and revisit?”
Deferring to expertise	”You know this system better than I do — what would you recommend instead?”
Proposing a follow-up	”This feels like it needs more analysis than we can do in this meeting. Can we agree to reconvene on Thursday with the data?”

Example Handling Dialogues

1. Validity objection:

Engineer: “A REST API won’t work here — you’ll get too much latency on the hot path.” You: “That’s a fair concern. Our measurements show p99 latency of 12 ms for the API call, which is within our budget. But if you’ve seen different numbers from a similar setup, I’d like to understand the context.”

2. Complexity concern:

Engineer: “This is a lot of abstraction for a problem we could solve with a feature flag.” You: “You’re right that a feature flag is simpler. The reason we moved away from that was [X]. If the consensus is that the simplicity benefit outweighs [X], I’m genuinely open to it — I just want the trade-off on the table.”

3. Trade-off challenge:

Engineer: “You’ve covered the cost to build this, but who is owning the operational runbook and the on-call rotation?” You: “That’s a gap in the proposal — I should have addressed that. My assumption was [team X], but I haven’t confirmed it with them. I’ll action that before we proceed.”

4. Out-of-scope objection:

Engineer: “Before we decide on this, we should also redesign the authentication layer.” You: “I agree the authentication layer is due for a redesign. I’d rather not couple those two decisions, though — can we track that separately so this proposal can move forward independently?”

5. Deep technical disagreement:

Engineer: “Your consistency model is wrong for this use case.” You: “I want to understand that better — can you walk me through the scenario where you see the inconsistency? I may be making an assumption I haven’t made explicit.”

The Language of Productive Disagreement

In English-language engineering culture, especially in British and American tech organisations, productive disagreement has a specific register. It is direct but not dismissive, confident but not closed.

Avoid these patterns:

Dismissive: ~~“That’s not really relevant.”~~ → “I’m not sure that applies to this scenario — can you help me see the connection?”
Capitulating too quickly: ~~“OK, yes, you’re right, whatever you think.”~~ → Engage with the substance or ask for time to consider.
Aggressive certainty: ~~“No, you’re wrong.”~~ → “I’d push back on that — my understanding is different, and here is why.”

Confidence without aggression is the register to aim for. It is learnable, and it makes you more effective in every technical discussion you participate in.