.png)
.png)
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:
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
Tackle technical debt generated by feature rush
Reduce percentage of issues tagged as debt by 30%
Migrate 80% of projects to new UI library to reduce UI debt
Reduce debt-related contact rate by 50%
OKRs to improve dev speed
Accelerate development through automation
100% of repos have a Continuous Delivery pipeline
Increase code coverage from 30% to 60%
Reduce build time from 20mins to 5mins
Reduce cycle time from 8 days to 24h
All devs have access to a QA library of examples for automated tests
OKRs for better performance and reliability
Build a world-class infrastructure
Increase Apdex from 0.7 to 0.98
Reduce the number of paged issues by 40%
Improve Crash Free sessions from 75% to 95%
Reduce core pages load time to be under 3s
OKRs to increase code quality
Demonstrate incredible standards in code quality
100% of pull requests are reviewed by 2 developers
75% of the developers have gone through QA training
100% of repositories are using code linting and static code analysis
Reduce the percentage of QA-related broken builds by 60%
OKRs to deliver great user experience
Significantly improve the user experience through better performance
Decrease the number of production exceptions by 45%
Accelerate customer instance cold start time from 2min to 10s
Reduce API response time from 900ms to 450ms
Improve NPS from 15 to 35
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:
- Peter Kappus writes that "check-ins are the most important part of OKRs".
- Felipe Castro cautions people not to let their OKRs turn into New Year's resolutions.
- Christina Wodtke tells us that "cadence is probably the single most important thing".
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.
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.
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.
Got an objective in mind, but not sure how to get there?
Tability's free AI can create a detailed strategy with all the steps to take to reach your goals.
Generate your strategy with AI
.jpg)
.jpg)