Most of the companies I’ve worked for in the last 5 years have used the OKR system. Although this system was invented in the 70s, it has more recently become popular at Google and has spread through the tech world.
It’s a simple system where the company defines a number of Objectives, and each objective has one or more measurable Key Results. Those KRs are intended to track progress on that objective over time.
For example.
- Objective – Increase Customer Retention
- Key Result #1 – Lifetime Customer value increase from $N to $N+5
- Key Result #2 – Decrease Customer Churn Rate by 10%
Most companies I’ve been at usually have 3-5 OKRs active at any given time.
What OKRs are supposed to do for a company
The idea is basically that everyone has some very clear, direct and measurable goals to align behind. Everything a team does should align to a specific OKR. In theory, that means everyone is rowing in the same direction(s).
It works great at certain levels and in certain ways. For the leadership team, it typically seems to be an excellent mechanism. It can put all the leaders on the same page(s) and provide a great starting point for the quarter.
It can put all the leaders on the same page(s) and provide a great starting point for the quarter.
When it comes time for a dev team make decisions…
Where OKRs become less useful is within the decision making process for an individual team.
Where OKRs become less useful is within the decision making process for an individual team.
Joe Cannatti
The most common pattern I’ve seen goes like this
- The team comes in with a backlog of things that they want to work on.
- They discuss each item and work out a basic list ordered by priority. The cut out things they know they aren’t going to get to any time soon.
- They go over the list and add a label to each task/project to specify the OKR to which it is most closely related.
- For the most part, it’s usually works out to be possible to assign an OKR to anything without too much mental gymnastics
Wait a minute… Isn’t that backwards?
Shouldn’t we be using the OKRs to drive coming up with ideas in the first place instead of just wedging them in afterwards?
Yeah, I think that’s the idea.
Backlog
It usually seems to me that the reason it works out this way is because teams generally have large backlogs of things they’ve decided they’d like to do. Most of the stuff in that backlog was written down long before the current OKRs where specified.
So it makes sense that when the OKRs come out for the quarter, we just take what we already have and figure out how to fit it into the OKRs.
Is there anything wrong with that?
Yes and no.
The biggest problem seems to me to be that the team doesn’t end up feeling truly connected or committed to the OKRs. For example, as I write this, I can tell you every project we are going to attempt to work on this quarter, but I can’t even tell you what the OKRs for the quarter are.
We did make them all fit in with OKRs, but it never felt like it was really what was driving us. Maybe that’s okay, but it doesn’t seem super useful to me. I think it gives leadership the justification they need to declare that everyone is working towards the same goals, but I don’t think it leads to dev teams actually feeling like that’s true.
I think it gives leadership the justification they need to declare that everyone is working towards the same goals, but I don’t think it leads to dev teams actually feeling like that’s true.
Ideas to improve how this all works
I have a couple ideas about how you can make this better for the next planning cycle for your team.
Backlog Bankruptcy
When you start the planning for your next cycle, consider abandoning your current backlog. Instead of diving into the things your team has already defined as work that should be done, start totally from scratch.
Drive downward from the OKRs and see if the team can come with ideas that have not already been thought of. Or if they can reframe their existing ideas in meaningful ways to make them truly feel like an extension of the OKRs.
This isn’t easy to do. You will need to continually push people away from stuff that’s already in the backlog, but I think it can lead to better results in the end.
Use OKRs to drive weekly team meetings
Use the OKRs as the starting point for your weekly sprint plannings and other checkin meetings.
Generally, these meetings will naturally follow a pattern of being shaped by the projects and tasks people are working on, but it’s possible to keep pushing the flow of the conversation back to the OKRs.
What effect would this have on your team?
I’d love to hear how you think this could workout on your team. What do you expect would be different if you adopted these techniques? Comment below or reach me at joe@zafulabs.com
Top comments (7)
I don't have much experience with OKRs, but I'd be curious how to handle technical debt / refactoring tasks?
Often times I think management wouldn't care for this, but let's imagine a scenario in which they do.
How would one integrate this? Does anyone know a way to measure technical debt?
Tracking tech debt and other work that is driven by engineering is sometimes handled as a separate channel of work. For example, I've seen places where 70% of work went towards business goals and 30% towards tech debt and engineering goals. All that business really needed to know was that 30% of effort was going towards future tech stability.
Hm... Seems like a hack to me.
Shouldn't the reduction of technical dept and "future tech stability" be a business goal as well? This agreement seems to be for ease and removes some potentially valuable communication, I'd think.
Let's imagine a scenario in which the engineers want to do some big refactor, to be able to do future tasks easier, faster, more secure (add some more things if you want). Ideally, this wouldn't have to be done in 30% of the work-time but get more attention. Of course I'm not saying it should occupy 100% of efforts, but maybe raising it to 50% or 70% (depending on the refactor) might be good. And if there's fitting OKR, it would be really hard to argue for this, although it might actually be the right move to do. What do you think?
I dig it in principal and I have seen it work fine that way when companies are smaller. That approach seems to stop working as companies get bigger though. It typically gets very difficult to make the case heads up between direct business features and tech improvements. The 30% thing is sort of like a correcting function. To push things back into balance as the company grows.
While I totally agree that it's highly unlikely it'll work in a bigger company, that still means it's a workaround. I'd like to know a way to incorporate technical debt and refactoring into OKR principals (with the assumption that all parties involved understand the importance). Of course we can find workarounds like the 70-30-rule (which actually sounds reasonable, I think), but I still think there's value in trying to find a way of adapting it into OKRs in an ideal scenario, as to learn from it and maybe actually implement it at least in some way somewhere.
I personally have trouble finding a metric to measure technical debt by, so I'm curious whether anyone knows of a good one to use...?
I encounter this same problem. My teams do OKRs but they always end up using it as a way to confirm what they wanted to work on. In fact if something they wanted to work on is not reflected in the OKR, they modify the list of OKRs.
I like your suggestion. I’ll add one more, if management incentivized achieving business goals instead of project metrics (eg velocity, on-time delivery), then I think OKRs would be much more meaningful.
I am in love with the idea of just dumping the backlog (or at least shelving it) when it’s time for new OKRs. In my experience an existing backlog often serves to muddle the narrative that the team is trying to form. Or worse, the backlog items often just end up languishing forever.