Credits: The Japan Times

How to achieve goals and track performance

What you need to start using OKR

Bernardo Lemgruber
8 min readNov 30, 2016

--

Companies of all sizes and segments share the same challenges when trying to define and track performance metrics. Everyone wants to know if they’re doing good or bad and, most importantly: how. Even those that already know what to measure, often get lost on how to do it. It’s not an easy task to collect, compile and interpret metrics while building a disruptive product.

Here at VTEX we work in independent teams: each team has ownership of a different product and chooses their own methodologies, technologies and road-maps. We have discussed a lot about the pull between unifying versus keeping this extreme independence. The idea behind unifying processes is not to increase bureaucracy of course, but to give more visibility to each team’s progress and to turn transparency into a natural way of accountability.

Last year, some teams started experimenting with OKRs (Objective and Key Results). This methodology was created at Intel and became popular when Google started using it (at their very beginning). All the recent hype around it makes sense when you realize OKR can be used in a lot of contexts, scales and projects: the company, the team, yourself, to create events, plan vacations… and even parties!

What is it made of?

This is a brief x-ray of all components organized in an OKR sheet as we use on my team. If you want to play around with a more detailed version, you can copy and use this template as you wish. Now, let’s break it down!

Objective

Start with a clear objective.

This is the main component of an OKR. It must be ambitious and inspiring. A good objective makes you a little uncomfortable: it pushes you further and tastes like the uncertainty of not knowing if you’re going to make it. These are some questions that can help you define the objective:

  • Why are we doing this?
  • Why is this project more important than others?
  • Where do we want it to go?
  • What makes my eyes shine about this project?
  • Will it be hard to achieve?

Key Results

One is not enough, three is good and five is too much.

The Key Results (KRs) relate directly to the objective: they are steps that get you closer to the objective once completed. The most important thing here is that they must be measurable — only then you can say, for sure, if you have achieved it or not. To help you define your KRs, answer these questions:

  • What results do we need to obtain to achieve the objective?
  • How does this KR make us closer to our team’s objective?
  • Is it possible to measure and/or quantify this KR?
  • What number says that the result has been achieved?

Confidence Level

The Confidence Level is different for each KR.

Each KR receives a confidence level grading (on percentages). It must represent how confident the team is about the work they’re doing. Reviewing this number frequently is a good practice because it helps prioritise things and makes the project more transparent and easy to follow up. When in doubt, ask yourself:

  • How far (or close) are we to this result?
  • What are the chances of completing this KR?

Tasks

Break the KRs into tasks. It makes it easier to organize the project.

KRs are the results you want to attain, but they’re not tasks. It’s very important not to mix both concepts. Think about what has to be done in order to reach the results you have defined and make a list of all tasks you need to work on to get there. This is, literally, your to-do list.

  • What do we need to do in order to reach my results?
  • How can we make a list of our present and future tasks?
  • Is this a task or a result? (this is a good one to verify your KRs)

Health Check

The colors help to understand what’s going on with a quick look.

The Health Check says if the project is being delivered as expected. For example, if code quality or visual design details matter to you, they should be an item on this list. If there are any processes that need compliance, they should be there too. When defining the Health Check, ask yourself:

  • What’s important to guarantee that the project is on the right track?
  • Is there any compliance involving this project?
  • What are the project limitations?

Risks

It is important to have a risk list on sight so that you never forget what can go wrong.

No matter how much we plan, we just can’t avoid surprises. What we can do is prevent ourselves by listing known threats. This means actually making a list of what can put the project at risk. Of course, we can’t know everything, but this “risk list” is intended to make you more comfortable to take conscious risky actions.

  • What threatens my project?
  • What could go wrong in a near future?
  • Is there any external factor that could have a negative impact on the project?

Critical Path

Mapping the critical path helps a lot.

Google has a good definition for this. The concept is pretty basic: think about the sequence of mandatory activities that need to be completed in order to reach your goals and how they depend on each other. Something very common is interdependence between teams, for example.

  • Which are the critical activities that impact directly my OKR?
  • What doesn’t depend on me but it’s fundamental to reach project goals?

What now? What do I do with this?

There are no “10-step rules” to use OKRs. Here at VTEX each team made their own adaptations to the methodology in order to fit their own workflow. The good news is: there are some best practices and ways to know if it’s working or not.

I interviewed people from different VTEX teams to learn about their experiences and investigate what went well, what didn’t, and what they have learned so far. The result is a list of the best practices for the successful use of OKR:

1. Rhythm

Teams that succeed above the average with this methodology meet every week to review their work, and their OKRs and make the necessary adjustments. Some teams meet once a week to review everything. Others meet on Monday morning to define the week’s goals and meet again on Friday afternoon to evaluate their progress.

What’s important here is to establish the ideal rhythm for your team to revisit the OKRs. Everyone I’ve talked to considered these meetings their most important ones.

2. 70% is ideal

The objective must be ambitious, remember? This means that if you fully complete your OKR on a regular basis, you’re not being ambitious enough. Each company and team have their own sweet spots to define what’s acceptable. Here we defined 70% as our ideal.

This number means you’re close enough to your objective to see a light at the end of the tunnel — when you’ll be more mature to decide where to go next. Which is perfect to define your next OKRs. Oh, and don’t forget this: bad performance should not be punished, they must be faced as learning opportunities.

3. OKRs are public

One of our objectives while implementing OKRs here at VTEX was to put everyone on the same page, not only the project team but also other teams. We also wanted to be more transparent about what’s being made by everyone and follow up on the product’s evolution.

As we use Slack for internal communications, we put the link to our OKR on the team’s public channel topic. This was a way to make it easily available for everyone in the company to access and see:

In essence, OKRs must be public. The whole company must have access to what everyone is developing, has developed or will yet develop. In our case, simply putting it on Slack proved to be very efficient.

Practice. I want practice.

To speed things up and be more public, some of our teams used Google Presentations to make their OKR boards. I’ve made a template you can copy to start with OKRs.

There are a lot of apps and tools out there, but a simple slide presentation was everything we needed.

When we started using it in my team, we wanted to learn and understand the methodology as fast as we could. Though OKRs are usually made for three months, we chose to start with monthly cycles. We did this until we felt comfortable to set an objective good enough for three months — which ended up happening naturally.

During the weekly meetings, we duplicate the current slide and make all modifications on the copy — the easiest way to keep a history, week by week, of our progress. To make meetings shorter we split them into two: one on Monday and the other on Friday. On Mondays, we define tasks for the week and set the confidence level for each Key Result. Friday was the day to review what we accomplished and what is pending, update the Health Check and make a preview list of next week’s tasks.

One last advice.

After you define your first OKR, look at it and ask:

  1. Is it inspiring?
  2. Is it measurable?
  3. Is it transparent?

If you answered a confident “yes” to all three questions, chances are that you have an excellent OKR on your hands.

What else?

Nothing else. Now you already have a template and know how everything works. Get out there and test it! If you want to dive in, there are a lot of articles and videos on the internet — check these two to get started.

How Google sets goals: OKRs. A Medium article from Rick Klau, founder of Blogger and partner at Google Ventures. There’s a video detailing how they use OKR at Google and giving some historical context as well.

The OKR Guide. A link full of resources about how to implement, examples, stories, slides and much more.

If you enjoyed but still have any doubt about it, let’s talk! Comment here or tweet me!

Thank you Robyn Steinberg for inspiring me to write this article. I hope that OKRs help at Wix Lounge! 😊

At last, a special thanks to whole VTEX team who is always testing new things, experimenting and growing together. My OKR partners: Anderson Moreira, Rodrigo Dumont, Felipe Castro, Bruno Abreu, Breno Calazans and Gustavo Giserman.

Also everyone who contributed to this article: Wellington Fabrício, Fabio Caldas, Augusto Barbosa, Daniel Fosco, Gabriel Galc and Luiza Breier.

There’s also a Portuguese version of this article! 🙌

--

--