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 pri- orities 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.
— The set of aspirational OKRs will by design exceed the team’s ability to execute in a given quarter. The OKRs’ priority should inform team members’ decisions on where to spend the remaining time they have after the group’s commitments are met. In general, higher priority OKRs should be completed before lower priority OKRs.
— Aspirational OKRs and their associated priorities should remain on a team’s OKR list until they are completed, carrying them forward from quarter to quarter as necessary. Dropping them from the OKR list because of lack of progress is a mistake, as it disguises persistent problems of prioritization, resource availability, or a lack of understanding of the problem/solution.
Corollary: It is good to move an aspirational OKR to a different team’s list if that team has both the expertise and bandwidth
to accomplish the OKR more effectively than the current OKR owner.
— Team managers are expected to assess the resources required to accomplish their aspirational OKRs and ask for them each quarter, fulfilling their duty to express known demand to the business. Managers should not expect to receive all the required resources, however, unless their aspirational OKRs are the highest priority goals in the company after the committed OKRs.
More Litmus Tests
Some simple tests to see if your OKRs are good:
— If you wrote them down in five minutes, they probably
aren’t good. Think.
— If your objective doesn’t fit on one line, it probably isn’t
— If your KRs are expressed in team-internal terms (“Launch
Foo 4.1”), they probably aren’t good. What matters isn’t the launch, but its impact. Why is Foo 4.1 important? Better: “Launch Foo 4.1 to improve sign-ups by 25 percent.” Or simply: “Improve sign- ups by 25 percent.”
— Use real dates. If every key result happens on the last day of the quarter, you likely don’t have a real plan.
— Make sure your key results are measurable: It must be possible to objectively assign a grade at the end of the quarter. “Improve sign-ups” isn’t a good key result. Better: “Improve daily sign-ups by 25 percent by May 1.”
— Make sure the metrics are unambiguous. If you say “1 million users,” is that all-time users or seven-day actives?
— If there are important activities on your team (or a significant fraction of its effort) that aren’t covered by OKRs, add more.
— For larger groups, make OKRs hierarchical—have high- level ones for the entire team, more detailed ones for subteams. Make sure that the “horizontal” OKRs (projects that need multiple teams to contribute) have supporting key results in each subteam.