What SpaceX can teach us about OKRs
Why and how you should use OKR (Objective and Key Results)
So… Turns out I actually have no idea if SpaceX uses OKRs, but I thought it’d help me drag your attention on this not-as-sexy (but so important!) subject. And now you’re here, I swear I’ll do my best to use them as an example.
You probably heard about OKR, pretty name that stands for “Objective and Key Results”. It looks like they’re all over the place these days, presented as a game changer in the way you run your company, creating focus and aligning team efforts towards the same goal.
OKRs look fairly simple. They’re nothing more than a set of objectives linked with measurable key results, that you’ll grade — and update accordingly — every quarter. For your company, for your teams, sometimes even for individuals. It’s an amazingly good execution framework, but also a fairly challenging one to put in place.
OKRs are hard. Why bother?
Poorly written OKRs will add process overhead, and will be at best a waste of time, at worst a source of frustration. Good OKRs will align your entire organization on the key measurable outcomes you expect in the quarter to drive success. For your company, and for your customers.
So what will actually “change the game” in my opinion is how you’ll define them with your teams, and more importantly how you’ll continuously use them in order to develop and maintain:
- Operational efficiency, as you adapt your organizational structure to remove redundancies and optimize for clarity.
- A shared and common understanding of what success means, and how each team is contributing to it.
- A sense of ownership for your teams — which means responsibility, accountability, and authority — helping you push decisions down.
We’ll get back to these aspects later on, but for those of you who are new to OKRs — or need a refresh — let’s cover first how it works, dissecting piece by piece the scary diagram below:
Start from your company mission
Let’s start simple with one set of OKRs, for the entire company. Company OKRs typically derive from your mission, which defines the purpose of your organization, and what everyone is hoping to achieve by working there.
And let’s take a cool example with SpaceX! I actually have no idea what their OKRs are — or if they even use OKRs — but I do know what their mission is:
To revolutionize space technology, with the ultimate goal of enabling people to live on other planets.
Bold. Now in order to accomplish this mission, they likely have a product and go-to-market strategy in mind. A good starting point to set objectives.
Stable and high impact Objectives
Objectives are high impact, long-term goals that are stable over multiple quarters. A given set of OKRs should have 3 to 5 objectives. They should be aligned with your Mission, helping you get closer from that higher purpose everyone in the company is hoping to achieve.
I also like them to be exhaustive. Anything that is not helping moving an Objective forward — or one of its Key Results — should be left aside. It will help you prioritize and focus on high impacting things.
Good objectives, aligned with your company mission, will align everyone on what success means for the company. Giving direction and sense to everyone’s work.
Back to SpaceX and their mission to colonize Mars, a big piece of their strategy must be around reducing quite dramatically the “Earth-Mars” ticket price. Noticed how airplanes work for more than one flight? Well, SpaceX needs to build re-usable rockets, leaving launch costs to fuel and maintenance. Just like an airplane. Which means — amongst many other objectives — to manage atmospheric re-entry, for example.
Measurable and outcome based Key Results
Key Results are quantifiable and measurable outcomes that help achieve objectives. Each objective should have 3 to 5 KRs. They may change from quarter to quarter, or their metric threshold might be adjusted.
Back to SpaceX. What would be a measurable Key Result that helps us achieve our Objective (remember: manage the rocket’s atmospheric re-entry)? Slowing it down from 3,000+ mph to 550 mph (an acceptable speed so it doesn’t burn up in the atmosphere) sounds like a good start. And I’ll stop the analogy here, cause I really have no idea what I’m talking about.
For a Product team, Key Results would likely be based on Churn, or certain type of engagement from a particular cohort. On Customer Support side, it’d be metrics like the NPS, or the average issue-resolution time. And the closing rate, or the average time-to-hire on Recruiting side... You get the idea.
The important bit here is “measurable outcome”. Because you will grade these Key Results at the end of each quarter. And you should design them to push your teams to their best, by making them stretch. On a good (but not great) quarter, you should achieve an average score of 70%.
How is it different from my roadmap?
Think of your Roadmap as how you intend to achieve your Objectives. There is probably a bunch of things you’re planning to do in order to move a Key Result during the quarter. Now some of these items will end up moving a metric, others won’t. Market conditions will change, other ideas will arise…
So don’t come with a long list of outputs — or ToDos — based Key Results. It defeats the idea of giving ownership to the team, “locking them” on a predefined list of tasks, and it will end up disengaging them.
Key Results are not a list of what you will build during the quarter. They should be based on Outcome. Leave the “how” to the team.
You didn’t put all these efforts in hiring smart people, just to tell them how to do their job, right?
So don’t build Output based Key Results. Have your Key Results drive your teams’ “ToDos”, not the other way around. For example, avoid things like “Ship X”. Why are you planning to build/ship that feature, and which metric will it move? That’s what your Key Result should be based on.
Let’s take another example with a University, whose Objective is to produce highly employable graduates. A good — Outcome based — Key Result would measure the percentage of graduates getting a firm job offer within X months. Rather than measuring the percentage of graduates that get an X+ grade, the time they spend in class, or the amount of courses they should attend.
OKRs are recursive
Now you (hopefully) get a decent sense of how it work, let’s get a bit deeper with recursive OKRs, cause that’s where all the fun is. Note that a single set of Company OKRs can get you pretty far, and I’d recommend you to keep it that way for the beginning, particularly for small orgs.
But as your company grows — and you get familiar with the methodology — you’ll eventually need to develop other sets of OKRs, per team. Each of these sets should be in service and consistent with your higher level OKRs.
As an example, most startups start with separating their Product Engineering and Sales teams OKRs. Again, watch out for alignment and consistency. Let’s take the example of a SaaS business, who’s looking to reduce Customer churn and grow the LTV per customer.
Sales complains that Product is not good enough. Product complains that Sales is bringing non-qualified customers. Sounds familiar? Now you notice Sales’ Key Results are based on deal volume. How is that aligned with your Company OKRs? Wouldn’t it be better to incentivize your Sales peeps on customer retention? Or at least on a particular customer profile, whose Product is actually designed for?
This process, during which you’ll design and align OKRs across your organization, is a great opportunity to learn and improve your operational structure, while giving sense to everyone’s work.
How to create OKRs for my teams and align them?
Start by providing guidance through Company OKRs, then ask your teams to set their own OKRs. The first thing they should look for are Company Objectives and Key Results they can directly help achieve. Typical scenarios:
- Sometimes there will be a Key Result that is their direct responsibility, in which case it is likely to become a whole objective for the team. Easy.
- In larger organizations, there will be Key Results that the team will contribute to achieving, but will not be solely responsible. Watch out for unnecessary redundancy here. Otherwise their OKRs should cover the contribution they can make.
- Teams could also have Key Results whose outcome has a dependency on the work from another team. It’s their job to negotiate and get commitment from the dependent team (who might have a KR to represent that dependency). That happens pretty frequently in engineering between Product and Platform teams. Or between Sales and Product teams.
- Occasionally, there will be no higher-level key result the team can directly affect. In such a case, is there a higher-level objectives — rather than a key result — that the team can affect? And if they still can’t find anything, that should raise a flag on your organizational structure.
This process alone will help you align your entire organization, in addition to flag redundancies and dependencies created between teams. It will give you good insights on how to adapt your organizational structure, optimizing for clarity and operational efficiency.
Grading OKRs and individual performance
At the end of every quarter, every team should grade their respective Key Results. It’s all about holding yourselves accountable to business outcomes, and evaluating your goal setting abilities.
As you might remember, Key Results should be designed stretch. So on a good (but not great) quarter, you’re looking for an average score of 70%. The point of grading is to look at each Key Result, and think about why you got that grade.
Was the Key Result poorly written? Was it too challenging, or on the opposite too easy? Are there things you could have done differently to make more progress? What does that mean for the next quarter? It’s a team exercise everyone should go through, transparently.
But individual performance and promotion should remain independent of the Key Results grading. You should actually base your promotions on a separate feedback cycle, and a clear Job Ladder that defines what is expected at each level. But that’s separate subject. More on this here if you’re curious.
OMG, I got more questions!
Ha! Well, if you actually do have more questions, you can certainly send them through comments. Or check out some actual OKRs examples. This template from niket is a good starting point, just like his example on Uber.
But the best thing you could actually do is… To give OKRs a shot. That’s really how you’ll learn the most, and how you’ll be able to adapt this framework to what works best for your organization.
We got it wrong many times with my teams. And that helped us get better. From the moment we’d collectively define them, to the moment we’d grade them. Because every single quarter, as we’d reflect back on our performance and the choices that led us there, we’d ask ourselves the tough — but right — questions. And I believe that’s what pushed us to continuously prioritize, adapt, and more importantly, to learn.
