When capital was cheap and talent was scarce, performance management in software engineering was laser-focused on keeping people. “Below expectations” was a rating you used sparingly, and rarely needed.
That era is over. Post-ZIRP, with AI compressing what headcount companies think they need, “below expectations” is now handed out routinely — partly because it provides useful paperwork when layoffs come, and partly because in a leaner environment, the bar for “meets expectations” really has risen.
What hasn’t changed, however, is what the research says about high-performing teams. Google invested heavily in trying to understand what made them effective and the answer came down to trust, clarity, and whether people felt safe enough to take interpersonal risks. These conditions, the ones that help people do their best work, haven’t changed even as the business context around them has been turned on its head.
This post is mostly about those fundamentals, because they’re still what determine whether a performance process is useful, or punishing, to engineers. Even in organizations where ratings are being used for headcount decisions, there’s usually still room to run the process — the 1:1s, the feedback conversations, the data-gathering, the self-reviews, the calibration — in ways that are honest and fair.
How performance management works, and what it needs to do, changes a lot depending on what scale your organization is at:
Organizational growth tends to erode the proximity that good performance management depends on. Managers get further from the day-to-day; context gets filtered through summaries and calibration sessions.
More process doesn’t exactly fix that. What does fix it: keeping managers close enough to the work to form their own view of it, building structured ways for engineers to surface their own contributions rather than relying on what their manager happened to notice, and using data to recover some of the proximity that growth takes away.
Performance management defaults to the individual as its unit of analysis. But most outcomes in a software organization are produced by teams.
Before evaluating individuals, it helps to ask whether the team is set up to succeed — whether priorities are clear, whether the investment balance makes sense, whether structural constraints are creating the problems that get attributed to people. Individual performance exists within that context, not separate from it.
When you skip that step, you end up with performance conversations that assign individual blame for what are really team-level or organizational problems. An engineer’s cycle time doesn’t mean much if the team’s review process is broken. Someone’s output looks different when they’re carrying half the on-call rotation.
Before getting into frameworks and cadence, remember that the person sitting across from you (in a 1:1, in a review conversation, in a conversation about an improvement plan) has a whole life happening outside of work. None of that makes performance conversations less necessary, but how you have them matters more than most managers think.
Building psychological safety means people feel they can take interpersonal risks: ask for help, admit mistakes, disagree with a call, surface a problem they’ve spotted. Teams with high psychological safety tend to argue more than those without it, not less — the difference is that the arguments are about ideas and approaches rather than about whether it’s safe to have them. A concern that comes up often is that focusing on this means letting things slide. It doesn’t. Safety is what makes candor (radical or otherwise) possible.
You can’t have an effective performance conversation with someone who doesn’t feel safe. They’ll show up, but they won’t hear the feedback the way you intend it. Without safety as a foundation, feedback lands as a threat, growth conversations trigger anxiety, and anything framed as performance-related gets filtered through the assumption that something bad must be on its way.
A few things can help these conversations go well:
Most managers default to what’s measurable in. But while metrics feel concrete, concreteness isn’t the same as accuracy, and most of the metrics that are easy to pull don’t hold up particularly well as a read on individual engineer performance.
I asked Otto Hilska, our CEO, how he thinks about evaluating an engineer’s performance. He’s spent decades building engineering organizations. Four questions came straight off the top of his head:
These four dimensions should give you a consistent lens to apply across different engineers and different review cycles without reducing anyone’s work to a single number.
Often, engineering performance management ends up measuring what’s visible rather than what’s important.
Think about what gets recognized in many engineering organizations: the engineer who swooped in over the weekend to fix the production incident, the one who shipped the big feature two weeks early, or the one who worked overtime to get the launch out on time.
Yes, these deserve recognition, but a performance management system that rewards heroics without asking why the incident happened is basically accepting the conditions that required them. Engineers figure this out fast. If fighting fires earns praise and preventing them earns nothing, that’s a signal about what the organization values. The people who burn out first are usually the ones who care too much to let things break.
The same challenge appears in what Tanya Reilly calls “glue work”: code reviews that teach people something, documentation that new hires can use, maintaining the CI pipeline, mentoring, keeping technical debt from compounding. None of it ships on a public roadmap, and on a performance system calibrated around feature delivery, it tends to be invisible — right up until someone leaves and, surprise, no one knows how the deployment pipeline works.
Over time, people notice what gets rewarded and act accordingly. If your process consistently fails to see the work that holds teams together, you’ll end up with engineers competing to ship the next big thing while the important foundation work stops happening.
Engineering data earns its place in a performance conversation when it helps you understand what’s been happening. It doesn’t do much when it tries to replace that understanding.
If a team’s cycle time has been creeping up over a couple of months, that’s something to dig into. Maybe the work is more complex than usual. Maybe reviews are backing up. Maybe someone’s overloaded and hasn’t said anything. You don’t know until you look.
“Your cycle time is in the bottom quartile of the team” skips that step completely. It turns something that needs context into a conclusion, and puts a team-level metric onto one person. Cycle time, shaped as much by waiting as by doing, doesn’t say much about individual performance on its own.
Data is much more useful when it helps reconstruct the work: what someone spent their time on, how that connects to team priorities, where things slowed down, who they were collaborating with. That context is harder to maintain as teams grow, which is where engineering intelligence tools can help.
A caveat, though: tools in this space vary considerably. Some reduce an engineer’s work to a productivity score (commits, PRs, lines changed, blended into a composite) and present them in a table that “definitely isn’t stack ranking, we promise”.
These normalized scores are attractive if you want to get performance management done quickly. But they tend to reward the wrong things: they ignore complex work, miss the maintenance and collaboration that holds teams together, and create a false impression of rigor.
All that to say: if you’re pulling data into a performance conversation — from whatever tool — that data should support the conversation, not be the conversation.
If regular conversations are happening throughout the year, a formal review becomes a synthesis of things already discussed, not a standalone verdict. When managers save their observations for review cycles, they turn reviews into high-stakes evaluation events that produce defensiveness rather than growth. So try your best to not do that.
Engineers who do strong work but aren’t natural self-advocates are disproportionately harmed by informal, vibes-based processes. When there’s no consistent structure, the engineers who get seen tend to be the ones who are good at being seen, which isn’t always the same as being good at their job.
Cadence is more important than any individual component of the process. The more frequently performance conversations happen, the less weight the formal review has to carry. A rough structure that tends to work regardless of scale:
A good litmus test to know if your process is working: the engineers on your teams know where they stand at any given point in the year.
In some organizations, performance management has become less about development and more about documentation — building the paper trail for headcount decisions that were going to happen anyway. Ratings carry more weight, and the metrics behind them aren’t always chosen for the right reasons.
That part isn’t always something an individual engineering manager can change. What you do still have control over is how the process shows up in practice. People shouldn’t be trying to piece together where they stand from a formal review. Feedback needs to come early enough that there’s still time to respond to it — and that only works if you understand the work in enough detail that you’re not just going off whatever was most visible or most recent.
If all of those pieces are in place, your process should hold up pretty well against the ever-changing-something-landscape we’re all here living in.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
