OKRs vs. KPIs, what are the differences? That’s a common question I hear from managers of Engineering Teams. KPIs are more straightforward to explain than OKRs, which can be tricky and more complex. They don’t mean the same, although they are connected.
What are KPIs?
KPI stands for Key Performance Indicators. In other words, KPIs are a set of metrics that should give you an overview of the area or team’s performance. They need to be measurable and comparable.
If you look at many KPIs, they’re not fulfilling their purpose. Organizations should select as few as possible so that tracking the progress is possible. Besides, all the significant changes in process and company goals should impact the numbers.
Then, managing an area or a team becomes more tangible: when the KPIs show poor performance, it’s time to act. The actions taken should reflect better numbers; otherwise, managers need to find another strategy and act differently.
What are OKRs?
OKRs stands for Objective Key Results. It’s a managing methodology that is popular in Silicon Valey. It’s been widely adopted by companies and startups at scale. It’s also seen as an alternative or complement for strategic planning.
OKRs’ primary purpose is to define Objectives that must align with the business and a set of Key Results. Each Key Result needs to have a measurable number as the goal and a limit date. The limit date means that the goal should be achieved within that time frame.
What’s the difference between KPIs and OKRs?
KPIs provide an overview of the area or team for managers, whereas OKRs must focus on its future. That said, it becomes clear that KPIs are a controlling tool, and OKRs intend to change an organization’s status quo and keep track of its progress by periodic assessment meetings.
It’s crucial to have that in mind when choosing the KPIs and the OKRs. Otherwise, they become useless and can even play against business goals. Let’s see some examples of them
Examples of OKRs and KPIs for Engineering Teams
Below there is a list of KPIs examples. However, you can find more examples in my article Software Engineering KPIs: how to choose the best fitting metrics.
- Deploy Frequency: it’s a sum of the number of deploys made by day, week, or month, depending on the organization’s need. It shows how frequently the team — or area — delivers value to the final user.
- Time to Merge: it measures the number of days a Pull Request remains open or under review. You can find an average or, as I prefer, see the 75th percentile of all pull requests closed in a given period. It shows how performant is the team.
- Time to Recover: how much time does the application is inaccessible after an error? This metric tells a lot about how engineering teams respond to failures.
When thinking of OKRs, Engineering Teams may consider Objectives such as:
- Improving the Time to Market of new features
- Lessen the Churn rate of the product
Here are some possible Key Results for Improving the Time to Market of new features:
- Increase the Deploy Frequency to 37/week until <insert the date>. Assuming you deploy less than 37 times a week currently, increasing the frequency means you’re delivering more. Delivering more is crucial to achieving a more competitive Time to Market.
- Reduce the 75th percentile of Time to Merge to 3 days until <insert the date>. Instead of the Median or Average, I prefer using the 75th percentile for Key Results. In other words, it means that 75% of the Pull Requests must be merged up to 3 days after they were opened. The team can achieve it by opening lighter pull requests or engaging in collaborators’ pull requests instead of working on a new work item.
For the second object, Lessen the Churn rate of the product, let’s assume you know the primary source of churn comes due to a high number of errors in the application. Then, the Key Results could include:
- Reduce the number of Technical Debts to 15 until <insert the date>. Let’s say you have 30 Technical Debts currently. It’s a 50% improvement. There are many chances that improving the codebase will positively affect the churn rate and help in the KR of the previous Objective. The cleaner the code, the better it embraces the changes. It means you can reduce the churn and also achieve better Time to Market by gardening your codebase.
- Reduce the Mean Time to Recover to Recover (MTTR) to 3 minutes until <insert the date>. The team needs to monitor application outages, connectivity problems, 503 errors, and other failures to ensure end-users’ experience is not impacted with more than 3 minutes of instability.
In short,
KPIs and OKRs are not the same. They have different purposes. KPIs aim to give managers an overview of how the team or area is working, whereas OKRs focus on providing the team a direction and then tracking its progress.
I presented some examples of KPIs and OKRs for Engineering Teams to illustrate the difference. SourceLevel provides lots of metrics, which may include your KPIs. Check out our Analytics feature, or schedule a demo with me.
If you need to define KPIs for your team, I am giving away a 30-min consultation meeting. Schedule a demo so that we can discuss your specific needs.
Originally published at https://sourcelevel.io on October 20, 2020.
