I feel like I'm swimming in acronyms these days.
Earlier this year, my team started using Objectives and Key Results (OKRs) for our planning. It's been a learning process. I had some prior experience with OKRs at Google, but I've never felt like I was fully taking advantage of the tool.
I just recently started digging through The 4 Disciplines of Execution (4DX)1 and, surprisingly, OKRs are starting to make a lot more sense. This post outlines some ideas I've picked up through my reading.
Too many goals
For the last few quarters, my team has had 4-5 Objectives.
That's a little high, but it's within the recommended limits.
I usually have some work to do on each of these OKRs every week.
Some weeks I have a hard time prioritizing which objective I should work on.
Do I work on experimentation or search?
¯\_(ツ)_/¯
When we set OKRs, it feels like we're scoping out what work we can get done in the next quarter. That leads to an OKR process that goes something like this:
- List out all the project work we could do, order by importance, and pack the quarter/year until it's full.
- Group our project work into 3-5 major themes.
- Explain why we're doing each class of project (Objectives)
- Develop metrics to describe "success" and set Key Results
It's a useful exercise. We can clearly communicate what we are and aren't working on and why certain projects were deprioritized. I like this process a lot and I think we should keep it, but I don't think it harnesses the true value of OKRs.
Specifically, I think it encourages us to set goals for projects that don't need them. For example, The last two quarters I've set OKRs for giving quick responses to client teams. In reality, I'm already responding quickly. In no world am I going to start ignoring questions because it's not in my OKRs. It's an obvious priority. This OKR isn't a good goal anymore, it's a placeholder for a time commitment.
The Fix
Instead, consider this process: Assume nothing changes in the next quarter. We keep executing on our day-to-day tasks just like we have in the past. We answer questions, fix bugs, improve our tools. All of it.
Now, what one thing could we change to have the biggest marginal impact on the business? That's our new objective.
This is totally different from before. We're not scoping out work for the next quarter. We're identifying the one improvement we're going to protect from the whirlwind of our daily work. That means your single OKR does not need to encompass all of the work you're going to do in a quarter.
In 4DX, they call this objective a Wildly Important Goal (WIG)
The Benefits
Emergencies flare up every now and then; it happens. But, I hate spending a week to put out a fire just to realize I didn't make any progress on my OKRs. I call these Zero Weeks. In my experience, every week is crazy in it's own unique way, but it's usually easy to sneak in an hour of work for a long-term priority. On the other hand, It's not easy to sneak in an hour of work for four long term priorities. Focused objectives cut back on Zero Weeks
The most obvious benefit of focusing our goals is being able to build momentum behind important projects. Sometimes, our projects lose steam near the finish line; The tool becomes "good enough" for day-to-day use or a stakeholder loses interest. Maybe the moment of urgency has passed. In any case, it feels like the project is drifting to completion. If we focus our team on one project, we'll be able to execute faster. This means:
- Share holders are less likely to lose interest
- We'll have fewer Zero Weeks so we'll be able to maintain context
- We'll stay motivated because the problem will be fresh in our minds (Sometimes it's hard to remember why we're even working on a project)
- We'll stay on task and notice drift more quickly (because we'll have more eyes)
Our team has a lot of projects going on at the same time and we're distributed around the world. It's easy to feel disconnected from a teammate if you don't work on the same projects. Working towards the same goal will make us feel more connected - even if someone's only contributing an hour or two that week.
But what about all the other work?
Remember, your single OKR does not need to encompass all of the work you're going to do in a quarter.
In reality, we have dozens of responsibilities we have to execute on every day: code reviews, answering questions, meetings, interviews, actually coding... Setting a single wildly important goal can feel like you're ignoring all of the other important work that needs to get done. I get that, and I'm still a little suspicious of this methodology for that reason.
However, I think I have a work-around for this. We should continue to end our quarters by prioritizing and packing the next quarter's work. That work should be called our "Deliverables" not our OKRs.
We should expect to get our deliverables done every quarter (not 70% done, as recommended for OKRs). I think this is a much more useful and interesting metric for our partner teams. We have teams that depend on our work. I don't want them to have to guess at which 30% of our goals isn't going to get done.
Of course, this isn't great because now we have two rounds of planning and reporting. It sounds like more busy work and more reporting. But, I think it's actually less work that what we're doing now. Compare the two workflows.
Currently we:
- List all possible projects, order by priority, and pack the next quarter
- Group our project work into 3-5 major themes.
- Set objectives for each of these major themes (3-5 objectives)
- Develop metrics and key results for each of these objectives
What I'm suggesting we do:
- List all possible projects, order by priority, and pack the next quarter Call these our "deliverables".
- Step back and identify one wildly important objective we're going to focus on
- Set key results and metrics for that one objective
Instead of setting 3-5 objectives and tens of key results, we're only setting one objective with a few key results. Also, this makes workday deliverables useful. If we're still required to add deliverables every quarter, we may as well get some use from them.
What do you think? Am I missing something?
1 I first heard about this book in Cal Newport's Deep Work which I also recommend.
Thanks to :mreid for his review and comments.