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.