Objectives and Key Results (OKRs) | Felipe Castro

Hey everyone. Welcome to the new economy. I'm Scott Levy, CEO and founder of Result Maps, where we're on a mission to help the world be its inspired best. That means helping CEOs and leaders build healthy cultures of relentless execution so you hit your numbers and thrive no matter where your people are or what challenges come your way. One way we do that is bringing you these sessions with leaders who've learned to thrive even as they navigated uncharted territory and thorny challenges. The idea is to get you actionable, learning you can put into practice immediately to lead and navigate at your best as you thrive forward.

Today I speak to Felipe Castro. He's the founder of the boutique advisory firm Outcome Edge and an OKR trainer whose expertise and practical experience comes through in everything he writes and, and the talks he gives all around the world at different conferences. What stands out to me every time I read an article or download a PDF from Felipe is how it's very clear that he's not just jumping on an OKR bandwagon. He's really thought about these topics deeply and done the hard work of helping people translate them to action. And his ability to distill what he's learning and cycle through different narratives to help people learn faster is really outstanding. So I'm excited to bring his learning to you. Don't forget to hit that like button and subscribe to get all our updates. And with that said, let's get started.

I'd love to hear a little bit about how you became passionate about okrs. Is that something you've always been interested in? How did you get into being this well known OKR coach?

That's a famous speech by Steve Jobs where he says that you cannot connect the dots looking forward to only connect the dots in your life looking backwards. So I'm an engineer by training. I started working in startups. So I did business development, product sales, I did everything. Startups lived in bay, in the Bay Area for a while. After that I completely changed my career. I became an executive recruiter, headhunter. So they're recruiting for that company. So I have them user teams, etc. After a while I found my own recruiting firm. So we hired back companies. Then eventually the companies, some of the clients started asking me, hey, can you help us with other stuff besides recruiting? And then that led me to helping them with performance management, which led me to helping them set goals and led me to realize, hey, this is broken. This is not working. Because at the time we're doing like work with companies that use balance Card or something like that where like in October you're trying to predict what you've been achieving in December of last year. So it's 14 months later. And it basically kind of worked for everything that the companies have been done for a while, been doing for a while. Right. But anything that is new or a new product or any uncertainty at all, it was totally broken. And then I started looking for a solution and then when I found okr, oh, that's like an agile iterative way of doing goals that seem to work and then I basically jumped by. Then it would be like, I don't know, 2013 or 14, whatever. I started doing that and that's 100% of what I do now. I started with the pain and then.

I take it as an engineering background that led to the phrase Full Stack. Would you call it Full Stack okrs in one of your presentations?

Yeah, yeah, I used to call it Full Stack Agile, Full Stack Agile, End to end agile. The idea is that the way companies use Agile, usually they use Agile 4 for delivery only. So the way the SaaS strategy is waterfall, the way they plan is waterfall, the way they set goals, the way they reward people, the way they compensation. So everything else is waterfall. So basically the last part of the business, right, if you look at the either end to end or a stack with several layers, only one of them is agile and the whole rest is basically waterfall. So one of the things we need to do is to stop doing waterfall waves. So it's annual behavioral planning, telling people what to do. So everything that Azure is not, people used to do that. The way I see it is that my work is to experiment with different narratives to see what helps people learn. So over time I'm basically changing my product or my narrative because some narratives work better in the way to achieve the learning outcome. What we need to learn while speaking the language and the narrative. So although the concept of the Antman Agile or Full Stack Azure, something that helps people, I have evolved to other ways of explaining the same thing. So the way I explain it now is that the main problem we have with EVOKR is what I call the Tinkerbell. So basically you take a traditional company using traditional management, traditional ways of working and you sprinkle some OKR pixie dust on top of a traditional company and companies believe that if they just sprinkle that pixel dust of OKR on top of it and if they think happy pots, they're going to suddenly turn into Google and fly away. And that of course never works. Two real Stories. Right. First True Story is a huge bank. Like a couple years ago, they basically just changed the label of the dashboard. They had a KPI dashboard. One week was KPI, the very next week was okr, and that's it. They only changed the label. Right, yeah. Those are okrs, of course. And no, no, you're using okr. True story, secondary story. I was in Europe years ago in a conference and then a group of agile coaches reached out to me. Oh, we are using okr, et cetera. Having problems for writing really bad okrs. They're writing deductive results. So we talked about how to solve that. That's okay. How many people were involved? Oh, I know, huge number. Like 8,000. Okay. And how did you train them? Oh, we sent them a one pager document, how to use OKRs. Oh, I see.

That's a very common scenario, by the way.

Very, very common. Because it's magical, Right? All I have to do is, hey, just say okr. Somebody told me that the default state of corporate goals is to suck is things that are not manageable. Just a to do list. Just a list of activities. So they're really, really bad. Right. And just calling them okr, they'll default to being really bad again. So it's not because you call it OKR that I'm going to measure. Oh, now people know how to measure things. Yeah, now they understand the strategy. They magically know how to measure things. They know how to align. That's not how it works since OKR comes from what I call the startup wheel working. So if you look at companies like Google, Amazon, Netflix, they are not startups anymore, but they fight really, really hard to still work like a startup. And the best example is Amazon, where Jeff Bezos always says it's always day one, so always a startup. And the building that he's based on is called Day one. And when he moves to a new building, they took the name of him. Hey. The new building also calls day one because the message is we need to work like a startup. Right? So OCA comes from that model. So the startup ways of working. Right. And you can take something that came from that model and apply it over traditional company without changing the company. Okay. So you need to change how you work. So there's a lot of unlearning involved to use. Okay. You need to unlearn many of the old models. So there's lots of things that doesn't apply anymore. And I love the. There's a great book by Barry O'Reilly called Unlearn and Barry defines unlearning as the process of moving away from behaviors and mindsets that were once used in the past, but not limit your success. So there are two, say, yeah, 10 years ago they were amazing. 15 years ago, 50 years ago they were amazing. Now not so much. And because if you compare the way that the high performance teams work today and the way most teams work today is radically different. Right. So the idea that we can predict the future, that we can. Oh, we can plan. Right. It's a very, very common problem. Common problem, right. So one of the things that we need to unlearn is that idea that we can make by planning, spending more time planning, we can reduce uncertainty. Not. All right, so by planning more or creating a perfect plan, you can eliminate uncertainty. That doesn't happen. Right. So things you need to unlearn. One of the hardest components of OKR is unlearning. You explain the concept, people go, yeah, I get it, but I've been working the other way for 20 years. Yeah, that's the part of learning. So one simple example of unlearning is often when traditional companies reach out to me and they say, we want to be a data driven organization. So the very first thing you need to unlearn is the phrase, I have 20 years of experience in this industry. Your experience is not data, it's not evidence. So we need to learn 20 years of experience, say, hey, what's the evidence that backs this idea? What's the evidence that backs this? Right. I'm not saying throw away your experience. I'm just saying that just because I have 30 year experience doesn't mean, doesn't mean that that can be more important than the evidence. So it's very hard for people to unlearn that because we're used to having all the answers. And so that's a big chunk of what we need to learn.

That was one of the other things I liked in one of the downloads you had was you'd taken that idea from Spotify of, you know, you have kind of the traditional Kanban style. We have a backlog or ideas. We're working on these, we finished these, but there's a missing column which is we got the result we wanted. And that idea that everything up to that point is all about learning. Yes, you want to deliver, but.

But if you're not learning.

You'Re not really. You don't have agility.

The thing is, that's an idea from the common board, which is missing a column is from John Cutler. He's amazing. The Idea is the way most things work today is a feature factor. So you basically, hey, you give them, hey, I need to ship that thing. And then it needs to go like in the conveyor belt, assemble the line and abuse the feature and goes away. And you never see that feature again ever. Right? It just goes away and goes away. Can you think about the tool we use? Like a camel board? Right? Just go away. It's not a loop. Like they come back and okay, let's measure and do it again and see if it works. I was just on a call with a client. They were saying, oh, we have a problem because we launched our app and the app allows you to, I don't know, to deposit the check, get my idea. But we did it like last year and we launched it once and we never touched it again. And the number didn't go up. Yeah, it did go up a little, but since they're not going back to the same problem, it's not as good as shipping. So you need to unlearn this idea of a feature factory and start thinking about a product. So you give a problem team to solve or an opportunity and they're working on the same thing until they move the needle. Right? So. So that's a big difference between shifting from a feature factory where I measured by outputs how many things I ship, things like story points or velocity or number of probes delivered versus hey, did we make the difference? Did we make a difference or not? So what's the outcome? What is that result? What's the benefit you want to deliver? That shift is huge and is a big thing to learn.

What are your thoughts on how you should you cascade your okr, should you not? What are some of the traps you've seen people fall into trying to say, take my strategy and represent this and then mobilize this to my organization?

Cascading is one of the things that we need to unlearn because it's something that it's so old that people believe that there's no alternative. And cascading became a synonym of spreading the strategy. Quality work. If you want to spread to a line, yeah, that's great. But if you think about it, a cascade is a natural phenomenon which is you unidirectional. There are no feedback loops at all, no adjustments, and it ends crashing on the rocks. It's not exactly the analogy you want. Right. And by the way, escape is a synonym for waterfall. That's going to cap. Right? Stationary synonym for waterfall. So if you want to become more an agile organization and using oh, we're following our goals now, so that's probably not the best way to do it. The idea is to have a conversation back and forth. There's a discussion. One story that usually helps is real story from when jfk, when Kennedy launched the Luna Club, right? So basically was the 60s Cold War and the Soviet Union was way ahead in the space race, right? Had the first satellite, Sputnik had way better rockets. They put the first man in space. So they were way ahead, right? And at the time, imagine what will the Soviets do, take control space. Nobody can know, right? People were actually terrified by it. And also another problem they had was okay, people may like freedom, but when they see that the Soviet Union is way more efficient, maybe they align with them, which is a dictatorship, et cetera, instead of democracy, because hey, this thing, what they're doing is work. So they also had an image. So that's the top level problem they're trying to solve. That's the problem we need to win the space rate, otherwise that can affect the code. And then what happened was can't reach out to NASA via his vice president Linda Johnson. And then, okay, what can we do? And then NASA said they have way better rockets, they're way ahead of us, so there's no way we can compete with that. But going to the moon is so hard that they have to start from scratch just like we do. So the investment they have today is meaningless. So they decided to go to the moon, right? And the way that Kennedy presents the story is he goes to the Congress and says, I believe the nation should commit the go off at the end of this decade, take a man to the moon and bring him safely to the Earth. He described that as a problem to NASA. The NASA has to go in and come back safely. And it doesn't say, oh, I need a three stage rocket, here's the spec, go build it or here's the features I want in the rocket. No, it gives NASA a problem to solve. And the very problem that they decided to work with, work on was actually after lots of back and forth, okay? So that's the power of it, okay? And that's exactly the idea. So it's not about telling, you know, hey Scott, give me that feature. It's not even hey Scott, work on this problem. Hey Scott, it's our top level strategy and I believe that we should work on this problem here. What do you think? And then we have a conversation. And this was okay, So I don't know, let's say we want to reduce churn before canceling a lot or decrease retention. And then, oh, Scott, we believe that, I don't know, we have lots of bugs, so we need to solve that. What do you think? And then have a conversation. Maybe you say, yeah, it doesn't seem that bugs are the main issue. Maybe it's a lack of value in the product. So we need people to use the product more and get more engaged with it. So even so, there's a back and forth to the conversation and that's the real power of it. So you explain the problem you're trying to solve, you explain the context, and then I say, okay, what do you think? So that's the way I'm thinking. And I say, hey, can you try to poke holes in my model here? So you have a conversation, right? So that's the real power of it. So Netflix has. One of the management principles of Netflix is lead with context, not control. It's exactly the idea. The idea is, hey, this is the context. We have the Cold War, have the space race. The persons are way better than us, they're winning. What can we do? Can we like. But I made in space first. Sorry. The rocks are way better. Eh, that's that. Oh no. So let's try to go to the moon. So not only in this story, the government and Canada gave NASA a problem to solve. NASA was part of selecting the problem. Another historical example, when the Japanese launched the bullet train, they gave engineers a problem to solve. We need a train that's capable of going 120 miles per hour safely. That's the problem. It didn't give them a spec, user cases or whatever. That's the problem we need to solve. The concept was it's after the Second World War, we need to rebuild the country, the economy needs to grow and it's taking too long for people to go between the two major cities. In Japan, train is the main approach. So we need a faster train. And then after several years of innovations, they actually launched the bullet train, which went at 120 miles per hour in 1964. So that's a really fast train for 64.

Handing off a specification. There's so much attention today put into teaching people just to write a relatively clean spec. There are certain times where we think through a specification and what I think we found ourselves doing that it sounds like a lot of companies don't, is you say here's the spec, but what's the context? And is this the right spec versus here? I'm just going to give you a specification that's a very different way than a lot of people are taught to. To deliver code, for example, you've got to have all the specifications. You've got to be more and more detailed as a way to provide context.

The idea is when Agile was created and Agile frameworks like Scramican were created, we didn't have lots of the techniques that we have today. Right, Right. We know how to run experiments and test things. It's totally different than the way they work like 20 years ago. So it doesn't make sense to use Agile or scrap the way they used it 20 years ago. Right. So the idea is if you use a scrum or command and you say, oh, where the backlog comes from, let's change that back. What if, what if instead of having a stakeholder, tell people what was the backlog, what if we gave them a problem to solve? Explain the customer need we explain the problem and we let the team test different ideas until they figure out. Right. Right. One analogy I like to use is the traditional model. Companies often spend like 12 months building a wedding cake, several months of the best cake on the planet. Beautiful, but very spec. Because we believe that the plan is correct, the spec is right, we have 20 years of experience. Of course, you're right. While a startup works a very different way. So they basically, instead of building a wedding cake in a year, they try to sell a cupcake every week. And every week they test different versions of the cupcake. Right. And think about how many things you can learn by testing different versions of the cupcake. You can test different flavors, different ingredients, production sizes, finishing colors, whatever. Right. Because these are things that you can test. So test several different versions of the thing. So instead of, hey, build with this wedding cake, figure out how to win in the cupcake market. So. Right. So give them a problem to solve. Let's figure out how we can make money and make customers happy in the cupcake market. So let's try to figure out a gazillion different ways to make cupcake and see which one is awesome and which one works. So the team has the autonomy and the team has the techniques, the context and the autonomy to, hey, that's different idea to figure out, hey, which version of that case might sound so the same going back to Kennedy or to the train. Which version of the bullet train is actually going to work and go at 120 miles per hour? Which version of the rocket is going to get people through the moon and back? Yeah, we kind of know it's a rocket. Yeah. But it's going to the moon. But which version of that effect you need to build a new CRM is. Okay. What we're trying to achieve in CRM is this. And let's figure out what directly work.

What type of cadence do you find is most helpful do you have when you go into clients to help them adopt okrs? How often do they look back to see how things are going and what they might need to change?

The idea is that OKR works just like those Russian nested dolls, right? Where we have a larger doll with more dolls inside to have different cadences and cycles. So the idea is you can have longer term OKR for the company, usually annual. Usually have annual okrs for the company, which are usually higher level things that take long to change. Things are more stable. Usually have quarterly OKRs for the teams and we usually track OKRs every week. That cadence of measuring every week. And you say okay, based on, we measure okrs, what worked, what didn't work. Let's go again. So if it's not working, you try something different, right? If that cupcake is not selling, you try a different cupcake and that's it. So which cupcakes have you tried last week? Oh, this, this and this. Okay, what are the next hypothesis? This, this and this. And let's try it again then. It's not that feature Factory just putting something in the conveyor belt, disable line and say bye bye feature. Never seen that again. What's the version of the feature that we kept? Not let's do another one then. Another one, another one. And maybe that's not even the right feature, maybe it's something else. So that idea of learning is crucial.

Do you have an opinion on whether people should use team based or individual okrs or both?

Yeah, sure. It's usually both because. Let me rephrase that. It's usually. It depends on how the team is structured. But the idea is OKR is how you keep score, how you know that you're winning. So it's the scoreboard of the game. And some people play individual sports where each person has a individual scoreboard and some people play team sports. So if you're working on a team, like a cross functional team or agile team or a squad, you have a whole team of people working together to achieve the same outcome. So together we're going to achieve that okr. So you don't want to have like the designer with one okr, one of the engineers, the second one and third one going different directions because we all wouldn't work as a team, the same thing. On the other hand, you have functions like maybe sales or recruiting. Think about a recruiter. Recruiter usually works alone. I have my positions I'm filling, I'm hiring people, etc. So I can have my own OKR. Another example, let's imagine we are. If you go back to go back to team of teams, you don't have an actual team, right? Lots of individuals that report to the same person. So imagine we are part of the social media team, but actually you take care. You handle Facebook, I handle Twitter and Instagram. You can have your okr, I can have mine. So the idea is you use a team level, a team okr. When you have a team structure and you use individual cares. When you have basically individuals that work mostly together. That's basically. So usually if you have a team like an agile team, a product team or spread, usually stop at the team level. So Spotify doesn't have digital cares anymore. Twitter, most of the lots of people at Google, the site of engineering side, they don't use digital cares anymore because they just don't make sense in that scenario. Right, Sam?