The Role of OKRs and KPIs in Software Development

We have answered how and how not to measure software development productivity. Now it is time to move beyond metrics to the high-level goals and aims of a project and business as a whole, OKRs. Once a business has created these, measuring how teams perform daily toward these goals with KPIs becomes necessary.

Like with metrics, communicating with engineers and including them in developing goals and indicators is just as important as onboarding them with metrics. Properly developed OKRs and KPIs will help drive teams and businesses to new projects and clients, but if not approached correctly, these same goals can lead to disgruntled teams and low performance. In this article, the Enji team will share our insights into creating objectives and performance indicators.

To begin exploring the problem, let us refresh our memory of what OKRs and KPIs are with a definition and examples.

OKR (Objectives and Key Results) is a goal-setting framework businesses use to define specific, ambitious objectives and track progress through measurable key results. The objective outlines "what" you want to achieve, and key results define "how" to measure progress toward that goal. On the other hand, KPI (Key Performance Indicator) is a metric used to evaluate how well an individual, team, or organization performs against specific operational goals. Although these terms are similar in that they deal with goals, there is a key difference between them. OKRs are aspirational and set for growth and innovation, while a business uses KPIs to monitor ongoing performance and efficiency.

While separate concepts, OKRs and KPIs can complement each other within a business by serving different but interconnected roles in driving performance and growth. The strategic goals of OKRs demonstrate what a business wants to achieve over a certain period, often pushing teams toward innovation or significant progress. The business can use KPIs to monitor the performance of day-to-day operations and ensure that ongoing activities align with the overall goals of the business. Effective daily performance brings OKRs closer to completion.

Objective: Improve application quality 

1. Key result 1: Decrease customer-reported bugs by 50% within the first quarter.
2. Key result 2: Increase automated test code coverage to 90% within six months.
3. Key result 3: Achieve a product quality customer satisfaction rating of > 90% next quarter.

Lead Time

• Target: Reduce lead time to under five days by the end of Q4.

Cycle Time

• Target: Reduce cycle time to under 3 days by the end of Q4.

In theory, these are excellent OKRs and KPIs that any software development team can use to set performance goals. Management will make fair decisions on promotions and ratings while planning future projects based on these results. In practice, however, businesses require more than beautifully written objectives and performance indicators to create effective teams. Software engineers often feel alienated when measured against these points, with the value of their work reduced to numbers. It is easy to understand if we return to the two examples of KPIs above, reducing lead and cycle time.

In a sense, the KPIs are not incorrect, but what happens next could be. Imagine a manager who only relies on these time metrics to decide if a team has achieved its goals or not. At the end of the quarter, they see that neither lead nor cycle time has decreased sufficiently. The teams fail to achieve the KPIs, and the manager makes decisions according to the data: no bonuses are given, a promotion is stalled, or maybe even a team member is fired or moved to another project.

This approach ignores the details. In this example, the engineering team may have reduced cycle time from five to four days, but even less would sacrifice testing and review. If the manager does not discuss the context and KPIs with the engineers and continues to press them to achieve the goal, quality will suffer, and end users will not be satisfied with the feature or product.

This situation occurred because the original KPIs did not consider the reality of how engineers work. The metrics became the goal and not signals.

Of course, this is not the rule, and businesses cannot ignore OKRs or KPIs. There are benefits to using them to set goals and measure progress towards achieving them for both teams and leaders:

• Clear direction: OKRs provide a clear framework for setting ambitious goals, helping teams understand what they need to focus on to achieve organizational objectives.
• Alignment: Both OKRs and KPIs align team efforts with company goals, ensuring everyone is working toward the same outcomes and priorities.
• Measurable progress: KPIs allow teams to track measurable outcomes, providing concrete data to assess performance and make informed decisions.
• Increased accountability: Setting specific OKRs and KPIs creates a sense of ownership and accountability among team members for their contributions to projects.

These benefits seem rather great and advantageous for all the stakeholders involved in creating software, and yet, teams and businesses encounter challenges like the situation above when they do not properly use OKRs and KPIs to drive effectiveness and success. To understand this better, we will switch to the point of view of software engineers.

While not a very scientific approach to studying the attitude of software engineers towards OKRs and KPIs, Reddit does offer a safe environment where professionals can share their varied opinions on the topic. In this sense, it provides an insight into their opinion of these approaches to measuring performance.

In terms of OKRs, users on Reddit made the following complaints:

• Misunderstanding OKRs as milestones or tasks. Many teams confuse OKRs with project milestones or tasks, leading to a focus on outputs rather than outcomes.
• Lack of alignment and buy-in. OKRs can fail if they are not aligned with the company's strategic goals or if there is insufficient buy-in from stakeholders.
• Overcomplication and overload. Organizations may create too many OKRs, making it difficult to focus on what truly matters.
• Difficulty in measuring impact. Measuring the impact of OKRs can be challenging, especially when they are not directly tied to quantifiable outcomes.
• Inflexibility and lack of adaptation. OKRs may become irrelevant if they are not regularly reviewed and adapted to changing business needs.

Users view KPIs in similar ways, noting their dislike of certain situations:

• KPIs that don't align with overall business objectives can lead to counterproductive behavior.
• Using metrics like lines of code or the number of tickets closed as KPIs can incentivize poor-quality work.
• Developers may find ways to artificially inflate their KPI numbers without actually improving performance.
• Individual KPIs can discourage collaboration and knowledge sharing.
• Overly aggressive or unrealistic KPIs can lead to burnout and decreased morale.
• KPIs often fail to capture the full context of a developer's work.
• Too many or overly complex KPIs can be confusing and time-consuming to track.

At first glance, it may appear that these opinions demonstrate a negative relationship among software engineers toward using OKRs and KPIs in general; however, that is not the case. They are frustrated with the improper use of these goals and metrics that exclude them from the equation. Engineers want to perform well and improve their skills. The problem, in their opinion, is the lack of the right tools to do this.

The source of this misunderstanding is more likely a misalignment of goals. Put simply, it looks like this:

Management wants to increase profits and scale the company. Engineers want to create great software and products.

Ideally, the great software and products will lead to better sales and more profits. Unfortunately, engineers may feel that quality requires time or it may not be possible to achieve with available resources (budgets). The arguments and discussions begin, and another problem arises: how do software engineers demonstrate value to the business? Unlike the sales team, they cannot draw a direct line between their work and profits. Engineers on Reddit also mentioned this issue.

This does not mean that management is at fault. There are two sides to any relationship, and clear communication is required. With that said tech leaders must include engineers in the discussions and pay attention to their concerns. One of which is to understand the development process.

Creating a software product or any other solution can be broken down into four steps: Effort-Output-Outcome-Impact. Let us imagine a financial application for investments.

• Effort. This is the work involved in developing the application.
• Output. The effort produces the application.
• Outcome. Users receive the application and begin changing how they invest.
• Impact. Users like the application, provide positive reviews, and revenue increases from use.

The leaders of the company that produced the application want to increase performance, and now they have a choice of how to measure software developer productivity metrics: the effort, output, outcome, or impact.

It is easier to measure effort and output because these stages offer clear metrics. For example, the lines of code a developer wrote, the number of tickets closed, pull requests completed, and the features produced. Likewise, these metrics also encourage speed, which can hamper efficiency in the long term.

Outcome and impact provide a better opportunity for measuring the value an engineering team brings to a business. An advantage of doing this is that it will create a trickle-down effect: when teams strive to produce impactful products or solutions, they will begin making a more efficient effort and output. Therefore, use these as starting points for creating better OKRs and KPIs for developers.

Here are points to consider when developing OKRs and KPIs for a software department. As with any advice, keep in mind your business's unique details, but do not be afraid to make changes:

1. Take your time: While there may be obvious goals and indicators you want to put in writing, it can be more beneficial to invest time in research, involve stakeholders, and develop ideas that will drive your business forward.
2. Align KPIs and OKRs with business goals: KPIs and OKRs should be directly tied to the broader business objectives. For a software development company, these might include improving customer satisfaction, increasing feature release frequency, or enhancing code quality.
3. Set SMART KPIs and OKRs: KPIs and OKRs should be Specific, Measurable, Achievable, Relevant, and Time-bound. For example, a KPI for reducing bug counts should specify the percentage reduction within a specific period to give the team a clear target.
4. Encourage continuous improvement: Using KPIs and OKRs to regularly assess performance encourages teams to improve. For instance, if code review times are too long, KPIs can track time reduction while OKRs can focus on improving team collaboration.
5. Foster accountability and transparency: Clear KPIs and OKRs make team responsibilities transparent and help foster accountability. Each team or individual understands their role in reaching key milestones, which helps in project management and tracking progress.
6. Promote cross-functional collaboration: In software development, KPIs and OKRs should promote collaboration between developers, testers, and product managers, such as a shared objective to improve user experience.
7. Track progress regularly: Regular tracking of KPIs and OKRs helps detect issues early and adapt as needed. This ensures that the business remains agile and responsive to changes in the software development process or market demands.
8. Differentiate between leading and lagging indicators: KPIs should include both leading indicators (e.g., number of features in development) to predict future success and lagging indicators (e.g., customer churn rate) to assess past performance. This helps in making informed decisions.
9. Use percentages of achievement: Rate a team's work as a percentage to see how well they progressed toward the goals or indicators. 90% may signal that something blocked them from completing their work even though they were on track to finishing.
10. Less is more: Instead of writing many goals and performance indicators, consider taking time to develop fewer, better-quality ideas. This way, your teams will have more opportunities to achieve them.

As we mentioned at the beginning of this article, OKRs and KPIs are different, even though they help a business perform better. OKRs provide a high-level vision, while KPIs focus on the everyday performance of individuals and teams. That is why businesses need to keep them separate and use them for the aims they are designed to achieve. Mixing them up can harm teams and a company's reputation, especially when KPIs become OKRs.

In terms of OKRs, do not use them to measure day-to-day tasks and activities. Likewise, do not create individual OKRs because these are crucial goals for an entire team. Furthermore, OKRs are not good for operational activities (such as emails written or meetings organized).

Since these tools, hopefully, provide clear and achievable goals and indicators, it can be tempting to use them as the foundation of performance reviews. At moments like these, remember Goldhart's law: "When a measure becomes a target, it ceases to become a good measure." There are many factors and metrics to consider when measuring software developer productivity, from DORA to SPACE and others as well.

Part of the challenge of creating effective OKRs and KPIs is understanding what your teams have achieved before and what is realistic in the future. Data is the foundation for understanding these questions, and Enji gives tech leaders clear and understandable information about teams and individuals. Using this data helps management plan with more certainty and stay updated on their teams' work without micromanagement.