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.