How to Set Engineering OKRs: Best Practices and Examples

Andrew Grove designed the very first OKRs in the 1970s at Intel. Through Grove’s innovative management methods, the company eventually won the so-called “microprocessor wars” of the 1970s and became the engineering powerhouse it is today. John Doerr, also of Intel, eventually spread the OKR practices across Silicon Valley, where they were quickly proven superior to any other concurrent management framework.

Nowadays, OKRs are used in all industries and are considered one of the best ways to increase team members’ cooperation, engagement, and creativity. And yet each industry has its challenges — as evidenced by our articles on OKRs for Marketing and OKRs for Sales Teams. In this next installment, we’d like to discuss the obstacles, practices, solutions, and everything else you should know when designing OKRs for Engineering.

If you need a reminder on the basics of OKRs, we’ve got a terrific 17-minute video that covers everything you need to know!

How to Set OKRs for Engineers

Software engineering is a very generic term — quite a few professions fall under its umbrella. The average workflow of a product development engineer in a start-up and a security engineer in an S&P 500 enterprise differ significantly; your OKRs should reflect that. However, the general process for formulating your OKRs remains the same.

The first thing you need to consider is your company’s strategic goal. Generally, it is formulated by the C-level executives and will be presented to you. For example, your company is developing a SaaS platform and wants to regularly release new features — thus increasing the number of subscribers by providing them with more and more value.

The second thing you must consider is how your engineering team will assist with this strategy. In our example, you must streamline and optimize the release process — from the planning stage to the final QA pass. So building a slick, reliable, and realistic release pipeline and testing it over the next year would be a perfect OKR for it.

The third thing is your Key Results — the measures by which you can see how close you are to achieving your goal. Returning to our pipeline, we can measure its success by three factors: the number of major feature releases, the number of release deadlines fulfilled, and the number of bugs that have escaped through it.

In the end, you should end up with something like this:

• [O] Establish a new release pipeline
• [KR] Release 3 major feature updates
• [KR] Hit 75% of release deadlines
• [KR] Have less than 60 unique bug reports for each new feature

This is a rather generalized example, made mostly to showcase the system. We will provide more specific ones in a later section. But for now, let’s discuss some of the more unique aspects of Engineering OKRs.

The OKR Integration

Software engineers are an interesting breed in workspace environments — they were among the first to adopt the Kanban system, which eventually gave birth to Jira. Nowadays, almost every software developer uses Jira because it is simply that good. Even those who stubbornly stick with Taiga and other alternatives wish they could switch to Jira anyway.

So when it comes to introducing OKR for software development departments, you have a significant advantage — a task-management system that is familiar and proven to work. All you need is to add OKRs into it, and that’s where OKR Board for Jira comes in!

With OKR Board for Jira by Oboard, you can:

• Link Epics to Objectives and Tasks to Key Results, creating an automatic OKR monitoring system;
• Track binary, decimal, or percentage Key Result values and assign custom weights to priority metrics;
• Separate strategic Yearly OKRs into Quarterly OKRs to ensure alignment;
• Assign OKRs to Departments, Teams, and custom units of your choice;
• Plan your execution across multiple teams and keep up with their progress with OKR Roadmaps;
• Receive real-time, highly detailed reports with shareable OKR Dashboards in Confluence.

And though a dedicated OKR tool brings enormous advanced opportunities, if you don’t have enough resources for it — don’t worry! Check our ultimate guide on managing OKRs in Jira for free.

The Task-Based OKRs

The OKR framework generally frowns on task-based Key Results — each Key Result is supposed to be quantifiable with a metric attached to it, and the metric that goes from 0 to 1 is of questionable use. However, when it comes to engineering, this concept is more what you’d call ‘guidelines.’ Some objectives, especially ones in product teams, require task-based Key Results.

For example, something like this is perfectly viable:

• [O] Prepare a new raid dungeon for World of Lorecraft in April 2023
• [KR] Design and approve the level layout
• [KR] Implement the unique debuffs applied by the boss
• [KR] Playtest the dungeon with a 70% satisfaction rate

The first two Key Results in this list aren’t particularly quantifiable — after all, how could you quantify the completion of a creative process? However, they represent essential milestones toward the completion of the Objective itself. And in this particular case, task-based Key Results are entirely justified.

OKR Board for JIRA allows you to set your Key Results the way you need — we support binary, number (including reverse number), and percentage formats of tracking, with all of them contributing towards the total OKR score.

The Concept of Scope

Scope creep is one of the main enemies of any engineering project. If you need an example — imagine that you are making a simple calculator, but then you decide to add an ability to solve quadratic equations. And then systems, later matrices, and of course, it needs to output function graphs, and, and, and… This is scope creep — and most of the time, it leads to severe complications, delays, and overall loss of focus.

Engineering OKRs — frankly, any OKRs at all — are also subject to it. It is tempting to showcase the entire workflow through your OKRs and have ten Objectives with five Key Results each. By spreading your attention across so many points, you make sure that you cannot focus on the essential ones. Remember — OKRs are not KPIs and are not meant to showcase your routine work but to drive you towards ambitious, audacious achievements.

To avoid the OKR scope creep, we highly recommend the 533 system. Narrow your selection to five Objectives that matter most, and give three Key Results to each. Then take a vote across your team and knock two Objectives out. The remaining three are the ones you should go with.

The Code Conundrum

There is a fairly standard “thought trap” related to OKRs for software engineers. OKRs are supposed to be quantifiable — and your developers are writing code. Therefore, more code = greater achievements. Right?

Wrong. Code is not a quantifiable metric by itself. You can write an algorithm in 10 lines or in 50 — and both would achieve the same result. By forcing your engineers to go with the latter, you are most likely decreasing the quality of your code and making it less optimized. Granted, there are some cases where the extended length of code is preferable — for example, it encourages writing comments — but then you should consider making the comments themselves your priority.

Finally, writing code generally falls under the “routine work” category and should not be considered an OKR unless there is a good reason. For example, having issues with code quality. In which case, your Key Results should account for these metrics instead:

• Reliability. You may also see how reliable your code is by running a static analyzer like Moose, Semgrep, and Sonarqube. Mean Time Between Failures is the industry standard metric for code reliability.
• Complexity. There are multiple possible metrics for complexity: cyclomatic complexity, Halstead metrics, depth of inheritance, class coupling, nesting, etc. Consider which fits your coding style best.
• Build stability status. The number of days since the last build failure (or consecutive days with a failed build) indicates the white box quality assurance.

NOTE: Similarly, the number of tasks completed and the number of issues closed are not a good representation of the developer’s output and generally should not be considered for KPIs or OKRs.

How to Manage OKRs for Engineers

OKRs are a continuous process and require regular check-ins, updates, and management. This is one of the reasons to avoid the scope creep — keeping an eye on 9 Key Results could be quite challenging already, while doing it with 50 would grind the product manager’s workflow to a halt.

To prevent that, here are some general guidelines on how to set up your OKR management process.

Confidence Check-Ins

Weekly or bi-weekly meetings give you an excellent opportunity to monitor Key Results, determine possible issues with them and stay on top of everything happening within your team. You should update your progress toward each Key Result and your confidence level during them.

If you are unfamiliar with the confidence levels — they represent how confident you are that you will achieve at least 70% of the Key Results by the deadline. At Oboard, we use three confidence levels:

• On-track. An objective remains achievable; progress is made steadily.
• Behind. The current pace of progress is not enough to achieve it.
• At Risk. The objective is unachievable even if all efforts are shifted toward it.

Having an Objective in one of the latter stages is generally a good ground for a PPP (Progress, Plans, Problems) report and/or requesting help.

NOTE: If using the SCRUM methodology, you should align your OKR check-ins with your end-of-sprint meetings.

OKR Board for Jira features dashboards with real-time metrics for teams and individuals. They make these weekly meetings much easier to prepare for, since all OKRs are automatically tracked and logged, and the confidence score is calculated based on the objective and relevant data.

Quarterly OKR Meetings

Most OKRs exist in a quarterly scope, and at the end of each quarter, you should have an OKR closure meeting. Here’s an example of its agenda:

• Which OKRs were successful? Discuss what was done right and which practices you might want to adopt. For example, if the OKR was completed due to better cooperation than usual, recall and document your process, and try to use it in the future.
• Which OKRs have failed? Discuss what went wrong and how you could have avoided it. For example, if the OKR failed due to the assignee prioritizing other tasks, you should establish new priorities or adjust their responsibilities for the next quarter.
• Are we still aligned? Discuss whether your team’s objectives this quarter contributed towards the company-level strategic goals. If some of them turned out to be unnecessary — you should review and replace them.

Afterward, you should set the OKRs for the next quarter using the insights from the current results. Keep in mind that it is generally unwise to transfer failed OKRs into the next period — you should at least adjust their scope and review their necessity overall.

OKR Management System

Managing OKRs for a team of 10 is somewhat bothersome but could be done with a liberal application of Google Sheets and some notification system. One of our customers used a combo of Zappier and Twillio, but to be fair, that is a little bit extra.

However, as your team, scope, and engagement with the OKR framework grow, you will spend more and more time doing paperwork. Tracking your Key Results across tasks and metrics, calculating the completion percentages, and determining the exact Objective status takes time, and we haven’t even gotten to reports.

Now, Intel, back in the 1970s, had no choice but to power through these issues — but that was 50 years ago. With OKR Board for Jira by Oboard, you can reduce all the maintenance tenfold — all the routine tasks like monitoring and reporting are automated, leaving you more time to focus on the issues that matter.

Engineering OKR Examples for Product Teams

Engineering is the most turbulent process for software development and arguably the hardest to quantify. We have already talked about how lines of code, tasks completed, and other metrics ultimately mean nothing — instead of measuring work, you should manage its output and outcome. For example:

• [O] Reduce the technical debt generated by the 2022 feature rush
• [KR] Upgrade all 8 third-party libraries to the latest versions
• [KR] Refractor 70% of modules to fit the code style guide
• [KR] Increase Code Coverage back to 75%

***

• [O] Prepare for 2023 Q2 release
• [KR] Fix all 26 outstanding bugs
• [KR] Reduce the crash rate to 0.1% per session
• [KR] Improve communication with QA (submit extensive changelogs for all major builds)

***

• [O] Improve the user experience
• [KR] Conduct a usability study to identify at least 3 major pain points in the product
• [KR] Implement design improvements based on user feedback and increase user satisfaction score by at least 2 points on a 10-point scale
• [KR] Increase user engagement by at least 15% through improved user flows and more intuitive interfaces

Engineering OKR Examples for Outsource Teams

Outsourced software engineering teams aren’t quite as similar to the product teams — for one, their members rarely stay on a single project long enough for the OKRs to become relevant. So instead of focusing on outputs and outcomes, which would differ each quarter and provide no reference point, you should focus on the internal processes and performance. For example:

• [O] Develop a mechanism for rapid onboarding of new developers
• [KR] Create a Quickstart document outlining the stack, style guides, etc.
• [KR] Document at least 75% of software functions with extensive comments
• [KR] Implement a mentorship program and have each senior developer participate

***

• [O] Use all available resources to optimize the development process
• [KR] Create a database of internally-developed libraries and frameworks
• [KR] Design 5 projects using already developed solutions
• [KR] Shorten the development process by 2 weeks on average

***

• [O] Complete the MVP development by May 2023
• [KR] Conduct user research on 100 potential customers to validate product-market fit
• [KR] Build a MVP with at least 80% of planned features
• [KR] Touch down with the customer and get feedback on the MVP

Engineering OKR Examples for QA Teams

QA teams are the natural enemy of the developers — it is their job to pick apart the new products, find faults, and ship them right back into the oven. However, gone are the days when the QA departments were just mind-numbingly checking each possible outcome — a modern tester spends as much time writing their automated tests. And this should be reflected in the OKRs.

• [O] Reduce the number of bugs and defects in the March 2023 update release
• [KR] Implement automated testing for at least 80% of software features and achieve a 95% test coverage rate
• [KR] Reduce the number of unique customer-reported bugs by at least 50%
• [KR] Achieve a defect density rate of fewer than 0.5 defects per 1000 lines of code

***

• [O] Develop and launch a new testing framework
• [KR] Research and compile data on up-to-date testing practices in FAANG and competing companies
• [KR] Test drive the new framework and finetune it until we achieve 50% reduction in testing time
• [KR] Implement it company-wide if the previous testing was deemed successful.

Engineering OKR Examples for Data Science

Data Science is a relatively new form of software engineering, breaching the mainstream only about a decade ago. It would be fair to say that some people still don’t quite understand what the data science engineer does — but these OKRs should be able to explain quickly.

• [O] Improve the accuracy of our predictive models
• [KR] Achieve a 10% increase in the F1 score of our top-performing model.
• [KR] Implement a new data preprocessing pipeline that increases the model’s accuracy by 5%.
• [KR] Reduce the model’s false positive rate by 20%.

***

• [O] Increase the efficiency of our data analysis process
• [KR] Reduce the time to clean and preprocess our data by 30%.
• [KR] Implement a new data visualization dashboard that allows us to identify trends and patterns more quickly.
• [KR] Automate 50% of our data analysis tasks using Python scripts.

***

• [O] Improve the reproducibility of our research
• [KR] Document our code and processes to a high standard, achieving a minimum score of 90 on the PEP8 style guide.
• [KR] Implement version control for our code using Git, with at least one commit per day.
• [KR] Publish at least one research paper in a peer-reviewed journal, with code and data publicly available on GitHub.

Engineering OKR Examples for DevOps and Infrastructure

Generally speaking, DevOps and IT Infrastructure is not the most exciting engineering department — and their OKRs certainly reflect that. Still, they are a crucial part of your engineering structure, and having them motivated and engaged means volumes. Consider these examples when setting DevOps OKRs:

• [O] Redesign the DDOS mitigation algorithms within the next sprint cycle
• [KR] Determine if we can use a DNS based or a proxy-based DDOS solution within a sprint cycle
• [KR] Compare 10 solutions by price and technical requirements
• [KR] Configure and enable DDOS solution

***

• [O] Increase the scalability and reliability of the company’s infrastructure
• [KR] Implement automated scaling and achieve a 99.99% uptime rate
• [KR] Reduce the average response time of the company’s website by at least 50%
• [KR] Reduce infrastructure costs by at least 20% through cloud optimization and infrastructure automation

***

• [O] Migrate the company’s infrastructure to a new cloud provider
• [KR] Develop a plan for the migration, including a timeline and resource allocation
• [KR] Successfully migrate all infrastructure components and ensure that there is no downtime or data loss
• [KR] Achieve a cost savings of at least 25% compared to the previous cloud provider

Engineering OKR Examples for Security Teams

Security is a perpetual arms race between your security engineering team and hostile outside factors. That’s why keeping up with their progress is essential, and you should always stay on top of their results. At this point, giving them OKRs is a no-brainer — and here’s how you can do this:

• [O] Implement software whitelists on employee devices
• [KR] Conduct software surveys across all 6 departments
• [KR] Cross-reference departments’ employees with issued devices
• [KR] Update the whitelists and lock down the user accounts

***

• [O] Revise the rapid response security protocols
• [KR] Increase the strength of the incident response team to 5
• [KR] Reduce the average emergency response time to 5 mins
• [KR] Intercept (dwell time = under 1 minute) 90% of simulated pen tests

***

• [O] Improve the security of the company’s infrastructure
• [KR] Conduct a security audit and identify at least 3 major vulnerabilities in the infrastructure
• [KR] Implement automated security monitoring and achieve compliance with industry standards (e.g. PCI DSS, SOC 2)
• [KR] Reduce the number of security incidents to zero within the quarter

Security engineering teams might benefit from aligning with DevOps — to the point where you might even consider giving the two departments some shared OKRs or making them stakeholders in each other’s objectives.

***

There is no silver bullet for software engineering OKRs — each team is different and faces different challenges depending on their environment and direction. Yet, if you follow our practices and examples, it is possible to quantify their efforts and better understand their challenges.

To improve this process further, use the OKR Board for Jira — a robust all-in-one OKR plugin that streamlines and automates the OKR management process. Turn your Objectives into Epics, link tasks to Key Results, see cross-project progress on the OKR Roadmaps, and create executive reports with a single click. With Oboard, managing software development OKRs is extremely easy, leaving you with more time to spend on development and other essential tasks. Start the free 30-day trial or request a demo right now!