Engineering KPIs You MUST Start Measuring NOW

It’s not about being the best. It’s about being better than you were yesterday.  — unknown

For the last few weeks, we have been exploring the Key Performance Indicators (or KPIs) that your company should start measuring and using, if you are not already doing so.  To continue the series, today I’ll be focusing on metrics related to your engineering teams, specifically software engineering.

Over the years, I’ve managed a large number of software engineers, either directly as a manager, or indirectly as a product manager. In my experience, software engineers are an interesting and fun mix of scientist and artist.  They take great pride in their work, as evidenced by the variety and evolution of the titles they use: programmer, coder, developer, software engineer, and sometimes even architect.  This pride and ownership of their creation is certainly something you want to foster.  Still, it also comes with some costs and risks, as the pride can manifest as zealotry – especially when it comes to adhering to process norms, or seeking design perfection over business value.

Establishing a priority on meeting certain quantifiable goals can really help the engineering team to see eye-to-eye with management on what’s most important to the business, which in turn helps them achieve clarity on how their work contributes to the overall mission.  Here are some KPIs I highly recommend:

• Estimate to actual ratio – this is exactly the same as the KPI for Professional Services I recommended in the 2^nd post in this series: it’s the ratio of how much time they estimated their work to take to the time it actually takes. The objective here is to continuously improve Engineering’s estimation accuracy, both to optimize performance, and, critically, to enable more informed decision-making when it comes to choosing one R&D/product investment over another.  When Product Management presents several options to leadership for different product directions, the decision must take into account the cost of each option, both in engineering time, and in time to market.
• Velocity & rate of change – Velocity – often known as throughput – is a measurement of engineering’s throughput, and the rate of change is the increase/decrease in that metric over time. While there’s no cardinal standard for “good”, the objective is to improve velocity over time, and nothing facilitates improvement more than a clear & regular measurement of performance.
• Build-to-production defect ratio – Bugs happen. It’s inevitable. The raw number of defects is often used to gauge code quality; but I’m more concerned about WHEN defects are found than how many. This is because a bug is much cheaper to fix – both in absolute effort and in its impact on the market – if it’s found during the build process, rather than after the product is in production. Tracking on a ratio of where in the build-release cycle defects are found can really help your quality assurance team (and engineers) focus on moving quality upstream as much as practical.

You will need to instrument the engineering team to track their time in order to create accurate metrics for these KPIs.

Of course, the ultimate measure of success of engineering is that the delivered product – as guided by product management – drives revenue growth via new market addressability, higher marketing conversions, win rate, upsells to existing clients, etc.  But those kinds of metrics are outside the scope of this post.

Meanwhile, I have found that improving the engineering team’s estimation accuracy, their velocity (efficiency), and the proactiveness of their quality efforts are all absolutely essential to maximizing the value they can deliver to the company overall.

Read the updated version of this post: 2020 Engineering KPIs to Start Measuring Now

Want to learn more about how Journyx can help you track metrics for your Engineering team? Visit the Jourynx for Engineering solutions page.