Write better performance reviews in half the time
Most engineering managers spend 20 hours writing performance reviews that nobody finds useful. Here's how to write reviews that actually help your team grow.
👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.
Performance review season can be brutal. You’ve got ten engineers to review, each one requiring thoughtful feedback on a year’s worth of work. Meanwhile, you’re still running sprints, handling incidents, and trying to keep everything else moving.
So you do what everyone does: you block off entire days on your calendar, pull up a blank template, and stare at it while slowly dying inside. Twenty hours later, you’ve produced an AI-generated document that reads like it was written by a committee of robots. Your engineer skims it, nods politely, and you both move on with your lives.
There’s a better way.
Performance Reviews
Most managers approach performance reviews like they’re writing a novel. They try to remember every single thing that happened over the past year and document everything exhaustively. The output is a document that takes forever to write and provides minimal value to the person reading it.
Your engineers don’t need a comprehensive biography. They need clear, actionable feedback that helps them grow. And you need a process that doesn’t consume your entire December.
Here’s what I think actually matters in a performance review:
What they did well and should keep doing. Not everything - the highlights. The stuff that makes them valuable to the team.
What they should work on next. One to three specific areas. Not a laundry list of every possible improvement.
Where they’re headed. The growth path you see for them, and what success looks like in the next period.
That’s it.
Start with the data you already have
You’ve been doing 1-on-1s all year, right? You’ve given feedback in real-time. You’ve seen their work, design docs, and incident responses.
Before you write anything, spend 15 minutes gathering:
Your 1-on-1 notes from the past 6-12 months
Feedback you’ve given them (positive and constructive)
Their key projects and impact
Peer feedback that you have collected
I keep a simple doc for each person on my team where I record notable moments throughout the year. “Sarah’s incident response on that Sev2 issue was stellar.” “Mike’s mentoring of the new hires is leveling up the whole team.” Takes me 30 seconds when something happens, saves me hours during review season.
If you don’t have this system yet, you should start it after this cycle. For now, check your Slack DMs, email, and 1-on-1 docs. You’ll find more than you think.
Write the way you talk
The best performance reviews sound like they were written by a human who knows you.
Instead of: “Demonstrated strong technical acumen and cross-functional collaboration capabilities.”
Write this: “Your technical judgment has gotten noticeably stronger this year. The way you handled the database migration - thinking through the edge cases, coordinating with the platform team - that’s the kind of ownership we need more of.”
One sounds like it came from a template. The other sounds like it came from your actual manager.
Use specific examples. Don’t say “good at debugging”. Say “You tracked down that race condition in the payment service that the rest of us had been staring at for two days. That kind of tenacity and systematic thinking is exactly what senior engineers do.”
Keep your sentences clear and direct. Write like you talk in your 1-on-1s.
If you’re enjoying this article, you might also like some of this year’s most popular posts:
Focus on 3 things maximum
Don’t try to cover everything. Every project. Every skill. Every possible area for growth.
Your engineer will remember three things from their review. Maybe. So be ruthless about what you want to highlight.
Pick your top three for strengths. The things they’re genuinely good at that make them valuable to the team. The skills you’d mention if someone asked you why you’re glad this person is on your team.
Pick one to three areas for growth. Not every possible improvement. Not every skill gap. The specific things that will unlock their next level.
I used to write these super long reviews covering eight different areas for development. As a result, my engineers would focus on whichever one felt easiest and ignore the rest. Now I’m explicit: “Here’s the one thing that will make the biggest difference for you this year”.
Use the “Keep, Start, Stop” framework
When you’re stuck on how to structure your feedback, try this:
Keep doing: The behaviours and approaches that are working well. Be specific about why they matter.
Start doing: New behaviours or skills that will help them level up. Tie these to their career goals when possible.
Stop doing: The habits or patterns that are holding them back. These are often the hardest to write, but also the most valuable.
For example:
Keep: Taking time to document your architectural decisions. Your ADRs have become the standard that the rest of the team follows.
Start: Speaking up more in planning meetings. You’ve got good instincts about technical risk, but you tend to stay quiet until we’re already committed to an approach.
Stop: Saying yes to every request that comes your way. You’re spread too thin, and it’s affecting the quality of your core work.
This framework forces you to be concrete. You can’t hide behind vague statements like “needs to improve communication skills”. You have to say what they should actually do differently.
Bring to life the Career Conversation
Don’t hide the career development points at the end, where nobody reads them.
Based on their performance and goals, what’s the logical next step for them? Are they close to being promoted? If not, what’s the gap? If they’re crushing it in their current level, what does the next level look like?
Be honest here. If they’re asking about promotion but they’re not ready yet, say so - and be specific about why. “You’re strong technically, but you’re working in isolation. To get to senior, we need to see you pulling projects across the finish line and helping other engineers level up.”
And if they’re on track for promotion? Tell them that too. “You’re operating at senior level already. Let’s start creating your promotion case together this quarter.”
The worst thing you can do is leave your engineers guessing about where they’re at.
The writing process
Here’s my actual process for writing a review:
Pull up all your notes, peer feedback and their key work. Refresh your memory.
Write the summary section. This is your high-level take on their year. Three to five paragraphs maximum.
Write three key strengths with specific examples. Then write 1-3 areas for growth.
Write the career development section. Where are they headed? What’s next?
Read it through once. Fix obvious typos.
That’s it. You’re not writing a dissertation. You’re writing useful feedback for someone you work with every day.
Some reviews will take longer - maybe someone’s struggling and you need to be more careful with your words. Or maybe they’re up for promotion and you need more detail. Fine. But most reviews should be done within an hour.
Before you submit it
Read your review out loud. If it sounds weird or robotic when you say it, it’ll read that way too.
Ask yourself, if I were this person, would this review actually help me? Would I know what to keep doing and what to change? Would I understand where I stand?
If you can’t answer yes to those questions, you’re not done yet.
Is there anything in this review that would surprise them? If yes, you’ve not given important feedback throughout the year. Performance reviews should document conversations you’ve already had, not introduce new information when it’s too late to act on it. If your engineer reads something and thinks “wait, what?” - that’s on you for not being open enough in the moment.
A final note
The goal isn’t to write a perfect document. The goal is to help your engineers grow. That happens through clear, honest, specific feedback delivered in a way that actually lands.
Your team deserves reviews that respect their time and help them get better. And you deserve a process that doesn’t make you want to quit engineering management every December.
That’s all, folks!
See you in the next one,
~ Stephane