“You need to finish ten tickets this sprint.”

In all my years as an engineering manager, I have never uttered those words. Counting tickets is a fundamentally flawed way to measure developer productivity. If you want to build a high-performing engineering organization, performance evaluation has to start with the business value we deliver, and it must end with the health of the team.

The reality is that team health and productivity rarely get translated directly into business KPIs. You cannot drive these factors on an isolated, individual basis; it requires a shared understanding across leadership. It is never just about delivering code. It is about the quality of that code and the quality of life of the people writing it.

Measuring the Unmeasurable: DX and Empathy

If we aren’t counting tickets, how do we measure success? We do not use direct, hard KPIs for team health. Instead, we rely heavily on qualitative metrics: regular engagement surveys and the Developer Experience (DX) framework. This approach places qualitative factors on an equal footing, or even above the quantitative ones.

Velocity is a signal, certainly. If it drops, I look at what is going on. But if velocity keeps rising while the team is quietly unhappy, you will only learn that through surveys and direct conversations. That is precisely where the human manager comes in. How much empathy can you bring to the table? How do you translate the team’s reality back to the business so they stay connected? In a world increasingly driven by AI and automated agents, that translation layer is the true value of a manager.

Code Quality in the Age of AI

When it comes to the quantitative side of code quality, we have tools like SonarQube. But the landscape is shifting at a breakneck pace. We are entering an era where one AI agent writes the code, another reviews it, and the same automation lives in your deployment pipelines. My teams and I are in constant experimentation here.

However, this AI-driven future only works if a team already has a shared understanding of what “good” looks like: linting, formatting, and coding standards. Organizations that never established that baseline are going to see absolute chaos now.

The Cascade of OKRs and the Power of the Rubric

Because I do not give developers individual KPIs, we rely on a cascade of OKRs. It starts with where the company is heading, moves to what the engineering org contributes, narrows to the team’s goals, and finally anchors on where the individual sits within that team. It requires a top-down agreement on business goals, and a bottom-up effort to help everybody connect their day-to-day work to those goals.

So, how do I determine if someone is strong or weak within the team? Through the career rubric, and through hiring.

As a hiring manager, my job is to gatekeep when the hiring happens. I sit in every single interview call because I need absolute clarity about where a person fits within our rubric. If someone is hired as a senior engineer, it is because they matched the criteria for a senior engineer and are placed there from day one. If I inherit a team, I rely on the shared understanding of the people who hired them before me.

But to do this, I need the company’s framework: How is performance evaluated? How is it incentivized? Is there a shared understanding of what good performance actually looks like? Performance cannot be about how I feel, how the team feels, or how my peers feel. It has to be grounded in reality. That is why the rubric is non-negotiable.

If There Is No Rubric, Write One

If a company doesn’t have a rubric, I go and write one. I have done this more than once.

It starts with fundamental questions: How do we want to reward performance, and how do we manage it? In its simplest form, the rubric runs along the standard company levels: mid, senior, staff, and answers a vital question for each: What does good look like, what does better look like, and what does best look like?

The criteria must be a mix of technical and behavioral skills. How does someone write code? Do they test often? How do they articulate a problem? How do they define that problem in the first place? How do they drive influence, react to pressure, and behave with their peers?

And a rubric isn’t a static document. It needs regular reassessment, especially now. We have to ask: What does AI adoption look like for a senior developer? How do they learn?

Growth is Not Automatic

Just because someone holds a senior title doesn’t mean they stay there automatically. An engineer who comes in strong can continue to thrive, or they can deteriorate. I monitor that through continuous feedback and the connection built in one-on-ones.

If a senior engineer wants to grow into a staff role, writing exceptional code is no longer enough. They need to build influence outside their immediate team and become a force multiplier. My job is to create those exact opportunities. Having them write architecture docs if they never have before, and ensuring they show up and present outside of our team bubble.

None of this means a developer’s quantitative work is ignored in their assessment, but it is not addressed directly as a KPI miss. I will never say, “You did not write tests, so you missed your KPI.” In fact, the quantitative side is rarely discussed in a one-on-one. For that to work, the team needs a culture of giving continuous feedback. It shouldn’t be my job to point out missing tests; the team should organically say, “Let’s write tests.”

My job is to ensure that shared understanding exists, to resolve behavioral conflicts, and to help people become force multipliers beyond their domain. I don’t micromanage the quantitative; I help shape the qualitative environment that makes the quantitative thrive.