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?

Example of Engineering OKRs

You'll find below an example built around a fictitious company. Your OKRs should move from quarter to quarter and map to your company's reality – that's why we thought it's best to illustrate things as a case study that you can take inspiration from.

Scenario

Askawoof is a startup building a platform to help companies run customer satisfaction surveys. They have been under pressure to release a lot of features quickly, and the quality of the work has suffered as a result. The Engineering team has decided to focus on quality with their next set of OKRs.

General advice

Don't start with the metrics. It's far more important to have a shared understanding of the Objectives, rather than nitpicking what the percentage of improvement should be.

Some Engineering metrics might be hard to understand for outsiders, which is why your Objectives need to be easy to grasp. It'll help others make sure that they're aligning properly with the rest of the organization.

Their Engineering OKRs

Objective

Tackle technical debt generated by feature rush

Key result

Fix the top 10 existing issues

Key result

Reduce contact rate by 30%

More OKR Templates →

Objective

Reduce future development errors through automation

Key result

Increase code coverage from 50% to 75%

Key result

Reduce build time from 20mins to 5mins

Key result

Reduce cycle time from 8 days to 24h

More OKR Templates →

How to track your Engineering OKRs?

There are many options available out there but we're generally seeing 2 categories of products emerging.

For teams getting started: Spreadsheets

Spreadsheets are a great way to get started with OKRs. They're flexible and familiar, and they reduce the amount of learning when you're still getting comfortable with the Objectives and Key Results process.

But, you'll probably start to feel some friction as adoption grows. The lack of check-ins workflows and trends makes it hard for spreadsheet to be a long-term solution for OKRs.

For seasoned OKRs team: OKRs-tracking software

If you're looking to simplify your OKRs process, then a dedicated goal-tracking platform is best to keep track of your OKRs at scale.

A platform like Tability will automate the check-ins reminders, provide progress charts and dashboards out of the box, and make the whole experience more collaborative.

Focus tip:

Frequent check-ins are the key to staying on track with your OKRs. Checking progress early and often will tell you what you should and shouldn't focus on. Make check-ins a part of your weekly ritual with Tability →

What other Engineering metrics can you use?

If you’re looking for some inspiration, here are some example of metrics that can be relevant for your Key Results.

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