OKRs Examples

/

Developers

OKRs for Software Developers

Stop wasting your OKRs. Focus on the right work and accomplish your goals.

Try Tability for free

The Objectives and Key Results framework is a goal-setting methodology that helps teams define a clear set of measurable goals for the quarter. It focuses on outcomes rather than outputs, and it's a great way for software development teams to simplify communications with stakeholders. Instead of discussing how a certain project needs to be delivered, the team and the leadership can focus on why such project is required, and what impact is expected.

When done right, OKRs empower teams to own their roadmap with a clear set of objectives to achieve.

There are also many similarities between best practices in software development and best practices with OKRs. You want to have fast feedback loops and work in small increments to make sure that your efforts are producing the right results.

We'll see in this guide some tips to help you write good OKRs, as well as some specific examples for developers.

How to write Software Development OKRs

Step 1. Knowing the difference between OKRs vs. Projects

The biggest change for developers adopting OKRs is to switch their commitment away from the backlog to focus on the goals defined at the start of the quarter.

To do that, it is essential to understand the difference between Objectives, Key Results, and projects:

  • Objectives: what do we want to achieve next quarter?
  • Key Results: how are we going to measure progress?
  • Projects/Initiatives: what are our best bets to get there?

A common mistake is to start listing all your existing initiatives as Key Results. It's quite tempting as these projects are important, but your OKRs should not be a different representation of your roadmap. 

A good Objective should be inspiring and easy to understand by anyone in your org. You can be more specific in the Key Results, but the Objectives should give a clear idea of the expected impact at the end of the quarter.

A good Key Result should help you measure progress toward your Objective. A good test is to ask, "would we do things differently if this KR goes off-track?". If the answer is negative, then you need to refine your OKR.

Finally, your projects or initiatives are bets that you make to achieve your OKRs. Some will work—double down on it. Some will fail, and it should be okay to stop and move on to the next idea.

Step 2. Pick 2-3 focus areas

The next step is to pick the correct focus for the quarter. Here are some examples that apply to Software Development:

  • Reliability: ensure that the service always works as expected.
  • Usability: improve existing features to make the platform intuitive.
  • Functionality: deliver new capabilities.
  • Security: improve existing protection, and add new safeguards to protect customers.
  • Performance: make sure that your application is responsive and scalable.
  • Dev speed: invest in your development cycle for faster releases.

Once you have your theme in place, you can go further and turn them into inspiring statements for the team. They'll become the starting point of your OKRs.

Step 3. Write your plan

Once you've narrowed your focus, you can start writing your OKRs. You'll see some examples below, and here's a complete guide on OKRs if you're just getting started.

This AI can create OKRs for you 👇
Create tailor-made OKRs with Tability's goal-setting AI.
See the tutorial

Example of OKRs for Software Developers

OKRs to reduce technical debt

Objective

Reduce significantly our legacy technical debt

Key result

Reduce number of issues tagged as debt from 120 to 75

Key result

20% of the sprint effort is dedicated to technical debt

Key result

Application performance improves by 80% as a result of our work on technical debt

OKRs to accelerate release cycles

Objective

Get faster releases through automation

Key result

Increase the number of production deployments from 1/week to 4/week

Key result

Reduce the mean lead time for changes from 8 days to 72h

Key result

Reduce build time from 20mins to 5mins

Key result

100% of our services have a Continuous Delivery pipeline

OKRs to launch a successful mobile application

Objective

Launch a successful mobile app MVP

Key result

Get 100 daily active users on mobile by the end of the quarter

Key result

Mobile application NPS is above 30

Key result

25% of new active users install the mobile app

Key result

Achieve 60% week-4 retention in our mobile application for active users

OKRs for better software performance and reliability

Objective

Build a world-class infrastructure

Key result

Increase Apdex from 0.7 to 0.98

Key result

Reduce the number of paging escalations by 40%

Key result

Improve Crash Free sessions from 75% to 95%

Key result

Reduce core pages load time to be under 2s

OKRs to increase code quality

Objective

Improve our code quality standards

Key result

100% of pull requests are reviewed by 2 developers

Key result

75% of the developers have gone through QA training

Key result

100% of repositories are using code linting and static code analysis

Key result

Reduce the percentage of QA-related broken builds by 60%

OKRs to attain great security standards

Objective

Attain great security standards

Key result

100% of our services have a threat mitigation system in place

Key result

100% of devices are enrolled in a Mobile Device Management

Key result

All developers score 90+ in our security awareness training

Key result

Our policies cover 100% of the ISO 27001 requirements

OKRs to migrate to a new technology

Objective

Our JS codebase has migrated to TypeScript

Key result

75% of our JS repositories are now using TypeScript

Key result

Reduce the use of "any" type by 30%

Key result

80% of frontend developers have gone through TypeScript training

Discovering more Software Development OKRs

There are a couple of ways for you to get more examples of OKRs that would be a great fit for Dev teams:

Tracking your OKRs

Knowing how to write good OKRs is critical, but without good tracking in place, the OKRs will fade away and focus will be lost.

The easier it is for a team to have weekly discussions around the OKRs, the better they'll execute. Here are a few best practices for tracking OKRs.

OKRs-tracking with Tability

1. Do weekly check-ins

Quarterly OKRs should be tracked every week to be effective. Without a continuous reflection on progress, your OKRs won't be much different from having KPIs.

The check-ins process can be automated with a platform like Tability that takes care of reminders, and distribute updates to the teams.

2. Keep track of your confidence

Good progress updates should help everyone understand how far we are from our goal, but also how confident we are in achieving it. You can use a simple red/yellow/green color coding to indicate your confidence.

3. Make trends easy to see

Lastly, it's important to look at trends to avoid false positives. It's not rare for a team to have a hot start and then slow down mid quarter. This will be hard to see unless you can look at progress trends for individual Key Results.

Track your OKRs like a pro
Join companies like Autodesk, ClimatePartner, Freelancer to simplify goal-tracking and see true progress on OKRs with Tability.
See the tutorial

What other metrics can Developers you use?

Now that you've got good Objectives, it's time to pick some key results and finding good metrics that work for your team can be tricky. Lucky for you, we've laid out all the best success metrics for your teams to use.

Here are a few to get you started:

Deployment frequency

How often an organization successfully releases to production

Mean lead time for changes

How long it takes a commit to get into production.

Mean time to recover

How long it takes an organization to recover from a failure in production.

Change failure rate

The percentage of deployments causing a failure in production

Availability

How much of the day/week/month an app stays up & running without interruption.

Open/closed rate

Number of issues opened divided by the number of issues closed.

Number of incidents

How many incidents happened in production, ideally categorized by severity.

Code coverage

What's the percentage of the code that is tested by automated tests.

Build time

How long it takes to complete a build on average. Indicates how long it takes for a developer to know if their changes broke the application.

Review to merge time (RTMT)

How long it takes for a code review to be completed and merged.

Table of contents