OKR Best Practices

by Viacheslav Kovalevskyi

Part I: Objectives

This a concise guide on how to start writing your OKRs.

Start with creating a tracker of:

  • customers that you are aiming to onboard
  • their problems (problems that you are seeking to solve for the customers)

The most crucial part is that the list of problems has to be sorted. You should always be aiming at solving the most critical problem that your customer is having.

Remember that you are NOT "building a product" but "onboarding customers." Building the product is just a part of the onboarding process.

Solving customers' problems should be your objective, and therefore each objective should specify the problem you are aiming to solve and the list of customers with this problem. Be ready to answer why you think this is your customers' most crucial problem.

Remember, success seldom depends on picking the right engineering tool/project to build. It depends on choosing the right problem you are aiming to solve. So spend extra time verifying that you go the right problem.

Q: wait, but what if I do not have customers? What if my product is used by internal teams only?

A: there is always a customer, the fact that the customer is internal does not change anything. If unsure who your customer is, consider which team/org/person's feedback will be the most impactful when evaluating your effort's results. Very likely, that is your customer.

Part II: Key Results

Next, to keep yourself honest, you should come up with the KRs that will be good proxy metrics that will indicate how good you are at solving the problem for your customers. KRs should be measurable metrics and not binary facts of delivering the products or features themself.

Q: but what if I know metric, but it is almost impossible to measure it?

A: find the next closest proxy? What about surveying customers? What about just picking one company and asking their opinion at the end?

With basic things out of the way, let us cover several examples. First, an awful objectives example:

  • "Build unified engine for scheduling long running jobs" - what is the problem? Who is asking? Is this the most pressing problem my customers are having?
  • "Improve users experience of our web site users" - while we can identify customers, they have so many problems that this usually might mean anything.

Better example:

  • "It takes our customer 2 IC per year to run the manual process of scheduling long-running tasks by starting the VM manually and running scripts (customers: x/y/z)."
  • "We are spending X$$ on the CI system more than allocated in our budget."

In many cases, objective already includes good measurable values. A good example of verifying if your objective is well written is this: you should be able to show the objective to a random person in your org, and they should be able to tell you if the problem from this objective has been resolved or it is still there. The opinions should be the same if your objective is well-written according to the UODP principles.


Now we can identify good proxy metrics that can give us more exposure if we solve the problem. Let's start with bad examples:

  • Deliver (release) a new service that allows the customer to schedule long-running jobs
  • Refactor CI to use CPU-only instances more often

These KPIs are hard to measure. The rule of thumb: if you can easily find a way to resolve your KR without solving a problem set in the objective, this is probably a bad KR. For example, one can find a way to use CPU-only instances more often, but this could move the needle only 0.0001%. Is this good enough? should we declare KR as green? KRs like this allow one to declare almost anything as green or red. Same as the example with the new service, if the new service is used by 5% of your customers, the initial problem is still there; 95% of your customers are still scheduling jobs manually.

Better KRs here could be:

  • X jobs are scheduled on the new job scheduler (and not manually)
  • Customer Y no longer has to have one IC constantly allocated to the manual job of scheduling jobs
  • Z pipelines have migrated to the new job scheduler
  • Cost per month to support our CI reduced below Y$$

Having good OKRs gives several benefits:

  • They give clarity on how success will be measured.
  • At the same time, there is no micromanaging how the team should be delivering it (the team is free to pivot at any point to a different effort if they find a simpler way to provide an impact)
  • They protect the team from un-required pivots