Performance Goals That Survive the Roadmap
In my current role, we use a tool called 15Five to set individual quarterly performance goals for our employees. I believe this is mostly an effort from HR to have some sort of paper trail to point to in case an underperformer has to be PIP'd. However, there isn't a ton of guidance on how goals should be set (or even whether they should be set by managers or the employees themselves). Since I have to use this system, I have been doing my best to make it fair and valuable to my engineers. Over several iterations, I've landed on a system that I feel reasonably good about, so I thought I'd share it.
Iteration 0: Set your own development goal
The first time through the process, I worked with my team to set personal development goals. These would help the team grow in areas that they and the company cared about. For example: "Learn how our Kubernetes cluster management works" or "Take an online course on Angular testing patterns." Some folks completed these goals and others didn't. Either way, they weren't really correlated to their day-to-day performance. So when HR asked why I was rating some folks as Exceeding Expectations and others as Meeting Expectations, the goals didn't help answer the question. No bueno.
Lesson: These should be goals tied to individual performance, not self development.
Iteration 1: Set the product roadmap as a goal
So look, we know what's coming down the roadmap, right? So let's set executing on those projects as the goal. Alice, you get "Ship Project Icarus" as a goal. Bob, you're in between things so you get "Ship Project Calypso" and "Start the next project in the Velocity Initiative." Easy peasy.
Unsurprisingly, the roadmap changes, and priorities shift. Project Calypso is tabled, and Bob is pulled to urgent customer issues. Bob did great work, but his goal shows none of it. Poor Bob.
Lesson: Priorities change. Goals must roll with that.
Iteration 1.5: Adjust the goals retroactively
For a while, I tried to keep up with these changes by evaluating the goals toward the end of each period, adjusting them to what the priorities turned out to be. But with 12 reports, setting and adjusting goals for each involved a significant amount of toil. And deep down, I knew that this was appeasing the request to have goals, without actually getting much real value out of them.
Lesson: If the goals only exist to satisfy a request, they aren't worth maintaining.
Iteration 2: Capture SWE responsibilities as goals
Now, I try to set the same goals for each of my reports. There are currently four goals, each structured to be resilient to priority changes:
- Execute on the Product Roadmap - This is what most people naturally gravitate to day to day. This is the visible project work on their plate.
- Maintain System Health - This is proactively doing things to reduce technical debt, prevent degradations in security and performance, etc. This is important work that often goes unprioritized.
- Respond to Production Needs - This is more reactive. Triaging and fixing bugs, holding the on-call pager, and addressing follow-ups to major incidents. This work usually gets done, but often goes unrecognized.
- Contribute to Shared Understanding - While the other goals are primarily individually focused, this one helps counteract anybody focusing on their own performance at the expense of the team. Are you doing code reviews, writing and reading technical design docs, mentoring your juniors?
While the categories are the same, the details do shift based on leveling. (In 15Five terms, these are the KRs within the goal.) A junior engineer's expectation to contribute to shared understanding may be "ask questions on PRs" while a Staff engineer should be actively mentoring. This ensures that each goal is still a reasonable expectation for that individual. (tbh, I asked Claude to generate these KRs from our org's leveling table.)
At the end of each quarter, I evaluate each person across these categories. 15Five displays goal completions as a percentage, capped at 100% (no extra credit!). I only use multiples of 5% to avoid false precision:
- <80% - Below Expectations - Consistently short of the bar
- 80-85% - Approaching - Partial / inconsistent
- 90% - Meeting - Solidly at-level, the healthy default
- 95-100% - Exceeding - Sustained above-level, evidence of next-level performance
Using this scale gives me space to describe the shape of somebody's impact during that period. If Bob spent a quarter heads down on a migration and let some bugs slip, he can get an 80% on Respond to Production Needs but a 100% on Maintain System Health. When I sit down with HR to calibrate, I still see the average 90% result to confidently say he's meeting expectations. (Importantly, 80% would mean that Bob was actually falling behind expectations in that area. In a quarter with no bugs, no incidents, everybody can get a 90%. Don't penalize people for things outside their control!)
And most importantly, in my opinion, seeing that shape can drive useful conversations with the engineer directly. Bob sees that 80% and we talk about whether or how to adjust focus next quarter. I can flag that Alice is delivering project after project while tech debt accumulates, before it becomes a critical issue.
It works, for now
So this is what I'm settled on for the time being. That being said, I have little doubt that this will change again going forward. AI is changing a lot of what the day-to-day experience of software engineering entails. Will these categories hold up? Will others be needed? (Is editing CLAUDE.md 'contributing to shared understanding'?) What do you think?
Cheers!