English for Performance Review Conversations in Tech
Master the English phrases and vocabulary for 1:1 performance discussions, self-assessments, and career growth conversations in tech teams.
Performance reviews are high-stakes conversations. For engineers working in English as a second language, the challenge is not just doing great work — it is articulating that work confidently and precisely in a 1:1 or written self-assessment.
Self-Assessment Language
The self-assessment is your opportunity to frame your contributions before your manager does. Use strong, specific language.
Describing impact
- “I delivered the new authentication service ahead of schedule, reducing login errors by 40%.”
- “I led the migration to the new observability stack, resulting in 30% faster incident resolution.”
- “I contributed to three cross-team initiatives and drove the adoption of our internal SDK.”
Acknowledging growth areas
Be honest but constructive:
- “I recognise that I could improve my stakeholder communication, particularly around setting expectations early.”
- “I struggled with prioritisation in Q2 when several high-priority items landed simultaneously — I am actively working on this.”
- “I identified this gap and have taken steps to address it by…”
Avoid vague self-deprecation (“I’m not great at…”). Name the specific skill, describe what you did about it, and show progress.
Discussing Technical Contributions
Use precise technical language paired with business impact:
| Contribution | Weak phrasing | Strong phrasing |
|---|---|---|
| Bug fix | ”Fixed some bugs" | "Resolved a critical race condition that caused 2% of checkout failures.” |
| Code review | ”Did code reviews" | "Reviewed 34 pull requests, mentoring two junior engineers on testing patterns.” |
| Architecture | ”Helped with design" | "Authored the system design document for the event streaming refactor.” |
| On-call | ”Was on call" | "Handled 12 incidents on call, all resolved within SLA, with three contributing to post-mortems.” |
Receiving Feedback
Performance reviews involve receiving feedback, which requires specific language skills.
Asking clarifying questions
- “Could you give me a specific example of when my communication fell short?”
- “When you say I need to raise visibility — what would that look like in practice?”
- “I want to make sure I understand — are you saying the quality or the timeliness is the concern?”
Responding to critical feedback
- “That’s fair feedback. I can see how that landed differently from how I intended.”
- “I hear what you’re saying. What would success look like going forward?”
- “Thank you for raising this. I’d like to take some time to reflect and come back with a plan.”
Phrase: “I hear what you’re saying” — this is a professional way to acknowledge feedback without immediately agreeing or disagreeing.
Discussing Promotions and Career Growth
Asking about promotion criteria
- “What evidence would you need to see to support a case for promotion?”
- “Is there a gap between where I am now and the next level that I should focus on?”
- “Could we align on two or three areas to prioritise for the next half?”
Advocating for yourself
- “I believe I am operating at the next level in these areas: [X, Y, Z].”
- “I’d like to make a case for a promotion conversation at the next cycle.”
- “Over the past year, I have consistently delivered at a level above my current role.”
Asking for a stretch opportunity
- “I am keen to take on more architectural responsibility.”
- “I’d like to own an initiative end-to-end in the next quarter.”
- “Could I shadow you in the next architecture review to develop that skill?”
Talking About Goals
Setting SMART goals in English:
Vague: “I want to get better at system design.”
SMART: “By the end of Q3, I will author one system design document for a medium-complexity project and present it in a design review. I will use the feedback to identify two areas for improvement.”
Key Phrases Cheat Sheet
| Situation | Phrase |
|---|---|
| Describing impact | ”…resulting in a 30% reduction in…” |
| Owning a gap | ”I recognise that I could improve my…” |
| Receiving feedback | ”That’s fair — could you give me a specific example?” |
| Asking about promotion | ”What evidence would support a case for promotion?” |
| Advocating for yourself | ”I believe I am operating at the next level in…” |
| Setting a goal | ”By the end of [period], I will [action] [measurable outcome].” |
Key Takeaways
- Self-assessments should pair contributions with quantified impact — not just activities.
- Use strong action verbs: led, delivered, drove, authored, resolved — not helped with or worked on.
- Receiving feedback well is itself a professional skill. Clarify before reacting.
- When advocating for promotion, use the language of evidence: “I believe… because…”
- Goal conversations are more productive when you propose specific, measurable outcomes.
Navigating Feedback – Beyond “Fix This”
Let’s be honest, a lot of initial feedback you receive—especially during code reviews or from junior colleagues—can feel incredibly blunt. Phrases like “fix this” or “this needs refactoring” can feel dismissive and don’t immediately convey why the change is necessary. The key here isn’t to simply accept the criticism, but to understand it and respond constructively. It’s about shifting from a reactive ‘I need to fix something’ mindset to a proactive one focused on learning and improvement.
A more helpful approach starts with acknowledging the feedback without immediately defensiveness. A simple response like, “Thanks for pointing this out – I appreciate you highlighting this potential area for improvement,” sets a tone of openness. Then, request clarification. Instead of diving straight into justifications, ask questions that help you understand the underlying issue. For example, instead of arguing about a minor style preference in a code review comment, respond with: “Could you elaborate on what specific concerns you have regarding this section’s readability?” or “Can you walk me through your thought process for suggesting this change?” This demonstrates genuine interest and a desire to learn from their perspective.
Furthermore, when describing changes in a Pull Request description, move beyond simply stating what you did. Explain why. A good example would be: “Refactored the data validation logic as suggested in yesterday’s feedback (PR #1234). This change improves error handling and reduces potential runtime issues by implementing a more robust check for invalid input.” Notice how this explanation connects back to the previous conversation, demonstrating you were listening and incorporating their concerns. Similarly, when discussing your performance with your manager, don’t just list accomplishments; frame them within the context of team goals and demonstrate how your work contributed to those objectives. “As we discussed during my last check-in, I focused on improving the efficiency of the user authentication process, which aligns with the team’s priority of enhancing security.”
Finally, remember that feedback is rarely personal. It’s almost always about the work, not you as a person. Focusing on understanding and responding to the intent behind the feedback – whether it’s improving code quality, streamlining workflows, or achieving project goals – will build trust and foster a more collaborative environment.