English for Performance Reviews in Tech
Master the vocabulary and phrases you need to navigate performance reviews in English — from OKRs and impact statements to receiving feedback and advocating for yourself.
Performance reviews are one of the most consequential conversations a developer has at work. They determine promotions, raises, and how you are perceived by your manager and organisation. For non-native English speakers, the challenge is not just describing what you did — it is framing it in the language your company uses, the language of impact, growth, and contribution. This guide teaches you exactly that.
Key Vocabulary
OKR (Objectives and Key Results) — a goal-setting framework where each objective is measured by concrete, quantifiable results. “My OKR for Q2 was to reduce API response time by 40% — we hit 38%.”
Impact — the meaningful change your work produced, not just the tasks you completed. “The impact of the caching layer was a 60% reduction in database load during peak traffic.”
Scope — the range or level of your influence. Senior roles are expected to have broader scope. “I’ve been operating at a scope beyond my current level — I’m influencing decisions across three teams.”
Levelling — the process of evaluating whether someone is ready to move to the next career level. “I want to discuss levelling — I feel I’ve been consistently operating at L5 for two quarters.”
360 feedback — feedback gathered from peers, direct reports, and managers (a full circle of perspectives). “The 360 feedback was generally positive, but a few people mentioned I could communicate more proactively.”
Growth area — a polite term for something you need to improve. Preferable to “weakness.” “My growth area this half was stakeholder communication — I’ve been working on it deliberately.”
Self-assessment — the written or verbal summary you provide of your own performance before the review meeting. “My self-assessment focused on three areas: delivery, collaboration, and technical leadership.”
Phrases for Describing Your Impact
Impact language is the most important skill in performance reviews. Move from “what I did” to “what changed because of what I did”:
- “I led the migration to the new auth system, which eliminated a class of security vulnerabilities and reduced support tickets by 30%.”
- “My work on the onboarding flow reduced time-to-activation for new users from 4 days to less than 1.”
- “I mentored two junior engineers who have since taken on independent projects — that’s a multiplier effect on the team.”
- “The refactor I delivered reduced build times by 45%, which improved developer productivity across the board.”
The key structure is: action + outcome + measurable result. Avoid saying “I worked on X” — always say “I delivered X, which resulted in Y.”
Phrases for Discussing OKRs
OKR language is specific. Companies use it to measure progress with numbers, not opinions:
- “My key result was to achieve 99.9% uptime — we ended the quarter at 99.95%.”
- “We hit two out of three key results. The third one slipped because of the infrastructure incident in May.”
- “I set a stretch goal of reducing churn by 15% — we achieved 12%, which I consider a strong result given the constraints.”
- “Looking back, I think I set the key results too conservatively — I want to be more ambitious in H2.”
Phrases for Receiving Feedback
How you respond to feedback — especially critical feedback — is itself evaluated. These phrases show professionalism and self-awareness:
- “Thank you for that feedback — can you give me a specific example so I can understand it better?”
- “That’s fair. I’ve been aware of this and I’ve been working on it — here’s what I’ve done so far.”
- “I want to make sure I understand the feedback correctly. Are you saying the issue is X, or more Y?”
- “I appreciate you raising this. It’s not easy to hear, but I want to address it.”
Avoid being defensive. Even if you disagree, acknowledge the feedback before responding: “I hear you — and I want to share my perspective on that situation.”
Phrases for Advocating for Yourself
Many developers — especially non-native English speakers — find self-advocacy uncomfortable. But it is expected in performance conversations:
- “I feel like my contributions this half have been operating above my current level — I’d like to discuss levelling.”
- “I’d appreciate more visibility into what ‘ready for promotion’ looks like concretely for me.”
- “I’ve taken on significant scope this quarter, including X and Y. I want to make sure that’s reflected in the evaluation.”
- “I want to be transparent: my growth goal for next year is to move into a tech lead role. What would you need to see from me?”
Phrases to Avoid
| Avoid | Try instead |
|---|---|
| ”I just did my job." | "I consistently delivered on my commitments and took on additional scope." |
| "Nobody noticed my work." | "I want to make sure my contributions are visible — how can I communicate them better?" |
| "I don’t know what my growth areas are." | "I’ve been reflecting on this — I think my main growth area is X." |
| "That feedback isn’t fair." | "I’d like to share some context that might reframe that situation.” |
Quick Reference
| Situation | Phrase |
|---|---|
| Describing impact | ”My work on X resulted in Y.” |
| Discussing OKRs | ”We hit two out of three key results.” |
| Receiving hard feedback | ”That’s fair — here’s what I’ve been doing to address it.” |
| Advocating for promotion | ”I’d like to discuss levelling — I’ve been operating at scope above my current level.” |
| Asking for clarity | ”What would ‘ready for promotion’ look like concretely?” |
| Naming a growth area | ”My growth area this half was stakeholder communication.” |
The developer who can articulate their impact clearly has a significant advantage in performance conversations. Invest in this language — it pays off directly in your career.
Navigating Feedback – A Practical Approach for Non-Native Speakers
Performance reviews, particularly when delivered in a language other than your native tongue, can feel incredibly daunting. It’s not just about understanding the words themselves; it’s about grasping the subtle nuances of feedback and confidently articulating your contributions. Many developers new to English struggle with expressing impact or receiving constructive criticism effectively. A key issue is often translating technical expertise into a language understandable by stakeholders who may have different levels of technical knowledge. Let’s focus on practical strategies for navigating this situation, specifically targeting those learning professional English vocabulary.
One of the biggest hurdles is phrasing your accomplishments in a way that resonates with a performance review context. Simply stating “I fixed bug X” isn’t impactful enough. You need to frame it within the broader context of the project’s goals – perhaps “By resolving bug X, I contributed to improving user experience by reducing reported errors during peak usage, aligning with our Q3 OKR for enhanced system stability.” Notice how we’ve added quantifiable elements and linked it back to a key objective. Similarly, when receiving feedback like “This code could be more readable,” don’t immediately become defensive. Instead, respond with something like, “I appreciate the suggestion regarding readability. Could you provide specific examples of areas I can improve so I can better align my work with team standards?” Demonstrating openness to learning and seeking clarification is crucial. Remember, the goal isn’t to prove yourself ‘right,’ but to demonstrate a commitment to continuous improvement – a value highly prized in tech environments. Focus on active listening and demonstrating a willingness to adapt your approach based on feedback.
Another area where many developers struggle is advocating for themselves when discussing opportunities or challenges. Don’t shy away from expressing your interest in new technologies or proposing solutions, but frame them strategically. Instead of saying “I want to learn React,” try “I’m interested in expanding my skillset to include React, as I believe it could be valuable in our upcoming project [Project Name], allowing us to leverage its benefits for improved UI development and potentially reducing development time.” This demonstrates initiative, foresight, and a clear understanding of how your growth benefits the team. Building confidence through consistent practice – even just mentally rehearsing responses to common review questions – is paramount.
Here’s an example of using git blame to identify potential areas for improvement:
git blame <file_name>This command will show you the history of changes made to a specific file, allowing you to pinpoint exactly where code was last modified and potentially understand why certain decisions were made. You can then use this information as a starting point for discussion with your reviewer about potential refactoring or improvements. For instance, “I noticed that this section was heavily modified by [Developer Name] six months ago. While the functionality is still working, it might benefit from a more modern approach given current best practices.”