By Stephan Schulze
2023 is just around the corner, and some of us might be thinking about our upcoming New Year’s Resolutions. What do we want to achieve, when, and how do we evaluate our efforts productively? How do we drive rather than curb our progress?
These questions remind me of Andy Grove’s Objectives and Key Results framework (or OKRs, as we know them). When you think about it, we all casually set OKRs: No matter what you do, there’s always an objective you would like to achieve and a key result that helps you determine if you did. OKRs help you quantify results in terms of performance, motivating you to accomplish your goals.
While marketing, HR, and business development departments are avid followers of this framework, engineering teams can also benefit from OKRs, because it allows developers to break down their To-dos into actionable and measurable chunks.
We can divide OKRs into two segments:
- The long-term, aspirational objectives of the company as a whole.
- The practical, realistic goals a team can achieve during a specific timeframe to promote the company’s strategic targets.
As the latter is more tangible, it’s sometimes easier to measure departmental Key Results.
Measure what matters
But how do you set and measure the right OKRs for developers?
One approach is tracking the number of released features or processed tickets, which you really shouldn’t do. For one thing, it’s easy to game the system: I can create a bunch of small tickets and constantly push them. I seemingly reached my targets but contributed no value to the company.
A better method is reviewing the outcome. You could say, “we only shipped one feature this quarter (instead of 50), but that single feature moved the needle so much that we accomplished our key results.” And that’s what you need to focus on — which actions improve the company’s overall performance.
The subjective objectives
Talking about OKRs from an engineering perspective, it’s essential to ask how the team can contribute to the overall business-oriented goals.
Let’s say our company wants to provide the most stable, efficient platform. We could define several straightforward, attainable OKRs:
- Measure the average number of bugs in production and set a goal: Reduce it to zero, or allow a maximum of two bugs per month (or any relevant timeframe).
- Focus on increasing deployment efficiency. Deploying and shipping features and bug fixes more often save time. Reducing our deployment time by 10% will thus create value for the company.
- Cut infrastructure costs by analyzing where we currently spend money on our infrastructure stack and find ways to optimize.
Automation is key
As for the second part of the equation, I recommend automating Key Results measurement so data collection and analysis don’t become an extra chore.
We start by defining a KPI (Key Performance Indicator) based on two things:
- Where are we now?
- Which factor do we want to improve?
Let’s say our API delivers an average response time of 150 milliseconds, and we want to reduce it to under 100 milliseconds. We need to analyze the current data, feed the figures to our monitoring or analytics tool, and set up regular checks to measure our progress.
Every change in the data you monitor should be visible without manual action, allowing you to detect a trend.
Report, review, rinse and repeat
Once that’s set, you need regular reports. The team lead, or person responsible for the topic, periodically presents the information (in meetings or all-hands). Awareness is a crucial aspect of OKRs; people sometimes set goals at the beginning of the quarter and never discuss them until it ends.
That’s probably the most problematic approach because you sort of “outsource” your defined objectives. You forget about it until, at one point, you look and see, “Oh, we didn’t meet our goals.”
So, regularly review your progress to ensure people prioritize them. That helps confirm whether the team contributes to the company’s overall OKRs, and leaves time to realign before it’s too late.
Progressive enhancement
Finally, incorporating OKRs into your workflow is the secret to a well-implemented framework. Remember that it takes time to notice improvement and determine if your actions really did contribute to Key Results.
Instead of creating a new procedure that adds another layer of bureaucracy, consider discussing your team’s ongoing progress during the meeting cycle you have in place, like a bi-weekly all-hands meeting.