Objectives and Key Results (OKRs)
Our OKRs are public:
What are OKRs?
Objectives and Key Results (OKRs) is a specific way of setting goals that we use at Sourcegraph.
- For each goal (called an OKR), you state an objective (what you’re aiming to do) and key results (how success of the objective is measured).
- OKRs form a tree structure. We have a few broad company-level OKRs. Each company-level OKR has many sub-OKRs, for teams whose work contributes up to the company-level OKR. This codifies why/how each team’s work is important to the company.
Our OKR practices are heavily inspired by GitLab’s OKR practices.
OKRs are stretch goals
- Set OKRs to be ambitious but achievable, so that they convey your aims and what you could achieve if things go well.
- In (rough) numeric terms, if you achieve less than 70% of your KR, it was probably not achievable. If you regularly achieve 100%+ of your KRs, they are probably not ambitious enough.
- Your KRs are not the 99.99% likelihood outcome or the 1% moonshot outcome.
- OKRs 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 an OKR for X is not the same as committing to shipping X to customers. We are much more conservative in setting expectations with customers about ship dates than we are in setting OKRs, and it wouldn’t make sense to be locked into a ship date that we decided at the beginning of the quarter when setting OKRs.
- OKRs are not used directly for giving individual performance review feedback or for compensation purposes.
- Write your OKRs so they communicate effectively to an audience who understands that OKRs aren’t promises. Don’t write OKRs so cautiously that they are hard to understand. (For example, “Improve code intelligence support for Java” is a good objective, especially with well defined key results. But “Investigate feasibility of improvements to Java code intelligence” is probably bad.)
- For new projects, it can be hard to define the right OKRs. Do your best. Then refine them next quarter.
We set OKRs for each quarter. The (rough) schedule for setting OKRs for an upcoming quarter is:
- -3 weeks: CEO creates the upcoming quarter’s OKR document with company-level goals (as a Google Doc for easy collaboration) and links it from this page.
- -2 weeks: Each team adds proposed OKRs to the doc and solicits feedback from relevant stakeholders.
- -1 week: OKRs have been approved by the owners of the OKRs in the levels above them.
- 0 (start of quarter)
- +1 week: Review previous quarter’s OKRs in 1-1s.
This is based on the GitLab OKR format (as of 2019).
OKRs have the following format:
1. **Title or team: Objective as 1 sentence.** KR: Key result. => Outcome. KR: Key result. => Outcome. KR: Key result. => Outcome. 1. **Title or team: Objective as 1 sentence.** KR: Key result. => Outcome. KR: Key result. => Outcome. KR: Key result. => Outcome.
Title or teamis the title (e.g.,
VP Engineering) of the person who is directly responsible or the name of the team responsible.
- The bold
Objective as 1 sentence.is a pithy, informal summary of the objective, not an exhaustive and precise definition or description of the implementation. For example:
Automate time-consuming ops and support tasks.
Write scripts for headless browser testing of release grid items and update sourcegraph/sourcegraph and sourcegraph/deploy-sourcegraph CI pipelines to execute these scripts.
KR: Key result.is a list of 1-3 key results that are measurable. The objective and key results should be statable in a sentence of the form, “I will <objective> as measured by <key results>.”
- Quantitative key results are ideal, but if they aren’t appropriate for the objective, don’t try to force it. Instead, choose a key result that is clear in its reliance on someone’s judgment.
- If a key result has a complex definition (more than a few words), link to a handbook page with the precise definition instead of inlining it in the OKR list.
- Key results can be links to issues or RFCs.
- Good (quantitative):
100% of monthly releases ship on time
- Good (human judgment):
Create an effective pitch for Fortune 500 prospectsbecause “effective” is not defined and different people are likely to have a wide variety of opinions about what it means
- Good (quantitative):
- Objectives form a tree structure, rolling up to top-level CEO OKRs for the entire company. KRs should not partake in the tree structure. For example, do not make an objective a child of another role’s key result.
=> Outcome.part is only added/updated after the quarter starts.
Do not include any specific financial numbers, customer names, or any other sensitive information in the public OKR document. Instead, use placeholders (such as
M for 2 numbers or
C2 for 2 customers) and document their meanings in the linked
OKRs FYYY-QN Google Doc’s
Key for sensitive information section.
Changing OKRs mid-quarter
We don’t change OKRs once the quarter starts (with the exceptions below). Why? It is useful to have a conversation at the end of the quarter about how outcomes diverged from our plan, and why. There might be very good reasons why we changed our plan, and that is ok. If we edit our OKRs it becomes more difficult to have this valuable conversation.
If your OKR no longer accurately communicates what’s important or what you think is realistically going to get done, then you should immediately update the outcome with the expected result and a brief reason why.
When can you change OKRs mid-quarter? (In these cases, get approval from the CEO and everyone who’s affected by the change.)
- To include new priorities that weren’t captured by OKRs written at the beginning of the quarter.
- If the manager of a function or team changes mid-quarter.
Updating OKR outcomes
=> Outcome. for OKRs throughout the quarter.
- If possible, link to a live dashboard tracking the outcome.
- When you make meaningful progress toward an OKR’s outcome, post in the #progress channel and include a link to the PR that updates the OKR document.