OKRs from a development team’s perspective

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.

The most common pattern I’ve seen goes like this

1. The team comes in with a backlog of things that they want to work on.
2. 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.
3. They go over the list and add a label to each task/project to specify the OKR to which it is most closely related.
4. 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 [email protected]