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?
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.
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.
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.
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.
Tackle technical debt generated by feature rush
Fix the top 10 existing issues
Reduce contact rate by 30%
Reduce future development errors through automation
Increase code coverage from 50% to 75%
Reduce build time from 20mins to 5mins
Reduce cycle time from 8 days to 24h
OKRs won't be of much help if you're not keeping an eye on them. Staying focused and aligned starts by adopting a simple routine with the team.
Start your Monday by looking at outcomes first (OKRs) and then outputs (roadmap). This will make sure that roadmaps discussions are centered around the most pressing issues.
A common mistake for tracking OKRs is to use a table where you replace values in cells with the most recent update.
Not seeing trends can give you a false sense of security. You may be above the target line today, but the overall trend might be going the wrong way. So make sure that you have a simple way to understand if you're getting off track.
A simple progress chart can do wonders to help you understand if you're getting off track.
OKRs will most likely cause friction as you expand their use within your organization:
You can greatly simplify things by adopting a platform like Tability that will automate most of the OKRs tracking and make progress easy to see.
If you’re looking for some inspiration, here are some example of metrics that can be relevant for your Key Results.
How long it takes to go from code committed to code released to customers.
How many deployments are performed every day/week/month.
Number of issues opened divided by the number of issues closed.
Number of incidents
How many incidents happened in production, ideally categorized by severity.
What's the percentage of the code that is tested by automated tests.
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.