Customer-success-driven metrics for measuring Dev Team performance

It's been a few months now that I have spent researching how to effectively measure the performance of software engineering teams.

The very first metric that we all know—and we all know it doesn't work—is estimating man-hours per ticket and measuring whether the estimate was met.

This approach was replaced by Agile and Story Points. Again, I think we all already know its downfalls. That's why the industry moved on to further research.

In recent years, we've seen performance metrics frameworks like SPACE, DORA, and DevEx. They are great for measuring our deliverability excellence, but is this really interesting to Product and Management teams? Does it actually matter to them if we can pick up a ticket and deliver the change to production in 10 minutes? What if you're that fast but working on the wrong things that bring no value to the business? What if you optimize Lead Time to Change by splitting the same feature into an infinite number of small chunks, but the feature itself takes the same time to deliver as before?

Of course, I am not saying optimizing this part is unimportant, but it is not the essence of business growth. And, of course, I am not claiming to have discovered something new here—these facts are described by the inventors or facilitators of these frameworks too (you should check out Laura Tacho and Abi Noda).

For me, something still felt missing. I started to realize that these metrics aren't directly showing the business impact of development teams because we tend to think about development teams in the wrong way. We've gotten used to thinking that the objective of dev teams is to build features, code quickly, ensure code quality, minimize bugs, manage architecture, handle infrastructure, and so on.

✅ So we measure those things to gauge dev teams' productivity.

Meanwhile, aspects like customers, business growth, product growth, sales, and marketing are seen as the responsibilities of other teams.

❌ So we don't measure those aspects for dev teams' productivity.

But shouldn't we? 🤔

Believe me, as a developer, I had to come to terms with this too, but: is it really interesting to anyone (besides engineers) whether the code is clean, tech debt is low, or test coverage is high?

I first heard about this paradigm shift in the Lean Startup podcast (unfortunately, it was a while ago, and I cannot find the specific episode). It suggested that engineers should focus on optimizing the biggest risk in the product/business model. Sometimes, this involves performance, quality, technical debt, or coding features. But sometimes, it's about creating a website that converts better or improving user metrics. (Of course, the talk itself went much deeper.)

This insight made me think that software developers should turn into product developers.

Then I saw Radek Maziarka writing about the same thing (PL version):

Product Engineer - nowa rola?

Later, I discussed this with my fellow Head of Engineering. I shared my thoughts on DORA and measuring the performance of dev teams (as described above). He told me:
"Such consciousness of the importance of measuring dev teams' performance is still rare, but it is growing. We measure DORA with some of our clients, but also prefer to extend the view with other, more customer-oriented metrics."

Finally, just yesterday, I stumbled across this podcast episode that inspired me to write this post:

In it, Gokul Rajaram describes the essence: teams in an organization should be organized around business objectives, not products. For example, instead of having an Android Team, iOS Team, and Web App Team, teams should focus on customer acquisition, customer engagement, and so on.

Teams should have business objectives such as:

📈 Increase customer acquisition from X to Y per month

📈 Decrease monthly customer churn from Z to W

This mindset shifts teams away from being siloed (product team, dev team, QA team) to being aligned around business objectives. It sets everyone on the team toward the same goal, removing friction between disciplines. 🤝

Then, teams are given customer-oriented metrics and incentivized based on those metrics.

This makes it easier to measure the team's performance.

At this point, does it matter how many lines of code they wrote? What their Lead Time to Change is? Or their Change Failure Rate?
Is it even important if they really spent their 8 hours at the computer? 🤯

Of course, within the team, there will still be software developers, QA engineers, product people, and data analysts doing what they're best at. But they'll have a different mindset and better cooperation.

This mindset makes everything easier: it removes friction between disciplines, eliminates micromanagement, makes people proactive and engaged, helps them understand the business better, and, finally:

💥 It makes it easier to measure actual performance. 💥

It's like another step in the evolution of interoperability teams that Agile introduced.

But is it even possible to introduce? For decades, software engineers were expected to work on engineering issues while the business side handled customer concerns. Engineers often don't want to bother with customer satisfaction when they have an important bug to fix.

Won't they embrace this mindset?

They used to work very differently before the Agile Manifesto, and today we "all" work in Agile fashion. It has become an obvious part of engineering best practices.

How about now? It's been over 20 years since the Agile Manifesto was published.
Have we, the software engineering industry, evolved enough to benefit from a new

📝 Product Development Manifesto?