(Each week, I write a post about OKRs. You can see the series of posts here; if you have a question about OKRs you’d like to see me cover down the road, drop me a line.)
Readers Jeff and Balaji asked related questions a few weeks ago. In essence, they wanted to know how I felt about the importance of quarterly goals – especially when some efforts span multiple quarters. In Jeff’s case, he was responding to my post about binary OKRs; in Balaji’s, he asked about products that may take a year to develop:
if a product that we believe will drive a key metric up, takes a year to develop and launch, how would you write the quarterly OKRs instead of writing it just in terms of making progress?
In both cases, they’re getting at one of the inherent challenges in OKRs: how do you draft a goal that focuses the team’s effort, pushes for ambitious outcomes – even if the 90 day timeline may not be sufficient? I have two thoughts:
- teams often accept more constraints into their planning than they should. What seems like it may take longer (multiple quarters) is often a byproduct of a team accepting external constraints (resources, obligations, dependencies). It’s leadership’s job to push the team to explore creative solutions to get to the outcome faster, more creatively.
- sometimes the quarterly timeframe is entirely arbitrary, and ultimately unhelpful. If it produces unnatural results – manufactured metrics, arbitrary interim deliverables – then the team should avoid imposing structure where it fails to achieve the desired result. (Just make sure everyone involved understands the trade-offs, and is aligned on the agreed-upon alternative.)
In the first point, I think back on my time as a product manager at YouTube. I was responsible for running the YouTube homepage, at the time the third most-trafficked page on the Internet. I was also responsible for YouTube accounts (how users logged into YouTube – to access their channel, recommendations, playlists, etc.) – users had the option of logging in with their YouTube account (which predated the Google acquisition) or their Google Account. It was confusing to users, and it was a technical mess on the back-end – especially when users had both a YouTube account and a Google account that shared the same Gmail address. Eliminating the confusion and standardizing on one way to log into YouTube was a key goal – indeed, it became a YouTube-level OKR that Larry Page elevated to a Google-wide company-level OKR.
The entire story is told in John Doerr’s Measure What Matters book, if you’re interested (pages 48-49). I’m sharing it here to note that we (my engineering team and I) had done the legwork ahead of setting our quarterly OKRs, and we knew that it would take six months to deliver the finished result. Larry listened to our plans, agreed with the outcome (eliminating YouTube logins, standardizing on the Google Account for all authentication), and had just one edit: we had three months, not six. (Yay?)
In that case, we weren’t really wrong: doing it right, tying up all loose ends, etc. would have taken the full six months. But Larry looked at the outcome and knew that delivering it more quickly would be enormously important to a number of other initiatives (both at YouTube and Google). He was comfortable accepting trade-offs (technical debt, or other, less important deliverables getting deprioritized to accelerate our work) – and by elevating our work to a company-level OKR, he communicated to the rest of the company just how important this was. In this case, the ambition baked into the OKR was the forcing function to get the team to reevaluate the constraints we believed we had – and allowed us to deliver on time a full three months sooner than we would have originally delivered. (OK, technically we delivered one week into the following quarter. Thanks to John Doerr for memorializing that OKR miss for posterity in a NY Times bestseller!)
On the second point: one of my favorite posts on this subject is from Hunter Walk from 2013: Manager OKRs, Maker OKRs: How I’d Change Google’s Goal Setting Process:
“Quarterly goals?” Why are three months the right duration for building features, why not two months or four months? And there was the amusing “last week of quarter” push to try and ship all the features you’d committed to ~90 days earlier.
I won’t quote the entire post – it’s well worth your time if you’re interested in this topic. High level, Hunter proposes three buckets for goals:
- One Month – “What are we building this month” is the key question.
- “N+12 Months” – “What will our product and business look like a year from now?”
- Minimal Quarterly/Annual KPIs
I haven’t worked with an approach like the one Hunter lays out – as he notes, we didn’t use this approach when I worked for him at YouTube. And for many of the companies / organizations I’ve worked with, the quarterly cadence seems to work well. But the premise of his suggestion is to fit the timeframe to the organization’s needs – rather than the other way around. Which I think does a good job of addressing the theme behind Jeff and Balaji’s questions: if the 90 day calendar is inhibiting the team’s execution, you shouldn’t let the OKR framework be so rigid that it forces unnatural commitments. Approach it like an OKR exercise: start with the end in mind (what outcome are we trying to achieve?) and let that guide you to the best tactic (timeframe, cadence, etc.).
Back to Jeff and Balaji’s questions that started this post:
Jeff observed:
When a team is really pushing hard to get V1 out the door in the quarter it can be both helpful to make that a company level OKR to drive focus and re-enforce the importance of the project BUT hard to really have the right metrics. Often the metrics end up being silly versions of binary (eg first 10 users – where 1 user isn’t really a .1 and 20 isn’t really a 2) or aren’t really on point to the true objective. (emphasis mine)
In that case, I’d focus on what Jeff calls the true objective. If the objective is crafted well enough to give everyone a sense of what the goal is (we’re launching the product to achieve [X], we won’t know if we got there until after we’ve launched the product, so our goal for this quarter is to launch [X]), that’s not terrible. (Indeed, my YouTube example above illustrates this pretty well. We had some key results around increasing the logged-in percentage of sessions on youtube.com, but we wouldn’t know whether we got there until we’d had a chance to observe the impact of that launch months later. Ultimately we scored ourselves on our launch, not the post-launch effects.) The mistake teams often make is to understand that the launch is in service of some other goal, but they never go back and ask whether the launch actually produced the desired outcome. They just take the win for getting the launch done and move on. Bottom line? If the launch itself is sufficiently clarifying for the team about what needs to happen, and why, go with it. But make sure everyone revisits the post-launch environment to confirm that the outcomes track with what you wanted.
Balaji was asking a similar question, albeit with the implication of milestones needed to get incrementally closer to a launch that’s potentially several quarters away. Given the comments above, I think the same approach holds true: use OKRs to keep the team aligned on the direction; Hunter’s “one month / N+12 months” framing is potentially useful here. Look for interim calibration opportunities that can help validate the assumptions baked into the timetable so you know you’re on the right track (or can course-correct), and ensure that the org has a shared understanding of what success looks like (i.e., post-launch impact) so that you can determine whether you achieved what you set out to achieve. It’s ultimately less important that that calibration happens as part of a quarterly OKR grading exercise – it’s more important that accountability becomes part of the organization’s DNA.
Is your org working with a goal setting calendar that’s not quarterly? I’d love to hear about the experience in the comments.