Team Performance Reviews in English: Language for Engineering Managers

Performance reviews are among the most consequential conversations an engineering manager has — they affect compensation, promotions, career development, and the working relationship between manager and engineer. For non-native English speakers in management roles, the performance review cycle introduces specialised vocabulary that does not appear in day-to-day engineering communication. Getting this language wrong can create misunderstandings about expectations, misrepresent an engineer’s standing, or undermine the trust that a review process is meant to build.

Key Vocabulary

Calibration session A cross-team meeting where managers compare their assessments of engineers at similar levels to ensure consistency — preventing situations where the same level of performance is rated differently across teams.

“In the calibration session, we’ll each present our proposed ratings and justify them against the level expectations. The goal is to ensure a senior engineer in my team and a senior engineer in your team are being held to the same bar.”

Performance band A rating category that indicates overall performance level — common examples include “exceeds expectations,” “meets expectations,” “below expectations,” and “does not meet expectations.”

“She’s solidly in the ‘meets expectations’ band this cycle — consistent delivery, good collaboration, no gaps that we’ve discussed. I’m not putting forward an ‘exceeds’ because she hasn’t had the scope to demonstrate the leadership dimension yet.”

Development area A skill, behaviour, or capability where an engineer has an identified gap and a growth plan — framed constructively rather than as a failure.

“His primary development area is written communication — specifically, documenting his technical decisions clearly enough that other engineers can build on them without asking him directly.”

Growth conversation A discussion focused on an engineer’s longer-term career aspirations, skills development, and progression — distinct from a performance review, which focuses on past performance.

“I try to keep performance conversations and growth conversations separate. Performance looks backwards; growth looks forwards.”

Promotion case The evidence and argument assembled to support a recommendation that an engineer be promoted to the next level — typically requires demonstrating that the engineer is already performing consistently at the higher level.

“To make the promotion case for staff level, I need to show sustained impact beyond the team boundary — the work needs to have influenced how other teams operate, not just our own.”

Stretch goal A challenging target that is designed to push an engineer beyond their current comfort zone — used to create development opportunities and demonstrate readiness for the next level.

“The stretch goal for this cycle was to lead the cross-team API design review. She did it successfully, and it’s now part of the promotion case.”

Rating vocabulary The specific language used to describe performance ratings — varies by company but typically includes terms like “consistently exceeds,” “strongly meets,” “partially meets,” and “does not meet.”

“When I write the review, I use the exact rating vocabulary from the framework — language like ‘this engineer consistently meets the expectations for the senior level’ maps directly to the calibration rubric.”

Useful Phrases

Opening a performance review conversation:

“I want to start by sharing how I see your performance this cycle, and then I want to hear your perspective. This isn’t a one-way conversation — your self-assessment is an important part of how I’ve thought about this.”

Delivering a positive rating:

“You’ve had a strong cycle. The platform migration you led was delivered on time, under budget, and with strong feedback from the teams who depended on it. You’ve demonstrated the scope and impact that the senior level requires — consistently, not just once.”

Delivering a developmental message:

“I want to be honest with you about where I see a gap, because I think it’s holding back your progression. The technical work is excellent — but the way you communicate design decisions in writing means that colleagues often can’t act on your work without a follow-up conversation. That’s the area I’d like to focus on together this cycle.”

Framing a development area:

“I’m not raising this as a ‘you failed’ — I’m raising it because I think it’s the thing that, if you work on it, will make the biggest difference to your trajectory. I want to support you in getting there.”

Discussing promotion timing:

“You’re not at the staff level yet, but you’re on the right track. The promotion case needs one more cycle of sustained impact at that scope. I’ll be actively creating the opportunities for you to demonstrate that — but I want you to know that it’s a cycle away, not two or three.”

Common Mistakes

Delivering a surprise in a review If an engineer is genuinely surprised by their performance rating, it indicates that feedback was not delivered throughout the cycle. Performance reviews should confirm what the engineer already knows — not introduce new information at the end of the year. A useful principle: “Nothing in a performance review should be a surprise. If I haven’t said it before today, I should ask myself why.”

Using vague developmental language Phrases like “you need to work on your communication” or “you need to be more proactive” are too vague to act on. Specific developmental feedback describes observable behaviour: “In the last three technical design documents you authored, the ‘trade-offs considered’ section was either missing or contained a single sentence. I need that section to be substantive enough that a reviewer can understand the reasoning without asking you directly.”

Conflating personality with performance Descriptions like “they’re not very confident” or “they have a quiet personality” describe personality, not performance. Performance language describes observable behaviour and business impact: “In the last four cross-team meetings, [name] has not offered input on topics where I know they have relevant expertise. This is limiting their visibility and influence at the senior level.” The distinction matters — personality cannot be asked to change; behaviour can.

Effective performance conversations require both honesty and care — and the precision of your language determines whether the engineer leaves the room with clarity and direction, or with confusion and frustration.

Navigating Nuance: Specific Language for Non-Native Speakers

As engineering managers, we’re constantly striving to provide constructive feedback and guide our team members’ professional development. However, the specific language used in these conversations can be incredibly challenging for developers who are still building their fluency in English, particularly when it comes to technical discussions and performance evaluations. It’s not simply about translating words; it’s about understanding the intent behind phrases and adapting your communication style to ensure clarity and respect. A common pitfall is using overly formal or complex language that can feel intimidating or confusing. Remember, the goal isn’t to impress with vocabulary but to be understood and help your team thrive.

One area where this becomes particularly relevant is in code review comments. Instead of a blunt “This doesn’t work,” consider phrasing it as, “I noticed a potential issue here – could we explore adding some error handling to gracefully manage this scenario?” This provides context, suggests a solution, and avoids direct criticism. Similarly, when describing changes in a Pull Request (PR) description, avoid overly technical jargon. Instead of “Optimized the algorithm for improved throughput,” try “This PR improves performance by streamlining the data processing flow.” The latter is more accessible and clearly communicates the value of the change. These small shifts in language can dramatically improve comprehension and reduce potential misunderstandings.

Furthermore, it’s crucial to be mindful of phrasing related to “development areas” – those specific skills or knowledge gaps a team member needs to address. Rather than saying “Your documentation needs improvement,” which can feel accusatory, try “Let’s focus on developing stronger documentation practices to ensure the long-term maintainability of this module.” This reframes the feedback as an opportunity for growth and emphasizes the impact of improved documentation. Similarly, when discussing career goals and aspirations – often referred to as ‘growth conversations’ - using phrases like “What are your ambitions within the team?” or “How can I support you in reaching your professional objectives?” demonstrates genuine interest and provides a space for open dialogue.

Finally, remember that active listening is paramount. If a developer struggles to articulate their thoughts clearly due to language barriers, be patient and encourage them to clarify. Paraphrasing what they’ve said back to them – “So, if I understand correctly, you’re saying…” – can significantly reduce confusion and foster a more collaborative environment. Don’t hesitate to use visual aids or examples to illustrate complex concepts. Building a culture of open communication, where vulnerability is embraced and mistakes are seen as learning opportunities, is essential for all team members, especially those still developing their English proficiency.