I've seen it time and time again: OKRs (Objectives and Key Results) are touted as the solution to engineering team goal-setting woes, but the truth is they're not a silver bullet. In fact, translating OKRs from business strategy to engineering team goals requires a delicate touch.
A well-crafted engineering OKR has a clear and ambitious objective, like 'Build the most reliable payment processing system in our industry.' This objective is then broken down into 2-4 measurable key results that define what success looks like in concrete terms. For example, 'Error rate below 0.01%', 'P99 latency under 100ms', and 'Zero data loss incidents in the quarter.' Note that these key results are outcome measures, not output measures. They're about achieving the desired outcome, not just completing a set of tasks.
I've worked with teams that have used tools like Google Cloud's Goals and Asana to manage their OKRs, and seen firsthand how these tools can help with tracking progress and identifying areas for improvement. For instance, one team I worked with used these tools to identify that their error rate was higher than expected, and then broke down the problem into smaller, actionable tasks, such as 'Implement retry logic for failed transactions' and 'Optimize database queries to reduce latency.' By doing so, they were able to reduce their error rate by 30% within a quarter.
One of the biggest challenges with OKRs is making technical debt visible to non-engineering stakeholders. When technical debt is described in engineering terms, it can be easy to overlook. But when it's framed in terms of business outcomes, like 'Reduce deployment time from 45 minutes to 10 minutes' or 'Eliminate the 3 most common production incidents by addressing root causes,' it becomes clear how it impacts the bottom line. I've seen teams use frameworks like the Technology Debt Framework to quantify and prioritize technical debt, which helps to ensure that it's addressed in a timely manner.
For example, I've seen a team that was struggling with a monolithic architecture, where every change required a full redeployment of the application. By breaking down the application into smaller microservices, they were able to reduce their deployment time by 75% and improve their overall system reliability. This not only improved the team's productivity but also had a direct impact on the business, as they were able to deploy new features and updates more quickly.
I've seen teams struggle with individual OKRs, which create local optimisation incentives that conflict with team performance. When each engineer has their own OKRs, it can lead to a 'every engineer for themselves' mentality. In contrast, team OKRs that everyone contributes to create a sense of shared ownership and collaboration. Individual performance conversations can happen in 1:1s and performance reviews, separate from OKRs. I've also seen teams use tools like 15Five to facilitate these conversations and ensure that everyone is aligned and working towards the same goals.
Unfortunately, there are some common pitfalls to avoid when implementing OKRs. One is turning them into to-do lists, where output measures like 'complete 20 reliability improvements' are prioritised over outcome measures. Another is sandbagging, where teams set easy OKRs to ensure 100% achievement, rather than pushing themselves to achieve real stretch goals. And finally, there's misalignment, where engineering OKRs aren't connected to the company's overall objectives. The OKR process requires management investment in goal quality and the courage to set goals that represent genuine stretch rather than committed delivery.