How to Give Technical Feedback Diplomatically
English phrases and techniques for delivering technical feedback that is honest, constructive, and professional — without damaging relationships.
Giving technical feedback is one of the most sensitive communication tasks in engineering. You might be reviewing someone’s architecture proposal, responding to a colleague’s design decision, or coaching a junior developer. In all these cases, how you say something matters as much as what you say.
This guide covers the English phrases and techniques that make technical feedback land well — honest and clear, but never harsh.
The Core Principle: Separate the Work from the Person
In English, there is a crucial difference between these two statements:
- “You made a poor design choice.” — attacks the person
- “This design has some trade-offs we should discuss.” — addresses the work
Always direct your feedback at the code, design, document, or decision — not at the individual. This is not just politeness; it produces better technical outcomes because the recipient stays open to the conversation rather than becoming defensive.
Framing Feedback Positively First
Before raising a concern, acknowledge what works. This is not flattery — it is professional context-setting:
“Overall this is a well-structured proposal. I have a few questions about the data layer that I’d like to work through with you.”
“The approach here is solid for the common case. I’m wondering how it handles edge cases around concurrent requests — can we talk through that?”
“This is a big improvement over the previous implementation. One thing I’d like to explore is whether we can reduce the coupling between these two modules.”
Phrases for Raising Concerns
Questioning an assumption:
“I want to make sure I understand the reasoning here — what’s the expectation for throughput at peak load?”
“Have we considered what happens if the third-party API is unavailable? I don’t see error handling for that path.”
Suggesting an alternative:
“One option worth considering is using an event queue here instead of direct calls — it would decouple the services and make retries easier to manage.”
“I’ve seen a similar problem solved with a strategy pattern. It might give us more flexibility as requirements change. Worth discussing?”
Flagging a risk:
“I want to flag a potential risk: this change touches the payment flow, which is high-stakes. I’d feel more confident if we had integration tests before this goes to production.”
“The performance here looks fine for current load, but if we scale to 10x users, this O(n²) loop could become a bottleneck. Should we address it now or create a ticket for later?”
Softening Language That Still Communicates Clearly
“Softening” does not mean weakening. These phrases reduce friction without reducing clarity:
| Direct (potentially abrasive) | Softened (still clear) |
|---|---|
| “This is wrong." | "I think there might be an issue here." |
| "You should have done it this way." | "One approach that tends to work well is…" |
| "This doesn’t scale." | "I have some concerns about how this will perform at scale." |
| "Nobody does it like this." | "The more common pattern for this is X — is there a specific reason for this approach?" |
| "That’s a bad idea." | "I see some challenges with this. Can I share my thinking?” |
Giving Feedback in Writing vs. In Person
In writing (Slack, email, PR comments):
- Be more explicit — tone is hard to read in text
- Add “I” statements: “I’m not sure I follow this part” rather than “This is unclear”
- Use hedging language: “I might be missing something, but…”
- End with a question when possible: “What are your thoughts?”
In person or on a call:
- Use a warmer tone, but be equally direct
- Pause and ask: “Does that make sense?” or “What do you think?”
- Watch for non-verbal cues — if the person seems defensive, slow down
Giving Feedback to Someone More Senior
This is one of the most language-sensitive situations in engineering. Use questions and observations rather than directives:
“I noticed something in the architecture diagram I wanted to check — am I reading this correctly that both services write to the same table?”
“I might be missing the full context, but I’m a bit worried about the latency on this path. Is that a known trade-off?”
“I had a thought about this design — would it be worth exploring whether we could avoid the shared database state? Happy to be wrong if there’s a reason for it.”
These phrases are not dishonest — they are professional. They show humility while still surfacing the concern.
Following Up After Giving Feedback
“I wanted to follow up on the feedback I shared last week — did you get a chance to look at it?”
“Happy to pair on this if it would help to talk through the options.”
“If you disagree with my suggestion, I’m genuinely open to hearing your reasoning — let’s find a time to discuss.”
Diplomatic technical feedback is a learnable skill. The engineers who do it best are direct enough to be useful, and considerate enough to be trusted. Those two qualities together make feedback welcome rather than dreaded.
Navigating Nuance: Feedback for Non-Native Speakers
Delivering technical feedback effectively isn’t just about stating your observations; it’s a delicate dance of precision and empathy. For developers whose first language isn’t English, this can feel particularly challenging. The subtle shifts in vocabulary and phrasing that convey genuine understanding and avoid potential misunderstandings are crucial. It’s easy to unintentionally sound overly critical or dismissive, even with good intentions. Let’s consider a common scenario: a pull request is submitted for a new feature implementing user authentication. During the code review, you notice several areas where the logic could be improved.
One frequent pitfall for non-native speakers is using overly direct language. Instead of saying “This code is wrong,” which can feel harsh, try framing it with softer phrasing. For example, you might say: “I noticed a potential issue in this section regarding error handling. Perhaps we could explore adding a try...catch block to gracefully manage unexpected responses and prevent the application from crashing.” The addition of “perhaps we could” immediately softens the critique and invites collaboration. Similarly, instead of saying “This variable isn’t used,” you could offer: “I’m wondering if this variable is currently required in this function. Could we discuss its purpose or whether it might be redundant?” This phrasing opens a conversation rather than delivering an immediate judgment.
Another area needing careful attention is using conditional language related to technical terms. Many developers use specific jargon that may not translate perfectly into another language. When describing a performance bottleneck, avoid simply stating “This code is slow.” Instead, you could say: “I’ve observed some latency in this section of the code during peak usage times. It might be beneficial to investigate potential optimizations related to database queries or caching strategies.” Providing context – when the issue appears – adds significant clarity and demonstrates a more thorough understanding. Furthermore, phrases like “it would be good to” or “we should consider” are preferable to demanding statements.
Finally, remember that active listening and seeking clarification are vital tools. If a colleague uses terminology you don’t fully understand, politely ask for an explanation: “Could you elaborate on what you mean by ‘optimizing the memory footprint’ in this context? I want to ensure I’m fully grasping your intention.” This shows respect for their expertise and creates space for productive dialogue. Don’t be afraid to admit if something is unclear; a simple “I’m not entirely sure I understand – could you perhaps explain it differently?” can dramatically improve communication and build trust.