Felipe Castro is the founder of the boutique advisory firm Outcome Edge and an OKR trainer whose expertise and practical experience comes through in the OKR guides he’s created, articles he’s published on Medium, and in the talks he gives at conferences all around the world. In an earlier interview with ResultMaps, Felipe put OKRs into perspective and provided valuable insights, some of those listed here, for how OKRs plug into your organization.

👉 Watch the full interview with Felipe here

How to get started with OKRs

The way I explain it now is that the main problem we have with OKRs is what I call the "tinker bell approach." Basically, you take a traditional company using traditional management and traditional ways of working, and you sprinkle some OKR pixie dust on top of it. Companies believe that if they just sprinkle that OKR pixie dust and think happy thoughts, they're suddenly going to turn into Google and fly away. Of course, that never works.

Two real stories: First, a huge bank changed the label of their dashboard from "KPI" to "OKR" one week, and that was it - no actual change to using OKRs. Second, I was at a conference in Europe a few years ago, and a group of agile coaches said, "Oh, we're using OKRs," but they were writing really bad OKRs - just reductive results. When I asked how many people were involved, they said a huge number, like 8,000. And how did they train them? "Oh, we sent them a one-pager on how to use OKRs." That's a very common scenario because it's seen as magical - just say "OKR," and suddenly, people will know how to measure, understand the strategy, etc. But that's not how it works.

OKRs come from what I call the "startup way of working." Companies like Google, Amazon, and Netflix fight hard to still work like a startup. The best example is Amazon, where Jeff Bezos always says it's "day one," meaning they need to work like a startup. OKRs come from that model, so you can't take something from that model and apply it over a traditional company without changing how the company works. There's a lot of unlearning involved to use OKRs - you need to unlearn many of the old models because there are lots of things that don't apply anymore.

One of the hardest components of OKRs is unlearning. You explain the concept, and people say, "Okay, yeah, I get it, but I've been working the other way for 20 years." That's the part about unlearning. For example, when traditional companies say, "We want to be a data-driven organization," the very first thing they need to unlearn is the phrase "I have 20 years of experience in this industry" because experience is not data or evidence. I'm not saying to throw away experience, but it shouldn't be more important than evidence.

OKR cadence and rhythm

One analogy is that the traditional model is companies spending 12 months building a wedding cake, making it perfect based on the belief that the plan is correct because "we have 20 years of experience." A startup works differently - instead of building a wedding cake for a year, they try to sell a new version of a cupcake every week, testing different flavors, ingredients, production sizes, etc. They don't think they can get it right upfront. So rather than "Build me this CRM," it's "Here's what we're trying to achieve; let's figure out what will actually work."

What type of cadence do you find is most helpful when adopting OKRs? How often should teams look back to see how things are going and what needs to change? The idea is that OKRs work like Russian nesting dolls with different cadences and cycles. You can have longer-term, typically annual, higher-level company OKRs for things that take longer to change because they're more stable. Then you usually have quarterly team OKRs, and we track OKRs every week to see what's working or not and try something different based on the measurements that week.

It's not that "feature factory" approach of putting something on the conveyor belt and never seeing it again. It's "What version of the thing did we try last week? What's our next hypothesis to try this week?" The idea of learning fast is crucial.

OKRs are a way to keep score

The idea is that OKRs are how you keep score - the scoreboard showing if you're winning. Some people play individual sports with individual scoreboards, while others play team sports. So if you're working on a cross-functional team all trying to achieve the same outcome together, you want a team-level OKR, not individuals going in different directions.

But in functions like sales or recruiting, where people operate more individually, you can have individual OKRs. The idea is to use team OKRs when you have an actual team structure and individual OKRs when it's really just individuals who happen to report to the same person. If you have a proper team like an agile team or product squad, you usually stop at the team level. Companies like Spotify and Google don't use individual engineering OKRs anymore because they don't make sense in that team scenario.