OKRs and goal setting #

I’ve had a lot of conversations around OKRs, so I wanted to write down my thoughts around them.

What are OKRs, and how are they defined #

OKRs stand for “objectives” and “key results”.

OKRs were developed by Andy Grove at Intel in the 1970s and later popularized by John Doerr, who learned about them while working at Intel, and then introduced them to Google in 1999. The framework has since been adopted by many technology companies and organizations worldwide.

Objectives are qualitative, inspirational goals that answer the question “What do we want to achieve?” They should be:

  • Clear and specific
  • Time-bound (typically quarterly)
  • Ambitious but achievable

  • Aligned with company strategy #

    Objectives create alignment across teams and drive focus on the most important priorities for the organization.

Key Results are quantitative, measurable outcomes that answer the question “How will we know if we achieved our objective?” They should be:

  • Specific and measurable
  • Time-bound
  • Aggressive but realistic
  • Leading indicators of success

Key results provide a quantitative measure of an objective: if all of the KRs are reached, the objective is considered accomplished.

Hierarchy of OKRs # 

graph TD
    O[Objective: Improve Customer Satisfaction]
    KR[Key Result: Achieve 90% Customer Satisfaction Score]
    P[Project: Implement Customer Feedback System]

    P --> KR --> O

This hierarchy shows how:

  • Objectives (top level) define what you want to achieve
  • Key Results (middle level) measure progress toward objectives
  • Projects (bottom level) are the actual work initiatives that drive key results

Addressing OKR Concerns #

I’ve often heard from many ICs and technical managers that OKRs feel like a pedantic exercise that only serves as busywork, and doesn’t provide real value to the organization, or might constrain the scope of the work unnecessarily. I hope to argue that, with the right process, OKRs can be neither.

OKRs create a common language of communication #

In my experience working with senior leadership teams, the biggest challenge in communication comes from not articulating engineering projects in terms of a measure that leadership can truly appreciate. This requires a mindset shift, especially for engineers who are used to dealing with problems that require deep context to solve and fully appreciate.

Senior leaders often have dozens, if not hundreds of members in their organization. They will likely not have the bandwidth to intimately understand the work you’re doing, although they probably want to. This puts an individual engineer or a team at a risk: if there is a disconnect in context and a common language across the two levels, the engineer may be working on amazing things that go unrecognized, and the leader may miss the opportunity to give critical feedback on the alignment of goals. OKRs serve as that missing common language, helping frame the technical work being done in terms of the impact to the organization and a quantitative way to measure it.

Concern: OKRs are too heavyweight #

When there is feedback that the OKR process is busywork, I think a lot of that comes from a heavyweight OKRs process. Including:

  • A process that forces very stringent requirements and arguing pedantries, like requiring specific phrasing or formatting.
  • A process that stretches weeks at a time, where the next OKR planning begins only a short while after the previous planning was complete.
  • Planning that is too frequent, where a team doesn’t even have a chance to deliver the previous OKRs.

To mitigate those, I suggest:

  • OKR planning no more than once a quarter. Every six months would be a better cadence, if it’s possibly to plan that far ahead.
  • OKR planning process only last 2 weeks: this forces a lot of thinking and collaboration, but leaves 10 weeks or more to focus on execution.

Concern: things change too quickly to write good OKRs #

This is a valid criticism. OKRs are built around long-term planning, and sometimes that isn’t always possible. If a KR is shifting constantly, it may be a sign of, frankly, some organizational dysfunction that any goal setting exercise cannot address.

However, this is also often a symptom of the OKRs themselves: perhaps the OKRs have over-specified and implementation detail, rather than serve as a measure of the achievement of a goal.

Taking improving the performance of a C++ codebase as an example. An overspecified KR may look like:

  • update clangd and achieve a 20% latency reduction in web service latency.

The “update clangd” detail is superfluous and overspecified: the goal is to make things faster, and if you find some better way to do that after a couple weeks of investigation, you should be able to switch the approach whenever to achieve that.

Concerns: the scope of the KRs is too constrained #

Sometimes a KR can feel like it’s constraining you to a specific solution. I have found that this, similar to a KR that goes stale quickly, is often caused by being too tightly coupled to a specific solution.

A solution may change mid-quarter, and the KRs should be authored so that as long as the outcome is achieved, it can be considered complete.

Examples of bad objectives #

  • not framed in terms of a business goal:
    • bad: “oncall rotation”
    • good: “achieve high availability of P0 services”

Examples of bad KRs #

  • overspecified: A KR that includes precise implementation details.
    • bad: “achieve a 20% latency improvement by adding flash attention support”
    • good” “achieve a 20% latency improvement in model training”
  • underspecified: A KR that doesn’t include a specific target.
    • bad: “ship fewer bugs”
    • good: “20% fewer P0 issues discovered in production” or “3 or less P0 incidents in production”
  • unmeasurable: A KR that is not quantifiable.
    • bad: “users are happy with their CI execution”
    • good: “p99 for CI test execution is within 2 minutes”