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

by John Doerr

Reading, Interpreting, and Acting on OKRs For committed OKRs Teams are expected to rearrange their other priorities to ensure an on-schedule 1.0 delivery. Teams who cannot credibly promise to deliver a 1.0 on a committed OKR must escalate promptly. This is a key point: Escalating in this (common) situation is not only OK, it is required. Whether the issue arose because of disagreement about the OKR, disagreement about its priority, or inability to allocate enough time/people/resources, escalation is good. It allows the team’s management to develop options and resolve conflicts. The corollary is that every new OKR is likely to involve some amount of escalation, since it requires a change to existing priorities and commitments. An OKR that requires no changes to any group’s activities is a business-as-usual OKR, and those are unlikely to be new—although they may not have previously been written down. A committed OKR that fails to achieve a 1.0 by its due date requires a postmortem. This is not intended to punish teams. It is intended to understand what occurred in the planning and/or execution of the OKR, so that teams may improve their ability to reliably hit 1.0 on committed OKRs. Examples of classes of committed OKRs are ensuring that a service meets its SLA (service level agreement) for the quarter; or delivering a defined feature or improvement to an infrastructure system by a set date; or manufacturing and delivering a quantity of servers at a cost point.