The way we evaluate developer performance is broken

“A developer’s job is to build  —  build it fast and build it right.”

For a long time I bought into that mentality, and it served me quite well as a developer. I would build things fast, my code was well structured and tested, and I got along with my team really well. I was congratulated and rewarded for doing this. I was called a “top performer.” It didn’t matter whether the project was a success or failed miserably. As long as I did my job of building it well, that’s all that mattered.

Performance evaluations of developers in most companies tend to focus around these three questions:

1. Speed: How quickly can you write code?
2. Quality: What is the quality of the code you write?
3. Teamwork: How well do you work with the people around you?

While those areas address essential day-to-day skills needed to be a good developer, they ignore the broader product context and feed into an already ingrained developer mentality of “my role is just to build,” with zero accountability for overall product goals (i.e., why we’re building it).

So why is this a problem?

Aren’t product goals and results the product manager’s job? If developers start worrying about conversion rates and KPIs, won’t it start taking their focus away from doing what they do best? That depends.

First, if you’re operating in a Waterfall-like environment where developers have little or no involvement in anything beyond the build phase, it would be unfair to hold them accountable for something they have no control over.

However, in an agile scrum-like environment where an autonomous team collectively owns a project with certain objectives, developers can and should be accountable for results along with every other contributing member of the team. While the product manager drives the product strategy, developers should be able to understand and buy in to that strategy, and ultimately, leverage their technical knowledge to influence product decisions.

Having that collective ownership and accountability encourages developers to think creatively about the implementation and optimize for achieving the product goals, rather than just building solutions that are technically interesting.

I’ll be the first to admit that I’ve often jumped at the opportunity to build a technically challenging solution rather than questioning its value to the product or suggesting a simpler solution that may still achieve the same product goals. Harder is more interesting, so that bias towards the harder is default behavior for a developer.

I recall an exchange I had with a product manager a few years ago:

PM: We should allow customers to save their credit card for future purchases.

Me: Sure, we can encrypt credit card numbers before storing them in our database. For better security, we should use a separate database server with stricter protocols around access. We’ll also require proper key management policies for the encryption keys, so we should get Ops involved.

PM: Sounds complicated, but security is essential here, so let’s definitely do that.

Later, I realized that my suggested implementation was completely unnecessary for our use case. We could deliver the same user value with a much simpler implementation:

Me: If our goal is to reduce the friction for returning customers, we don’t actually need to store the credit card numbers in our database. Instead, we can tokenize credit cards on our payment gateway so we don’t have to deal with storing the actual credit card numbers but can still allow customers to reuse a saved (tokenized) credit card.

Focus on the bigger picture

At a certain point in my career, I realized that my team’s ability to move faster was limited by my understanding of the product and product goals. I was working fast but not necessarily working smart. I was the bottleneck.

So I started asking questions. I wanted to know the reasoning behind the product decisions. I realized that I needed to influence those decisions. My mentality as a developer started to change. I started asking questions about UX and customer value. Rather than leaping at the opportunity to build a feature that was technically complex, I started finding ways to de-scope the complexity if it didn’t add significant customer value.

As a development manager, I try to instill the same mentality among the developers in my team: For everything you build, make sure you know why you’re building it and make sure it is worth it. You should understand the product decisions and challenge them if you disagree with them.

An important prerequisite here is team autonomy and collective ownership within the team. If the team, or individuals within the team, don’t have a voice to influence the product, then that needs to be fixed first.

With that, we can redefine the evaluation criteria for developers:

1. Results: How much have you contributed towards achieving your team’s product goals?
2. Sustainability: How sustainable is the work that you produce in the long term?
3. Teamwork: How are you making the people around you better?

Speed and quality are still relevant, but only in the service of achieving results and sustainability, respectively. And teamwork is not just about getting along with your team but also about actually having a positive impact on them.

Putting it into practice

So how do you evaluate developers on results, sustainability, and teamwork? I’ve found that asking the following questions is a good starting point:

Results

• How well do they understand the product goals?
• Have they been able to leverage their technical knowledge to cut scope while maintaining the overall goals (e.g., “We can use an open source UI library to build it faster while providing a similar user experience.”)?

• Have they been able to leverage their technical knowledge to improve the product ( e.g., “We can pre-load the user’s profile information in the background to provide a better experience which could help drive conversion.”)?
• How fast do they complete their tasks? Speed is still relevant.

Sustainability

• How much technical debt are they adding? Is it justified? I.e., does the quality of their code positively or negatively impact our ability to achieve future product objectives?

Teamwork

• Do they share knowledge with their team members, and do their team members learn from them?
• Do their team members get help from them?

The point here is to change the mindset of developers from just being builders to being owners vested in the success of what they are building. Developers who have this mindset are uniquely positioned to make a profound impact on the product because of their ability to combine product knowledge with deep technical expertise.

Changing mindset is not easy, but tying it into the way developers are evaluated sets a clear expectation that a developer’s job is not just to build but also to inform what gets built.

Zach Mathew is Manager of Development at FreshBooks.