In my previous blog, I talked about the Career Ladder as one of the five pillars to prepare your engineering department for growth. In this article, I  talk about another important pillar, building a high-performance team.

So what does a high-performance team mean? There are several definitions but to us, it’s a team that is constantly achieving and improving specific agreed key performance indicators (KPIs) and embraces the fact that in order to improve you need to measure KPIs.

In Marketing and Sales, we started working for a while on measuring specific KPIs aligned to our vision –  lead conversions, cost per lead, and our sales pipeline, but when it came to Engineering, especially development, we did not have a defined and easy way to do it.  We measured agile KPIs at a team level (DEV, QA, Scrum master, UX/UI) but not specific to one of our core competencies which is software development.

We started to research how to measure meaningful KPIs that will make our software development more efficient and productive without going back to the useless metrics such as lines of code. I wanted an easy way to show that our Software Engineers are improving by showing data that backs it up and not by arbitrary and subjective input.

There are not many tools that provide what we were looking for, from the ones we tested, we ended up going with  GitPrime because they had collected industry standard data which allows you to see where your company stands in comparison to other companies that develop software. When we first introduced the tool to our Software Engineers, we were careful to make it clear that this tool was being used to measure the team’s success and not there to micromanage their work.

From the top-down, the message was focused on improvement, growth and increasing self-awareness so the teams and organization can evolve. The emphasis was that this tool would help you as a Software Engineer to understand your current development patterns, adjust them if needed, measure the results and keep improving them based on a defined goal until your mindset is shifted towards a development practice that not only allows you to plan your development efforts but also helps to improve the Sprint throughput since you are now constantly releasing small chunks of code and features.

We’ve been using the tool less than a year and have seen improvements compared to the baselines (2017) we had before the tool. In less than a year, we have noticed the following KPIs by the end of 2018:

Our Software Engineers commit code 7 times a day on average compared to 3.4 times a year ago. That is a 105% increase.

Our Software Engineers commit code 4.3 days on average in a 5 day week compared to 2.3 a year ago. That represents an 86% increase.

This may sound easy to accomplish but there is a lot of work needed, including a mindset shift to be able to understand and improve your development practices. For instance, our Software Engineers put a lot of effort during Scrum planning so stories can be split in a way that can be delivered in a pull request every day if possible, that way the story gets to UX/UI Review and QA early on during the Sprint making the whole Sprint cycle more efficient and productive. Our QA’s appreciated this a lot since now they can test small features that add value from the get-go and not rushing the testing when features come late in the Sprint. The overall result is that you have a happier Product Owner that has access to features with a great level of quality very often.

Our 2019 goals from the engineering perspective are to keep improving these KPIs and be on top of the industry standards (We are very close) and also working in the code quality side, more specifically, the Code Review part which we already have a process in place but there is a lot of room for improvement once we define specific KPIs.

The final message I have is that it does not matter what tool you use,  you can build your own or use another tool, but the important part is that if you do not have a culture that embraces measuring KPIs towards constant improvement then it will be hard to build high-performance teams.

What tools are you using to measure KPIs? What successes have you seen? I look forward to hearing from you!