Guidelines for goals

Our company goals are public:

Principles

We believe:

  • “Plans are useless, but planning is essential.”
  • “No plan survives first contact with the customer.”
  • “A plan is only useful for determining the immediate next thing to do. Beyond that, you must be ready to abandon the plan in the face of new evidence.”
  • Discarding a goal that turns out to be wrong is better than following through on the wrong goal. People know this intellectually but disregard it in practice.
  • Each problem we’re solving has a different (and often unknown/unknowable) timeline and rate of progress.
  • Only people with skin in the game can set useful goals.
  • A goal is good if people think about it regularly and it helps them make decisions.
  • Goals are communication tools. A goal that people don’t understand is a bad goal.

How we set goals

  • For annual planning, instead of OKRs (which imply an unrealistic level of certainty for the next year), we will set a small number of goals with a clear primary one and a written 1–3–5-year vision.
  • We set company-wide OKRs for each quarter.
  • Also, each team sets its own OKRs for each quarter.
  • Quarterly OKRs are set just before the quarter starts. (We don’t try to set them too far in advance.)
  • At the end of each quarter (and whenever needed), we review the the annual plan to assess our progress and change it if parts are no longer relevant or realistic.

What are OKRs?

OKRs (Objectives and Key Results) are a way of defining goals.

There’s no formal specification of OKRs. Every company does it slightly differently. We can learn from how other companies do OKRs, or how experts recommend to do OKRs. There is no universally correct or incorrect way to do OKRs, only effective and ineffective ways, so think from first principles and this page’s guidelines.

A goal in OKR form looks like:

  • Objective
    • Key result 1
    • Key result 2
    • Key result 3

To make OKRs across the company easy to understand, we have a few rules:

  • Objectives need to be concise and memorable. It’s like a title, not a definition.
    • If an objective is precise, it’s probably too long. Put the precision in the key results.
  • Each objective can have 1–5 key results.
    • A key result is how you know if you’ve achieved the objective.
    • Avoid tasks as key results (such as Implement performance review process). Find a measurable business outcome instead, or frame the result in terms of acceptance or participation (All team members participate in the performance review process).

See the most recent OKRs doc for good, relevant examples.

Writing good OKRs

  1. Each OKR has a single person (not multiple people) who’s ultimately responsible for it.
    • Many people can be working toward a goal, but there must be one person who’s ultimately responsible.
    • It’s OK for a team to own a goal. That means the manager is ultimately responsible for it. A team should not have more than 1 or 2 goals (to make sure it’s not becoming a workgroup with too many disparate goals).
  2. Pick goals where failure would be painful.
  3. Pick goals where you can influence the outcome. Avoid using a lagging indicator as a goal.
  4. Set key results to be ambitious but achievable, so that they convey your aims and what you could achieve if things go well.
    • Achieving 90–100% is on track. 75–90% is falling behind. Less than 75% is at risk or missing.
    • Goals are not the 99.99% likelihood outcome or the 1% moonshot outcome.
  5. Goals are for communication and alignment (everyone knowing what’s important, why, and how it’ll get done), not for estimation, scheduling, or promising/committing.
    • Setting a goal for X is not the same as committing to shipping X to customers. We are much more conservative in setting expectations with customers about firm ship dates than we are in setting goals.
    • Write your goals so they communicate effectively to an audience who understands that goals aren’t promises. Don’t write goals so cautiously that they are hard to understand. (For example, “Improve code intelligence support for Java” is a good goal, especially with well defined outcomes. But “Investigate feasibility of improvements to Java code intelligence” is probably bad.)
  6. If a key result can be reduced to a single quantitative metric, that’s great. But don’t try to force it. It’s OK to rely on human judgment for a key result.

History/journey of goal-setting

We’ve tried a few ways of setting goals at Sourcegraph as we grew. We used quarterly OKRs from late 2019 through mid-2020, when we switched to using more casual and non-quarterly goals. Throughout this period, we always had a couple of company-wide and annual goals that were on top of OKRs.

You’re probably hoping to read some deep insight about why certain goal-setting schemes worked or didn’t work. I (@sqs) think the lessons we’ve learned are about goal-setting overall, and not any particular scheme. We need to have a clear process and agreed-upon timeline for setting goals company-wide. We need to have clear ownership for goals. We need to communicate higher-level objectives, not just task lists.

Why are we using “OKRs” again, when we previously said OKRs were jargon? Because I (@sqs) have actually found using the terms “objective” and “key result” helpful in getting people to write down their goals more concisely and without listing tasks.

Sensitive information

Do not include any specific financial numbers, customer names, or any other sensitive information in the public goals. Instead, use placeholders (such as N0, N1, and so on) and link to the definitions in a Google Doc that is only visible to Sourcegraph team members.