OKRs Examples

/

Engineering

OKRs for Engineering Teams

Product teams are cross-functional groups that blend a mix of product managers, designers, data scientists, copywriters... and developers. So should Engineering OKRs exist if we already have Product OKRs?

Yes. Engineering OKRs focus on the quality of the work, while Product OKRs focus on delivering the right value. It's a bit of a simplified framing, but it highlights the two sides of the coin. In a lot of cases, you'll need great dev work to improve the user experience. But there are also many things specific to Engineering that Product goals will miss.

Focus areas:

Acquisition
Activation
Retention
Referral
Revenue

Key questions:

How efficient is our development process?

How good is the quality of the releases?

Are we producing too much debt?

Is our development team able to do their best work?

How to write OKRs for Engineering teams

Step 1. Understanding OKRs vs. Projects

Before jumping into the OKRs process, 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?

Projects are mentioned here because a common mistake is to list them as Key Results. But a project is a deliverable (output), rather than a goal (outcome).

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 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 right focus. An Engineering team will have several options to pick from:

  • 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.

Don't try to tackle everything though. You'll need to isolate 2 or 3 themes for the quarter, and use them as a starting point for your OKRs.

Step 3. Write your plan

Once you've narrowed your focus, you can start writing your OKRs.

Agree on 2-3 Objectives before diving into the Key Results. You'll see some examples below, and here's a guide about writing OKRs if you're just getting started.

Example of Engineering OKRs

OKRs to reduce technical debt

Objective

Tackle technical debt generated by feature rush

Key result

Reduce percentage of issues tagged as debt by 30%

Key result

Migrate 80% of projects to new UI library to reduce UI debt

Key result

Reduce debt-related contact rate by 50%

More OKR Templates →

OKRs to improve dev speed

Objective

Accelerate development through automation

Key result

100% of repos have a Continuous Delivery pipeline

Key result

Increase code coverage from 30% to 60%

Key result

Reduce build time from 20mins to 5mins

Key result

Reduce cycle time from 8 days to 24h

Key result

All devs have access to a QA library of examples for automated tests

More OKR Templates →

OKRs for better 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 paged issues by 40%

Key result

Improve Crash Free sessions from 75% to 95%

Key result

Reduce core pages load time to be under 3s

More OKR Templates →

OKRs to increase code quality

Objective

Demonstrate incredible standards in code quality

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%

More OKR Templates →

OKRs to deliver great user experience

Objective

Improve significantly the user experience

Key result

Reduce API response time from 900ms to 450ms

Key result

Decrease the number of production exception by 45%

Key result

Improve NPS from 15 to 35

Key result

Accelerate customer onboarding time from 2mins to 25s

More OKR Templates →

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.

It's not just us saying that:

The easier it is for a team to have weekly discussions around the OKRs, the better they'll execute.

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

Tability will act as your accountability buddy

It is vital that you implement a proper OKRs ritual, otherwise your OKRs won't be much different from having KPIs.

What other Engineering metrics can 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:

Cycle time

How long it takes to go from code committed to code released to customers.

Deploy volume

How many deployments are performed every day/week/month.

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.

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

Try Tability for free
Share