Hey 👋 this is Luca! Welcome to a ✨ monthly free edition✨ of Refactoring.

Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.

You can learn more about Refactoring here.

To receive all the full articles and support Refactoring, consider subscribing 👇

Become a better tech leader ✨

OKRs is the world’s most popular goal setting framework.

It stands for Objectives & Key Results, and is used by companies and individuals alike to define goals and track their outcomes.

• 🎯 Objectives are qualitative descriptions of what you want to achieve. They are short and inspirational. E.g. Increase application speed.

• 📈 Key Results are a set of metrics that measure your progress towards the objective. E.g. Bring API response time under 1 sec for the 95th percentile.

They were famously introduced at Google by John Doerr, in the early 2000s, and they spread rapidly across big tech and startups alike.

However, OKRs are way older than that.

John Doerr learned about OKRs from Andy Grove during his time at Intel. Grove introduced them in his seminal book High Output Management, in 1983, but Doerr recalls hearing about them as early as in 1975!

Despite almost 50 years in the business, there is still controversy on how to create good OKRs. Companies struggle with the right formulation, cascading goals, following up with their teams, and more.

Examples online are often incomplete, and it isn’t clear how to adapt them to your use case.

This article is a primer on OKRs and how to work with them. We will cover:

• ✨ What makes OKRs special — why they are so successful and widespread.

• ⚔️ Outputs vs Outcomes — the key separation to make OKRs effective.

• 🔭 Beyond OKRs — frameworks and ideas that complement OKRs.

• 🎽 How to create OKRs with your team — a lean process and tips to get started.

• 🍱 Real-world Examples — from the likes of Atlassian, GitLab, Buffer, and more.

Let’s dive in 👇

⭐ Weekly Featured Jobs

Before we start, here are the remote engineering jobs featured this week! They are all from great companies and I personally review them one by one.

1. Confidence Systems — Frontend Engineer — define steps in any workflow, then track completion of those steps in real-time.

2. Clipboard Health — Engineering Manager — marketplace where nurses and CNAs can search for jobs, and where healthcare facilities can fill open shifts.

3. Caliza — Full Stack Engineer (Remote US) — building stable finance for everyone.

4. MessageBird — Senior Front-End Engineer — cloud communications platform that connects enterprises to their global customers.

5. Musixmatch — Engineering Manager, Frontend — AI company developing algorithms and tools for music discovery, recommendation, and search through the power of lyrics.

Browse many more open roles (or add your own) on the full board 👇

Check out all Refactoring Jobs

✨ What makes OKRs special

OKRs are so dominant because they bridge a painful gap in every company’s life: the one between goals and operations.

On the one hand, companies have broad goals that are set on a yearly or multi-yearly basis. On the other hand, they have operations that run the business. It isn’t trivial to make sure that the latter work effectively towards the former.

OKRs do so by providing alignment and scalability.

• 🔺 Alignment — they make the team focus on a small set of outcomes, on a short timeframe.

• 🔻 Scalability — multiple teams can contribute to the same OKRs by cascading goals. This is what makes OKRs work for big companies like Google, and small startups as well.

The first time I encountered OKRs, I remember asking myself: is this so hard that it requires a framework? Why is it any better than just having teams decide what to do for the quarter?

In my opinion, the secret sauce that sets OKRs apart is that they focus on outcomes rather than outputs 👇

⚔️ Outputs vs Outcomes

OKRs describe what you want to achieve (objectives), and how to measure success (key results). They are not prescriptive on how to get there, which stays under teams’ control.

Teams are responsible for defining initiatives that lead to matching relevant key results.

This separation between key results and initiatives is crucial, but it is not easy to pull off. Sometimes it is hard to find good measures for key results, so you may resort to using deliverables.

Let’s make an example: we want to improve the observability of our software by instrumenting it with dedicated tools and automatic tagging of logs. On a first try, we may create the following OKR:

• Objective: Improve how we instrument our software

• Key Result #1: Integrate an APM tool (e.g. Datadog)

• Key Result #2: Create labels to tag logs automatically

The problem with these KRs is that they are things to do, rather than outcomes. Integrating a tool and creating labels isn’t a measure of success.

Better KRs for the same objective might be:

• Key Result #1: X% of all user-facing requests travel through instrumented services.

• Key Result #2: Y% of errors from logs are labeled automatically.

Now we are onto something. This is at the same time 1) less prescriptive, and 2) more focused on the outcome.

The separation between key results and initiatives is not black or white — there are situations where using the latter is fine. It is so when:

1. Delivering the initiative is a good proxy for success.

2. You are reasonably sure about the way to go, so it’s ok to be prescriptive.

In this case, for example, you may add a third KR about setting a ceremony to review the metrics:

• Key Result #3: Hold 3 monthly meetings to review the instrumentation status

This is prescriptive and looks like a thing to do, but it is fine — having the monthly reviews puts the process in place and already sounds like success.

Finally, when it comes to goals and key results formulation, both Matt and Julien from the Refactoring community report using the SMART format. This is useful and may act as a checklist to validate items against.

🔭 Beyond OKRs

Although widely used, OKRs do not cover everything you need about goals and planning. Here are a couple of other ideas that I love and can be used in combination with OKRs.

💎 GEMs

The separation between KRs and initiatives is so important that some people believe the OKR framework is a bit flawed because it doesn’t address the latter explicitly.

Kathy Keating proposes an alternative format to OKRs called GEMs, which stands for Goals, Measures and Experiments. It explicitly adds the experiments part to the objectives and key results (now called goals and measures).

It might look like a simple change, but names do matter and I love it. You can find here the original article: 📑 Get your OKRs out of my GEMs.

🦥 SLOs

OKRs are for improving something or achieving something new. As a company, though, you also want to maintain what you achieved in the past and avoid regressions.

Avoiding regressions is just as important as improving things, and arguably heavier to track. At any given time, in fact, while you may focus on a few KPIs for improvement, you need to maintain all the rest of them.

Tracking these with OKRs is cumbersome because you would need to add a bunch of items that aren’t attached to any new initiative, and would therefore pollute the “real” OKRs.

SLOs were born to fill this gap. They stand for Service Level Objectives and collect the KPIs you want to maintain at a certain level.

You can set SLOs in combination with OKRs. Here is how Atlassian does it: 📑 How we work — a combination of OKRs and SLOs.

🎽 How to create OKRs with your team

Creating OKRs is a collective process. By involving your team in the creation process, you create focus and commitment towards the goals.

The ideal journey is a blend of top-down and bottom-up input. In a startup it may look like this:

1. 🎯 Objectives — the leadership team sketches high-level goals. These are mostly qualitative, non-measurable, and based on themes that may span multiple quarters.

2. 📈 KRs — some initial KRs are created top-down, involving managers of the respective teams / functions. These KRs are totally provisional and serve as a basis for discussion.

3. 🔨 Initiatives — the initial version of the OKRs is presented to the team. People come up with initiatives to achieve the KRs and adjust KRs themselves in the process.

4. 🔄 Iterate — KRs and Initiatives are challenged and improved over a couple of rounds of iteration.

For a thorough description of an effective planning process, you can check out this great article by Lenny Rachitsky and Nels Gilbreth: 📑 The Secret to a Great Planning Process.

Julien Evano, Head of Engineering at IXUP, also shared with the Refactoring community their process to run OKRs across the company, from vision & mission down to the single Sprint: 📑 OKRs at IXUP.

You can find plenty of articles on how to create good OKRs. No company is the same, though, and everyone needs to iterate to eventually find out what works for them. Here are some tips that have worked well for me in the past:

• ✍️ Don’t obsess over the right formulation — yes, KRs should be numeric, but you can really write them any way you like, as long as they measure success. Look at your KR and ask yourself “would I be happy to achieve this?” — if the answer is yes, then it’s fine!

• 🙋‍♂️ Avoid personal OKRs — if you are new to the process, start with team OKRs. Personal OKRs are tricky and can also backfire spectacularly if mismanaged.

• 5️⃣ Max five — Five is kind of a magic number for OKRs. Don’t create more than 3-5 KRs for each objective, and have at most 5 objectives for each team. Ideally, the full OKRs should fit on a single page.

• ⏱️ Timebox the process — don’t spend a full month preparing quarter OKRs, leaving your team with two months to work on them. Give yourself tight deadlines to create good-enough items. Done is better than perfect.

• 🗓️ Don’t assume you will only work on OKRs — over the OKR period there will be setbacks, maintenance, and unexpected opportunities you will want to catch. Leave some slack to allow your team to work on them. After some iterations, we settled on assigning only 50% of the time to OKRs.

• 👑 Have someone accountable — appoint someone to be responsible for the whole creation process. This person should collect the materials, set meetings and deadlines, follow up with people, and make sure everything is done on time.

• ⚖️ 70% vs 100% rule — there is advice around creating stretch goals that people are happy to achieve at 70%, and there is also counter-advice around creating achievable goals to make people happier. To me it doesn’t really matter, as long as you are consistent with the strategy you choose. People adapt quickly to either way.

• ➡️ Follow up — grade OKRs regularly: bi-weekly or monthly at most. Do not just create them and revisit them at the end of the period. You can attach the OKR check-in to other review ceremonies you already have to make it more natural.

🍱 Examples

Here are some good OKR examples from successful companies (more examples at the end).

OKRs by Atlassian

Objective: Roll out a refreshed version of our main product.
Key Result #1: Obtain 2,000 new product signups.
Key Result #2: Have product reviews published on 10 major industry websites.

Objective: Improve customer satisfaction.
Key Result #1: Reduce wait time on customer support tickets to 24 hours.
Key Result #2: Improve feedback scores on our customer surveys to an average four star rating.

OKRs by Buffer

Objective: Make a significant impact on Buffer’s MRR and revenue growth
Key Result #1: Get 1000 Buffer trial starts by end of Q3
Key Result #2: Grow the Social blog to 1.4M sessions per month by end of Sept Key Result #3: Pablo > Buffer trial starts at 20/day
Key Result #4: Communicate with Buffer user list at least every 3 weeks

Objective: Expand Buffer’s reach by helping new audiences get to know Buffer
Key Result #1: Get 10K people onto a Buffer webinar, 8,000 of whom new to Buffer
Key Result #2: Generate 250K views on 3 pieces of co-promoted content
Key Result #3: Hold 3 local events to attract 600 people who are new to Buffer
Key Result #4: Submit a detailed proposal for a Buffer conference by Aug 31
Key Result #5: Get 125K listens to a social media podcast by end of Sept

Objective: Innovate! Set a new standard for experimentation and thought leadership w/ Buffer marketing
Key Result #1: Create 3 videos per week to use on social media, blog
Key Result #2: Ship 1 engineering-as-marketing product
Key Result #3: Meet weekly as a mktg team to brainstorm and share new ideas
Key Result #4: Hire/work with: 1 marketing engineer and 1 designer
Key Result #5: Track NPS score in a daily dashboard and perform NPS cohort analysis for possible Q4 focus

CEO OKRs by GitLab

Objective: Encourage wider community engagement
Key Result #1: Develop a strategy to grow to 1000 contributors per month.
Key Result #2: Meet quarterly objectives for hyperscalers and partners.
Key Result #3: Achieve seven certifications with each more than 2,500 certificates issued.

Objective: Optimize GitLab Managed future
Key Result #1: Meet GitLab improvement goals (availability above 99.95%, free user RoI strategy).
Key Result #2: Meet SaaS improvement goals (increase customer empathy project in engineering, x customers live with Project Horse beta, launch storage visibility).
Key Result #3: Implement category creation plan.

Objective: Accelerate customer initiatives
Key Result #1: Improve SUS usability through completing 100% of quarterly initiatives related to Workspace, Learnability, and Foundations.
Key Result #2: First order large SAOs on yearly plan.
Key Result #3: Achieve X% of ARR on cloud licensing.

Engineering OKRs from Obvious Ventures (annual)

Objective: Build a stable, secure, and scalable platform
Key Result #1: No SLA downtime violations
Key Result #2: No more than 5% of users experience an error
Key Result #3: Average deployment downtime < 30 minutes
Key Result #4: Maintain 0.95 average apdex score
Key Result #5: 99 percentile API response time < 2 seconds

Objective: Build positive and collaborative engineering culture
Key Result #1: Engineering team employee voluntary attrition < 18%
Key Result #2: 1 team offiste or hackathon per quarter
Key Result #3: Internal Engineering "NPS" Improves Every Quarter

📚 Resources

• 📖 A Modern Guide to Lean OKRs — the best guide on OKRs I know of, created by Andrew Beebe at Obvious Ventures. It is organized in three parts and covers everything you need to know to get started.

• 💬 OKRs and planning at IXUP — Julien Evano, Head of Engineering at IXUP, shared with the Refactoring community their full process, from mission & vision down to the single sprints.

• 📑 Get your OKRs out of my GEMs — a great spin on the OKR idea that takes it further and adds the concept of “experiments”. By Kathy Keating.

• 📑 How Atlassian works with OKRs and SLOs — this piece from the Atlassian engineering handbook explains how the company combines OKRs and SLOs to deliver results.

• 📑 Inside Buffer’s Experiment with OKRs — detailed and transparent look at how Buffer started using OKRs, with actual examples.

• 📑 OKRs at GitLab — how GitLab runs OKRs. It includes processes, examples, and guides.

How would you rate this edition? 🤔

Amazing • Great • Good • OK • Meh