I Built a Performance Review Gem — Here's What It Actually Does

Keywords: performance review, AI for managers, Gemini Gem, feedback writing, HR review, engineer management, professional development

Reading time: ~8 minutes

I've written somewhere around 80 performance reviews in my career. The first few were bad. Not in the sense that they were unfair — they were sloppy. Vague praise that didn't help anyone develop. Blunt criticism that landed poorly in formal HR documents. Observations I should have included but talked myself out of because I couldn't find the right words.

Writing a good performance review takes practice. You have to be accurate, fair, constructive, and appropriately formal — all at once, for multiple people, usually under deadline. It's one of the hardest writing tasks in any professional setting because the audience is reading for their career, not for entertainment.

My Performance Review Gem doesn't evaluate people for me. The judgment about how someone is doing is mine. What the Gem does is help me translate that judgment into well-structured, appropriately-worded review language that holds up as an HR document and actually helps the person develop.

The Problem I Was Trying to Solve

Three specific problems kept showing up in my reviews before I built this Gem.

First, observations I had trouble phrasing. Things I knew to be true about someone's work — "they always come unprepared to meetings," "their documentation is consistently weak," "they avoid difficult conversations with peers" — that I couldn't translate into HR-appropriate language without losing the meaning. I'd either soften it too much (and the feedback lost its value) or write it bluntly (and it created a problem in the HR file).

Second, reviews that covered the easy stuff and skipped the hard stuff. I had a pattern of writing detailed sections about what someone did well and vague sections about what they needed to improve. The Gem forces me to write both with the same level of specificity.

Third, inconsistent tone across team members. The same quality of work would be described in different ways depending on how much I personally liked the person — a problem I didn't fully recognize until I read three reviews back to back and noticed that two engineers with similar performance gaps had very different feedback. The one I liked better got softer language for the same issue.

The Gem doesn't fix any of these on its own — it still requires my judgment — but it gives me a structured framework and language that's harder to drift from than a blank page.

What I Tried First (and Why It Wasn't Enough)

My first attempt was a review template with sections to fill in: Results, Behaviors, Development, Goals. The structure helped. But the language I wrote into each section still drifted toward either too vague or too blunt.

Second attempt was having HR review my drafts before I finalized them. This caught the legally risky language but didn't help with the consistency or the translation problem. By the time HR saw the draft, the language was already chosen.

Third attempt was reading other managers' reviews to find a house style. There wasn't one. Every manager wrote in a different voice. I was trying to standardize something that wasn't standardized in the first place.

What I wanted was a tool that took my honest observations — the ones I'd write in a private notebook — and offered me structured, HR-appropriate language options. Not to replace my judgment, but to give me starting points that wouldn't put me in an awkward HR position later.

The Performance Review Gem did exactly that.

The Gem I Use

Here's the core of the instructions I saved into the Gem:

You are my performance review writing assistant. You help translate observations into structured, constructive review language. When I describe a team member's performance:

  • Structure the review with clear sections: Results, Behaviors/Collaboration, Development Areas, Looking Ahead
  • Convert informal observations into professional, specific feedback language
  • Ensure development feedback is constructive and actionable, not just critical
  • Flag anything that sounds vague, legally risky, or inconsistent in tone
  • Ask for specific examples if I'm being too general

My context: managing technical staff in an IT infrastructure team. Reviews are formal HR documents. I value directness but need appropriate professional language.

The "ask for specific examples if I'm being too general" instruction is the one I undervalued when I first wrote it. It's the most important. It keeps the Gem from letting me write vague praise or vague criticism, which is the failure mode I had most often before.

Two Real Examples — Before and After

These are based on actual reviews I've written. Names and specific work are changed, but the language transformations are real.

Example 1: Documentation Resistance

Situation. An engineer delivered consistently high-quality work — solid designs, clean implementation, reliable production behavior. But they consistently resisted documentation. Every project we shipped had weaker docs than the work itself warranted. I needed to frame this as a development area without making it sound like a complaint about the engineer's character.

What I asked the Gem:

"This engineer consistently delivers quality work but resists documentation. How do I frame that as a development area without it sounding like a complaint?"

Gem's draft (edited version I used):

Development Area: Documentation Practices

[Engineer] consistently produces high-quality technical work, including [specific project] and [specific project]. The technical depth and reliability of these contributions is a clear strength.

The area for continued development is documentation. Documentation that captures design decisions, operational procedures, and lessons learned is essential for team scalability and on-call sustainability. [Engineer]'s documentation has been less consistent than their implementation work — several recent projects shipped with thinner docs than the complexity warranted, requiring additional handover time.

For the next review period, the goal is to bring documentation practice to the same level as implementation practice. Concretely: every project should include a design doc before implementation begins and an operational runbook before handoff to the on-call rotation.

What the draft got right. It opened by acknowledging the strength before pivoting to the development area, which kept the feedback from reading as criticism of the whole person. The problem was described in operational terms (handover time, on-call sustainability) rather than character terms. The forward-looking goal was concrete and measurable, not aspirational.

What I changed. About 15% — added specific project names, tightened one phrase, removed an alternative version the Gem offered. The structure was the Gem's. The judgment about what to include and how to frame it was mine.

Example 2: Strength Recognition Without Vague Praise

Situation. A newer engineer had quietly become the team's go-to person for one specific subsystem. Customers and peers both mentioned them by name when talking about that area. I wanted to highlight this as a strength in the review in a way that was specific enough to be useful — not just "great work this period."

What I asked the Gem:

"I want to highlight this engineer's growth — they've become the team's go-to person for the [subsystem]. Make it specific."

Gem's draft (edited version I used):

Strength: Subject Matter Expertise in [Subsystem]

Over this review period, [Engineer] has become the team's primary technical reference for [subsystem]. This was visible in three concrete ways:

First, [specific contribution — e.g., leading the migration of X]. Second, peer recognition — team members consistently route questions about this area to [Engineer] first. Third, customer trust — at least two enterprise customers have referenced [Engineer] by name when discussing [subsystem] performance.

This depth of expertise, developed in less than two years on the team, is the kind of growth we want to see replicated across other areas.

What the draft got right. Three concrete examples instead of generic praise. The framing was specific enough that the engineer could read it and know exactly which work was being recognized. The closing line pointed toward future development without making the strength feel like a ceiling.

What I changed. About 10% — added the specific names, removed one of the example lines the Gem offered as alternative, signed off. The structure was the Gem's.

Where This Works and Where It Doesn't

After using this Gem across two review cycles for about 12 people, here's an honest assessment.

It works well for:

  • Translation problems — when I know what I want to say but can't find the words that fit an HR document.
  • Forcing specificity — the "ask for examples if I'm being too general" rule pushes me past vague praise or vague criticism.
  • Structuring the review — having the section order pre-decided removes one decision from a process that already has too many.
  • Tone consistency across team members — the same quality gap gets similar language regardless of who wrote the review.

It doesn't work well for:

  • Performance issues involving potential termination or formal discipline. Those need HR involvement before drafting, not as a final review.
  • Reviews where the relationship is significantly strained. The Gem optimizes for constructive framing, but if the underlying relationship needs direct conversation first, the written review comes second.
  • Reviews where I haven't been paying close enough attention. The Gem can't manufacture observations. If I don't have specific examples to feed in, the output will be generic regardless of how well I use it.
  • Cross-functional reviews where the criteria aren't mine. When I'm writing about someone's work in an area I don't directly oversee, I shouldn't be writing the review at all.

A Note on Managerial Judgment

The Gem is a writing tool. It doesn't make the actual performance decisions — what rating someone gets, whether they're on track for promotion, whether a development area is severe enough to put them on a formal plan. Those decisions still require managerial judgment, accountability, and usually conversation with the person before the written review is finalized.

What the Gem gives me is a way to take the judgments I've already made and write them down in language that holds up. The hardest part of writing a review isn't the words. It's deciding what you actually think about someone's work. The Gem doesn't do that part — and it shouldn't. But once you've decided, translating that into HR-appropriate language without losing meaning is a real skill, and it's one I'd rather have help with than do alone.

Sources

— Justin

📅 First published: 2026-05-08 | 🔄 Last updated: 2026-06-21