How to Give Feedback in a 1-on-1 in English

A practical English guide for giving feedback in 1-on-1 meetings — how to structure feedback, handle a defensive reaction, and follow up afterward.

Giving feedback in a 1-on-1 meeting is one of the most delicate forms of workplace communication, and doing it in a second language raises the stakes further — imprecise wording can come across as harsher, or vaguer, than you intend. Whether you’re a manager or a peer, clear and well-structured feedback helps the other person actually improve rather than just feel criticised. This guide gives you vocabulary and phrases for giving feedback effectively in English.

Key Vocabulary

Constructive feedback — feedback intended to help someone improve, framed around specific behaviour rather than personal character. “I want to give you some constructive feedback on the last sprint’s code reviews — I noticed they were arriving quite late in the cycle.”

Specific example — a concrete instance used to ground feedback in evidence rather than a general impression. “Rather than saying ‘your communication needs work,’ let me give a specific example: in yesterday’s standup, the update on the migration status wasn’t clear to the rest of the team.”

Behavioural framing — describing feedback in terms of observable actions, not assumed intentions or personality traits. “Instead of saying ‘you’re not committed to quality,’ I’d frame it as: ‘the last three PRs merged without tests, and I want to understand what’s getting in the way.’”

Impact statement — explaining the consequence of a behaviour, to help the recipient understand why it matters. “When the design doc was shared without context, it meant the whole team spent the first ten minutes of the meeting just trying to understand the proposal.”

Feedback sandwich — a (debated) technique of framing critical feedback between two pieces of positive feedback; many managers now prefer direct feedback instead. “I try to avoid the feedback sandwich — it can dilute the message. I’d rather be direct and follow with genuine encouragement separately.”

Check for understanding — confirming the other person has understood the feedback as intended, not just heard words. “Just to check we’re on the same page — how did that land for you? I want to make sure this didn’t come across as a bigger deal than I intended.”

Actionable next step — a specific, concrete change the person can make going forward, agreed on together. “Let’s agree on one concrete change: for the next two sprints, can we aim to get PRs opened by Wednesday instead of Friday?”

Follow-up — revisiting a piece of feedback in a later conversation to check on progress or adjust the approach. “Let’s touch base on this again in two weeks and see how it’s going, rather than leaving it as a one-time conversation.”

Structuring the Feedback

  • “I wanted to talk about something specific from last week. When the deploy went out without a heads-up in the channel, it caught the support team off guard.”
  • “This isn’t about any one incident — I’ve noticed a pattern over the last month where reviews are taking longer than usual to turn around.”
  • “I appreciate how thorough your reviews are — I do want to raise that the turnaround time has been a blocker for a few people this sprint.”

Handling a Defensive Reaction

  • “I can see this feels frustrating to hear — that’s not my intention. Can we talk through what’s making the reviews take longer?”
  • “I want to be clear this isn’t about your skills — it’s specifically about the timing, and I think there might be a workload issue underneath it.”
  • “Let’s pause for a second — I want to make sure this conversation feels useful to you, not just critical.”

Following Up

  • “How has the new approach been working since we last talked?”
  • “I noticed the change already — reviews have been much faster this sprint. Thank you for taking that on board.”
  • “Let’s keep checking in on this every couple of weeks until it feels like a solid habit.”

Professional Tips

  1. Anchor feedback in specific, recent examples. Vague feedback (“communication needs work”) is hard to act on; specific feedback (“the standup update wasn’t clear”) is not.
  2. Separate the behaviour from the person’s character. “The PR merged without tests” is about an action; “you don’t care about quality” is a judgment — the first is far more useful.
  3. Always end with an agreed next step. Feedback without a concrete follow-up action tends to be forgotten by the next 1-on-1.

Practice Exercise

  1. Rewrite the vague feedback “your communication needs work” into specific, behavioural feedback with an example.
  2. Write a short response (3-4 sentences) to a colleague who reacts defensively to feedback you’ve just given.
  3. Write a follow-up message checking in on progress two weeks after a feedback conversation.

Giving feedback effectively is a cornerstone of professional development, but it’s often complicated by differences in communication styles. For developers who are still honing their English skills – particularly when it comes to technical vocabulary and nuanced phrasing – the process can feel even more daunting. It’s not just about stating what you observed; it’s about conveying that observation constructively, acknowledging potential feelings, and establishing a collaborative tone. Let’s look at some specific strategies focused on helping non-native speakers navigate these challenges.

One of the biggest hurdles is often framing feedback as something positive. Instead of jumping straight into criticism (“This code doesn’t meet the standards”), try starting with what is good, then gently introducing areas for improvement. For example, when reviewing a pull request, you could begin with: “I really appreciate the thoroughness of your testing and the clear structure you’ve applied to this module. To ensure consistency across the project, I was wondering if we could explore incorporating [specific guideline] here.” Notice how that phrasing acknowledges the positive effort before suggesting an adjustment. Similarly, when responding to a Slack message asking for clarification on a complex algorithm – “That’s a really interesting approach! Could you elaborate on your reasoning behind using this particular data structure?” – you’re validating their thinking while opening a space for further discussion.

Another key area is managing potential defensiveness. Feedback can be perceived as criticism, and if the language isn’t carefully chosen, it can trigger an automatic defensive reaction. Instead of saying “This section is confusing,” which feels accusatory, try “I’m finding this section a little challenging to understand at first glance. Perhaps we could walk through the logic together?” or “Could you perhaps explain your thought process for this particular implementation?” The use of “I” statements – focusing on your understanding rather than directly criticizing their work – can be incredibly powerful. Also, actively listening and acknowledging their perspective (“That’s a valid point about…”) shows that you value their input and are open to a dialogue.

Finally, don’t underestimate the power of precise vocabulary. Using technical jargon incorrectly or relying on overly simplistic language can create further misunderstandings. If discussing code quality with a colleague, instead of saying “this needs fixing,” consider “this requires refactoring for improved maintainability” or “this could benefit from some optimization for performance.” Being mindful of the level of detail and tailoring your language to your audience’s technical understanding is crucial – especially when you’re working across different teams and experience levels. Remember, clear communication builds trust and facilitates collaboration.

Frequently Asked Questions

What English level do I need to read "How to Give Feedback in a 1-on-1 in English"?

This article is tagged Intermediate. If you find the vocabulary difficult, start with a related Career vocabulary exercise first, then come back — technical reading gets much easier once the core terms feel familiar.

Is this article free to read?

Yes. Every article on CoderSlingo, including this one, is free to read with no account, sign-up, or paywall.

How is reading this article different from doing an exercise?

Articles like this one explain concepts and vocabulary in context through prose, while exercises are interactive drills — fill-in-the-blank, matching, and multiple-choice — that test and reinforce specific terms. Reading builds understanding; exercises build recall.