Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs

by John Doerr

My first PowerPoint slide defined OKRs: “A management methodology that helps to ensure that the company focuses efforts on the same important issues throughout the organization.” An OBJECTIVE, I explained, is simply WHAT is to be achieved, no more and no less. By definition, objectives are significant, concrete, action oriented, and (ideally) inspirational. When properly designed and deployed, they’re a vaccine against fuzzy thinking—and fuzzy execution. KEY RESULTS benchmark and monitor HOW we get to the objective. Effective KRs are specific and time-bound, aggressive yet realistic. Most of all, they are measurable and verifiable. (As prize pupil Marissa Mayer would say, “It’s not a key result unless it has a number.”) You either meet a key result’s requirements or you don’t; there is no gray area, no room for doubt. At the end of the designated period, typically a quarter, we declare the key result fulfilled or not.

Once they are all completed, the objective is necessarily achieved. (And if it isn’t, the OKR was poorly designed in the first place.)

He sought to “create an environment that values and emphasizes output” and to avoid what Drucker termed the “activity trap”: “[S]tressing output is the key to increasing productivity, while looking to increase activity can result in just the opposite.”

[T]heir paired counterparts should stress the quality of [the] work. Thus, in accounts payable, the number of vouchers processed should be paired with the number of errors found either by auditing or by our suppliers.

unacknowledged dependencies remain the number one cause of project slippage. The cure is lateral, cross-functional connectivity, peer-to-peer and team-to-team.

The engineers weren’t aligned with the product managers’ objectives. They had their own infrastructure OKRs, to keep the plumbing going and the lights on. We assumed they could do it all—a big mistake. They got confused about what they should be working on, which could change without notice. (Sometimes it boiled down to which product manager yelled loudest.) As the engineers switched between projects from week to week, their efficiency dragged.

Early on, I found it challenging to separate my individual goals from the department’s OKRs. As IT’s leader, I thought they should logically coincide. But it wasn’t a good optic. Most of our top-level objectives endured from quarter to quarter, typically for eighteen months. Down the line, teams and individuals would modify their own OKRs as the environment shifted and we kept making progress. And they were asking, quite reasonably, “What is the CIO doing if his goals never change?” I got the message. Now I have my own objectives, and I ladder up to our top-level OKRs like everyone else. Beyond our base in the Bay Area, we made it a point to implement

That was our biggest advantage: We aimed higher.

Engineers struggle with goal setting in two big ways. They hate crossing off anything they think is a good idea, and they habitually underestimate how long it takes to get things done. I’d lived through this at Product Search, where they’d insist: “Come on, I’m a smart person. I can surely get more done than that.” It took discipline for people to narrow their lists to three or four objectives for their team, but it made a huge difference.

We have a best-idea-wins culture, and people are free to call out anybody, including the CEO. Alex: Especially the CEO, that’s the best call-out there is. When people challenge us in an open forum, we always stop and make a huge big deal about how impressive it is that the person spoke up. We try to overdo it, to create permission for people to lean in.

Structure and clarity: Are goals, roles, and execution plans on our team clear? Psychological safety: Can we take risks on this team without

feeling insecure or embarrassed? Meaning of work: Are we working on something that is personally important for each of us? Dependability: Can we count on each other to do high-quality work on time? Impact of work: Do we fundamentally believe that the work we’re doing matters?