Podcast Ep. 78: Exploring OKRs with Felipe Castro

Episode Description:

In today’s episode of the Agile Coaches’ Corner podcast, Dan Neumann is excited to be joined by special guest Felipe Castro. Felipe is an expert on objectives and key results (OKRs). He is an OKR trainer, speaker and author who helps organizations transform how they use goals by adopting OKRs. He has even created his own OKR tool called the “OKR Cycle,” which is a simple method to avoid OKRs’ most common pitfalls.

As a master of all things OKR, Felipe Castro is here to speak about — you’ve guessed it — all things OKR. He discusses what OKRs are, important aspects you should consider, tips and advice, common mistakes, misunderstandings and pitfalls, and how to overcome challenges.

Key Takeaways:

What are OKRs?

Acronym for Objectives and Key Results
An agile approach to setting goals and creating alignment
OKRs are about the outcome you want to achieve
A framework for defining and tracking objectives and their outcomes
Focuses on outcome-based planning as opposed to tracking tasks and activities
Instead of giving the teams a feature to build, you are giving them a problem to solve or an opportunity to tackle

Important aspects of an OKR:

The objective should be memorable, compelling, motivating and inspiring
The “why” comes from leadership and the team figures out the “what” together
Asking “so what?” can help your team create better key results
Give your engineers autonomy to solve problems
Psychological safety is crucial for fostering an environment for high-performance teams

Felipe’s OKR tips and advice:

Start with targets that are regular goals (hard but achievable)
Don’t copy another company’s method around OKRs — adopting OKRs is a journey that will be different for every company
Adapt the principles of OKRs for your specific context
You need to unlearn, adapt and evolve — especially if you come from an agile background

Common OKR mistakes, misunderstandings and pitfalls:

Treating it as a glorified to-do list
Using OKRs as a copy of Jira (which doesn’t add any value)
Seeing the role of engineers as assisting only with the coding rather than problem-solving
That the sweet spot for achieving a target is 70% (which has zero science behind it)

Mentioned in this Episode

Felipe Castro’s Book Pick

Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]

Intro [00:03]: Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.

Dan Neumann [00:16]: Welcome to the Agile Coaches’ Corner. I’m Dan Neumann and today I’m excited to be joined by Felipe Castro who is an expert on objectives and key results. Spends a lot of time talking at conferences, delivering training, and is an author, so very excited to be exploring OKR with you today.

Felipe Castro [00:37]: Thanks Dan. Thanks for having me.

Dan Neumann [00:39]: I know I’ve learned a lot from uh, I’ve seen you deliver live presentations and then you have some, uh, really nice artifacts on your website, felipecastro.com and we’ll put a link to that in the show notes so people can get the spelling of that. Uh, and I was curious for folks who don’t have an inkling for what OKRs or objectives and key results are, could you maybe give them a little bit of a, a working definition on that?

Felipe Castro [01:07]: Yeah, definitely. Um, OKR or objective key results is an agile approach to setting goals. And creating alignment. It was created in Silicon Valley and used by several companies, including Google, Twitter, Airbnb, Dropbox. Several companies use, uh, objective key results. Uh, as the name implies, you have an objective, which is a qualitative description of what you want to achieve in a set of key results that actually measure if you’re succeeding, measure, if you’re actually being successful.

Dan Neumann [01:38]: I was watching one of the, one of the talks and he said, it’s like the objective ought to be memorable. Like you said, it’s, it’s qualitative. It’s something that it’s maybe a catchy tagline. It’s okay to use the word awesome in an objective.

Felipe Castro [01:52]: Well, yeah. Yeah. The, there’s a very useful way to think about it. Uh, Intel created the original concept behind OKR, uh, the seventies and eighties, and then it was, then Google took it and then improved it, et cetera. But the original concept was to create a good goal. You have to state there’s a, there’s a formula that they use, which is I will, and then you say, as measured by, so there’s two components, what you want to achieve, but also how are you going to measure it? So the crucial words are as measured by the idea is in the current more modern approach to OKR. They do try to create the, I will part it what you, what you make it more compelling, make it more motivating and inspiring. Because goals don’t have to be boring, right? So you can make, you can either write it in a very boring way, but it can make it a fun creative and it can use awesome words such as kickass, depends on your culture. You can actually write great sentences. There’s a classic example of objective from Google from 2008, uh, make the web as, as fast as flipping through a magazine. Right? That’s clear, right? We want to make the web fast. That’s, that’s inspiring. That’s something you can relate to that that’s memorable. Right. Made a lot of sense in 2008. Right? So that’s the, the, the, the idea of an objective, right? Uh, one that I worked, I was working with uh, engineering team and they created one which was party like it’s 99.99% of the time. So in starting off saying world-class have the ability for something very boring, they created the ad. This, that’s memorable. That’s interesting. The idea is that the objective should be clear first and easy to remember. But it doesn’t have to be creative. It doesn’t have to be like, that’s not the point. You can do that if you want, but it can be also simple something that describes a problem and that’s, that’s something that has to be clear. Memorable describes a problem, right? The, the key results are the answer to as measurable. How do you know it’s succeeding? How do you know what’s working right? How do you measure if you’re being successful? And the main thing people notice about OKR is that instead of planning for the whole year, you plan around quarters. So usually the natural cadence of OKR is quarterly planning. So you plan every quarter, right? You also can have a annual longer term OKRs for high level stuff, but usually the teams, depending on the quarter, you can customize that. But most teams start with quarterly planning and that’s really fits the agile approach. You learn from it to iterate during the quarter. So describing OKR in a tweet I would say, here’s a system that force you to sit down with your team every quarter and discuss how are we going to measure that will be successful. That’s it for session every quarter. Simple one. That’s it.

Dan Neumann [04:49]: And you were discussing, we were talking a little bit before this and exchanging some emails. It really focusing on outcome based planning. So objectives and key results is focusing on the outcomes and I think that would be as opposed to activities. So outcomes versus tracking tasks.

Felipe Castro [05:07]: Yeah. The, the idea is uh, OKR it’s just a means to change the way people work. It’s just a means of, it’s the forcing function to, to, to, uh, enable you to adopt new ways of working. Right. And the core of that is the concept of outcome-based planning. The idea is that we plan around the outcomes we want to achieve instead of the a series of activities of projects, features that may or may not work. Right? And the idea is that instead of giving the teams a feature to build, you give them a problem to solve. You give them an opportunity to tackle, right? So you don’t say builders, you say that’s the big problem, that’s what you’re talking about. Explain the context, explain the strategy and let the teams come out with, with, with ideas. Let them innovate. They can task several different ideas, run experiments and then figure out what actually works. What do we actually move the needle? So, uh, outcome based planning is the stepping stone for creating powerful, uh, small teams that can actually drive innovation and they are the heart of Silicon Valley success, right? So breaking those networks off small powerful teams and planning is crucial for that.

Dan Neumann [06:30]: I know war metaphors get overused, but the one that came to mind was, you know, seizing a Hill. Like the objective is to take the Hill, or like you said, with the search, the objective is to make search as fast as flipping through a magazine. You know, the how around that then is really up to the team or you know, whether it’s as they go for that objective. Is that, is that valid?

Felipe Castro [06:55]: Yeah, usually. Um, the, the, the way I like to describe it as, uh, the why comes from leadership, right? That’s the context. That’s what we’re trying to do. That’s how it fits into overall strategy. Right? And then together with the teams, they talk about the what, okay. Given that’s the context given that’s what we’re trying to achieve as an organization. Right? Uh, what your team can contribute to that and then you have a conversation. Okay. And as part of the conversation is what we’re going to measure as measured by as part of that. So the team can come up with a set of metrics, uh, and then presents to the leadership, and then there’s back and forth. And it does, what do you call it by the rational conversation.

Dan Neumann [07:37]: So it’s not a hand off. Yeah, I’m sorry. It’s not a handoff of here’s the objective. I don’t care how you get there. It’s, it’s a collaborative effort to build the how.

Felipe Castro [07:47]: Yeah. And, and, and, uh, the, the challenges, um, first of all, two, two to two challenges, right? One of the most common mistakes in, in OKR is to treat OKR is a glorified $2, right? It just lists all the deliverables because we’re used to thinking about activities, right? We used to think about that’s how we use to work. That’s how our brains are wired. And also most people never worked in a company where they have to think about outcomes before. Right? Um, so making a distinction between, Hey, what we want to achieve and how are we going to imagine we successful versus our ideas, activities that may or may not work. That’s crucial, right? Making this distinction, right? Where people are working in agile, there’s two techniques that you can use. First of all, if it fits in JIRA is not a good result, right? If something that is don’t copy things from JIRA, JIRA is, is important. Uh, very important for tracking deliverables. Striking activities, right? OKR is how you measure if those things are working, okay? So outcomes are, they relaunched the feature. If nobody’s using, who cares? Right? And there’s a great technique to help you. Very simple technique to help you create key results, which is a software test. Good, good results. They make difference. They add value for your company. Your employees are customers and they pass the, so what? Test. So imagine your team is, has you have 10 minutes to present your OKR to the board, right? That’s it. And you’re going down and say, Oh, my first key result is to deliver the new app. So what? I don’t want an app. I want people using it. I want to, I’ll do it. All my customers are using it. They like it. Is it helping any issues? Are we making money out of it? Does anybody use it? I don’t. So what? Right. Or you can say, I’m launching those new marketing programs. So what I don’t want on new marketing program, that’s not the goal. Right? So if you keep asking the so what question, it helps people create better, better, OKRs, uh, the first time you do it, it sounds very aggressive in your face attitude. But as you learn, you say, I’m actually helping people by asking this question, right? So very simple task to say, does it add value? Does it make sense? Is it, how do you imagine if it actually succeeding?

Dan Neumann [10:19]: Right? Yeah, I like that so what test, and again, before we clicked on record, we were talking about a Sprint review in Scrum. And sometimes let’s say we want, we develop an, I’ll put on my stereotypical developer hat sometimes wants to show a piece of code or show an activity or show a thing that they did. And I think that’s, so what test also applies there. So why did we invest time doing the activity to build the thing? Like what’s, what’s important about that to the overall objectives that team is trying to achieve.

Felipe Castro [10:52]: Yeah, so lots of lots on back in there. First of all.

Dan Neumann [10:56]: And if it’s too much of a rat hole, we can come back to the mistakes.

Felipe Castro [11:01]: But first of all, the main idea of outcome-based planning is that we instead of giving teams feature to build, give them promise to solve, right? So it’s not about, Hey, stakeholder, what do you want? whatever you want instead actually, Hey, that’s the problem. Now go ahead and right to solve it.

Dan Neumann [11:22]: So a problem that I encountered at one place was they had an abandonment rate in there. They were selling insurance through a website and one of their problems was a huge abandonment rate as people would go through this funnel. And so that’s the problem then that they were asked to solve, okay.

Felipe Castro [11:38]: Yup, they gave me this feature. Right? So the idea is, especially with dealing with technology, the best ideas often come from people who have had that technology. Engineers are often the best of the best ideas on how to solve what technology just enables us. Uh, designers can come up with a usability issue that’s out for programmers. So give them problems to solve, right? And there’s a big shift away from the way, uh, uh, agile frameworks stand to, to work, right? So if you think about the classic book from subtler twice to work and half the time, that’s an efficiency mastery that doesn’t pass the Sol test, right? So, uh, okay. I delivered twice the work and half the time, but nobody used it. Nobody bought it. Maybe you didn’t make any money. Our customers are not happy about it. There’s no value in it. So what? So instead of doing that, I want twice the outcomes, right? So we need to, to, one of the things that is sometimes hard for, for people who are in agile is that when you’re trying to learn some concepts, I do agile is crucial agile are very important. But, uh, to take a next step, we need to move closer to, Hey, what are you trying to achieve? Uh, uh, real autonomous teams, self organized team. A full turnout focuses on outcomes, right? Is that about telling you what to do? Right? Is that about, Hey, stakeholder, what do you want? And I’ll go out and do that and deliver for you. Right. Um, and, and the challenges and uh, sometimes people, people who are very, let’s say dogmatic about agile, they have a problem with it. Is that the manifesto is a historical document you described how peopl work in 2001. It was never meant to be a, that’s a religious document you can change, can evolve because it goes against the very idea of agile, which is to learn and improve. Right? So if you go to the manifesto, the manifesto is exactly what? Because the seventh principle States, the primary measure progress is working software, which is a very output based activity based view of the world. Uh, so if she puts a software, there’s working that has zero bugs, zero value, cause it doesn’t solve the customer problem, nobody’s using it. They don’t like it. So, so what? Right. So uh, in agile we talk a lot about value, but there’s a an evolution on how we perceive value, right? If you believe, if you look historically what before agile, the proxy for value was, are we following the plan, right?

Dan Neumann [14:33]: Oh man, I waterfall project managed and yeah, boy where we did we have the right estimates where our actuals tracking to the estimates, Oh yeah, you were on that schedule. You are a rockstar PM.

Felipe Castro [14:44]: That’s the proxy for value, right? In waterfall, right? Are you following the plan? That’s it. Then comes out and says, no, the plan is a terrible proxy for value. Don’t do that. Things change, embrace uncertainty and they say the proxy for value is working software. The proxy for value is regularly showing working software for your stakeholders and getting their opinion, okay, that’s the proxy for value that had in 2001 right. They had the idea of the voice of the customer because a developer can never talk to it to a customer. Oh my God, that’s impossible. Right? So you have to have the voice of the customer, right? Somebody telling you what you do almost 20 years later, that doesn’t represent how high performance teams work anymore. Right. Because the opinion of the stakeholder is just that their opinion, right? And we need to move away from the hippo model, which is highest paid person’s opinion, right? People. Right? And instead of asking for stakeholders of your opinion, we actually show to real customers, put them in their hands and get them to use it, right? Real users, right? So you make decisions based on real evidence and not of the opinions of the stakeholder. So sometimes when I explain outcome-based planning for teams like no be focused on value, no you don’t. You focus on get the proxy users is really bad. You focus on getting your opinion of the stakeholder. I want you to move away from it. And I want you to measure better leading indicators for value. Do a prototype. Do your tasks to show actual product to actual users, right? And those are the lead indicators of future business impact that we can deliver, right? So in the age of 2020, we don’t need somebody to be the voice of the customer anymore. People can run experiments, they can interview customers. Can do user research? Right? So in that approach, uh, some of the agile frameworks and the language that we use no longer represent how high performance teams work in your training.

Dan Neumann [17:08]: That’s, that’s a good set of examples and I think that all kind of fits under that. Um, the mistake of treating OKRs as a glorified to do list, it’s really shifting away from whether your to do list is user stories or tasks or whatever the case might be. Shifting to really a focus on outcomes.

Felipe Castro [17:24]: Definitely. And um, first of all, using OKRs to track activities is a huge race of time. Lots of people are starting to use OKR and they get burned by it or it’s not working, et cetera, are just using it as a copy of JIRA. Sorry, putting the same information in two places. It doesn’t add value. Right. And by the way, it’s very common for engineers to say, I don’t see the value in OKR because they see the same information in two places. And I say, why do I need this new thing if I have JIRA or whatever I’m using, I have my backlog, I have my roadmap. Right. So the idea is an OKR is about the outcomes you want to achieve. JIRA, your backlog is different ideas so you can task them quickly, iterate and find that works.

Dan Neumann [18:13]: Yeah. Put your experiments in there. Yeah. I think you’ve said there were two mistakes. So one of them was a glorified to do list treating. Okay. Ours is a glorified to do list.

Felipe Castro [18:22]: Yeah. And there’s, there’s several, uh, fake news around or, or bad advice out there around, around, uh, uh, but when you move away from that idea of, Oh, okay, it’s not a to do list. I need to shift from level where again, I give teams problems to solve and it’s very common when I work with, with companies. Yeah. They embrace the outcome. Yeah. It makes sense. You should do that. Yeah. We need to measure if he’s a working day, embrace it. But they still see the role of engineers as, yeah. They assist to call. That’s what they do.

Dan Neumann [19:02]: They kinda like to solve problems. That’s what gets them excited.

Felipe Castro [19:04]: That’s why you become an engineer? Because you solve problems. So instead of just telling them a technical problem, give them the whole problem, get their opinion, and they’ll find you ways to use technology to solve a customer problem with business problems or whatever. That’s the whole idea of a technical business, right? So even tech leaders sometimes flip forward to that model where, no, my, my job is technical, right? Uh, and Marty Cagan, who is the de referencing back product management, that default leader usually says that if you’re using your engineers to code, you’re getting half their value, right? Only using engineers to code, you’re getting half the value. I strongly recommend reading Mark Marty’s book, Marty’s work you can go to as cpg.com the website, he just posted a, uh, an article saying that the things that, the most important stuff is to have empowered engineers introduced that can actually focus on the solutions, discuss the problems, and not only build features, right? So that’s something that even people in agile struggle with because the old model, people are so used to it that they’ve found a hard time thinking about, yeah, we can actually tell them, let them use their talent. Right.

Dan Neumann [20:26]: Yeah. You know, I think back to um, Oh, the skunkworks project that led to like the stealth fighters, I can’t imagine that somebody was telling the engineers exactly how they were going to build it. They’re like, you know, what we need is a jet that doesn’t show up on the radar. You go figure it out.

Felipe Castro [20:41]: Definitely. And again, this idea of our autonomy is not new by any chance throughout history. Several groups that working, they always come down to the same model. Autonomous teams, folks on emission. You talked about military, right? There’s a concept of mission command, which is very similar. Describe the context you’d have a problem to solve. That’s it. Uh, this goes down all the way to the Prussian army. 19th century goes all the way back to, uh, innovation labs in the forties and fifties. So Indian is about giving them the autonomy to solve problems, right? Not to do the work, right. Trust them, but it’s not about letting them do whatever they want. Right. You are accountable for the results. They should be it. You need to act. And when you say accountable, I’m saying in a positive accountability, right? I own this. I’m contracted to it. I’m not talking about necessarily about punishment, but Hey, you have to own this fan. You have to hear about it. That’s a clean, accountable, in a positive way.

Dan Neumann [21:48]: Yeah. Accountability. I for the longest time, and even a lot of times now, I still hear it. It’s a euphemism for being able to fire somebody if they screw up. And that’s just such an unfortunate thing. And then at one point I heard somebody say, accountability really means give an accounting for. So give an accounting for why you made those decisions. You know, was it reasoned, et cetera. It’s not you get fired if you screw up, but it’s being able to explain why you went this way, the decisions you made and how they were hopefully in this case, in search of an outcome that was planned.

Felipe Castro [22:21]: Yeah, definitely. Uh, when you say accountability is not about punishment, right? But about Hey, do I care about it? Do I own this result? Yeah, we did this. We tried it didn’t work, but I care about it. I own it. I’m trying to work on it versus I don’t really care, right? I’m not doing anything right. So it’s being accountable in a positive way. It’s not about punishment. Uh, one of the things you have to have the, the, there are some enabling factors to, to work with uh, outcome-based planning, right? Uh, and one of them is psychological safety, which is a concept was developed by a professor from Halvar, Amy and Melissa. And then after several years, Google did a study and found Hey, that’s the main factor that distinguishes high performance teams from the rest. So psychological safety is an environment. People feel safe to give ideas, express talk, right? And yeah, this is a crazy idea. Let me talk about it or talk about a problem we’re having. So that level, psychological, safe to sharing and expressing ideas is crucial to making the alphabet spending work. And definitely if you have an environment where everybody is afraid of punishment, psychological safety, the first thing that goes up goes away.

Dan Neumann [23:39]: Yeah. So when the, when there’s a lack of psychological safety, it’s an inability to bring forward new ideas, ideas that might be ridiculed or aren’t kind of safe ideas to offer.

Felipe Castro [23:50]: Yeah, exactly. Exactly. So, uh, the thing is, um, if you think about the concept of goals, goals, they have a very bad rap in companies today, right? You say goals, people think about, Oh gosh, that thing I have to do once a year, did it punish me? And then I don’t know what to add to that. That changes. There’s a forum. So they have a very bad rap. Right? Um, it’s very common probably, but OKRs are not goals. I just say, sorry. OKRs are within the general category of goals. They’re just not your standard corporate ways of doing goals. Right. So, first of all, goals work. We have 50 years of scientific research that when properly used goals, improve performance, right? So, but OKRs are not the traditional way of setting goals. So we have to change, uh, one very obvious thing you would need to change is if you want people to work in teams, how can we do, if I’m rating them as individuals, that doesn’t, that doesn’t make sense, right? So there’s a great quote from Dr. Mark when he says, we want you to, to try to innovate, uh, and work as a team. Why working, uh, for individual goals that you have to do that you can’t miss?

Dan Neumann [25:06]: Yes. Yeah, it’s a total disconnect. And then reward systems, financial reward systems get tied to the goals that you can’t miss. And it’s a wonder why people get dysfunctional at times about those. And one of the differences with objectives and key results, as I understand it, is these are more, um, they’re very aspirational. They’re stretched, they’re, they’re, um, like I said, qualitative reaches. And so you’re not expected to hit a hundred percent of your objectives and all the key results. Does that help? Fix what I said. Yeah.

Felipe Castro [25:37]: Yeah. That’s another misconception, right? Um, one of the things around OKR is that OKR was crowdsourced, right? It was not created by a consultant or a, an academic, right. Was treated by practitioners. People who were doing their job, like she overcompensated or engineer or whatever, and they improved over time. So there are several different versions of it. So, and on one end it’s good because it’s highly customizable. On the other end, it’s very confusing because people give you very different. Right. Okay. One of the common misconceptions around OKR is that every single OKR has to be aspirational. The idea is you have to shoot for the moon. And if you go online is every single key result. The idea is that you should reach it. The sweet spot for achieving a target is 70% right? And that’s the myth, right? So let me break it down. First of all, that 70% there’s zero signs around it, zero. That’s completely made up, right? The zero side, around 50% 80% or a hundred percent it’s all completely made up. Zero signs around it. That’s just a rule of thumb. The Google faded and that’s it. Right. And maybe you, and by the way, if you go to, uh, say Google ax, which is where we create the, uh, autonomous cars, et cetera, they have to work with 20% because it’s way more ambitious than the regular product.

Dan Neumann [27:14]: Okay. So a much lower, much lower expectation,

Felipe Castro [27:17]: Different approaches. Right. Okay. So don’t one size fits all. You can also have a OKR. There are similar to regular goals were, Hey, yeah, we expect that you’ve a hundred around a hundred percent. Right. Some of those seeds are aspirational because they’re unpredictable. Some of those things would be more regular. Yeah. We expect that you have this. So when you’re working with more regular, uh, results, those are for keeping the trains running on time. Yeah. Yeah. This is like, I need this number to be more predictable when I’m working with innovation where I’m trying really hard things. Yeah. You can try more aspirational stuff. Right.

Dan Neumann [27:58]: Okay. So kind of kind of connecting it to the, uh, from a, uh, there’s a framework, the three horizons, and I think I’d seen this reference. So, so for the, for the horizon one stuff that your bread and butter, what you’re doing all the time, you would expect a, the trains should arrive on time. We should be very good at that. And if we’re shooting for the moon or Google X, then maybe a lower attainment rate of OKR.

Felipe Castro [28:20]: Um, that’s one way to think about it. But it can also have things that you’re doing that should achieve results. This is an experiment I new idea we never tried to before, right? So it can be still things that you, uh, which we called horizon one, like improving the existing business, but we just relational cause we never did it before. Right? So it’s more around uh, predictability then, uh, if it’s disruptive or not. Right. And, uh, every single company I’ve worked with and I’ve worked with thousands and thousands of people over the last six years, I always recommend start with things that are predictive. Start with, uh, targets that are like regular goals. Start with things that are hard but achievable. You spec to achieve around a hundred percent of that, but there’s much easier adoption. Okay. Is a journey many people present. Okay. That’s a big bang goal. It doesn’t exist. And especially people coming from agile. I hope people come in from agile. Understand that it’s a journey. You don’t take it and adopt it exactly as this. You don’t copy Google cause you’re not Google. And by the way, there’s a great quote from uh, my friend, don’t copy Google. Not even Google copies Google because Google works in several different ways, right? So don’t do that. So it’s a journey. Improve over time. Baby steps.

Dan Neumann [29:47]: Yeah, it’s um, I wonder if the urge to copy Google is, is much like the urge, you know, to copy IBM back in the day it was like nobody gets fired for selecting IBM as the vendor. You know, nobody gets fired for trying to copy IBM or GEs model of, you know, you stack rank people and you chop the bottom off. Like, cause if GE was doing it, it must be okay. It just, the mimicry urge I think is pretty strong for, and maybe it’s related to psychological safety.

Felipe Castro [30:17]: That’s funny. That’s related to psychological safety, right? The analogy is perfect, right? Nobody was fired. Hope to buy IBM because if I follow something to the book, right, I’m telling the book, you can always blame the book, right? Hey, I’ll just follow Google. You can always bet the book, but often what’s happening is you didn’t customize your context. Right? So the very same thing to have agile, we have it, we have OKR, right? Yeah. Uh, so that’s the challenge. You need to understand the principles and customize to your reality. And yes, there are some techniques on how to apply those principles in practice, but it’s always customizable. It’s always about what’s working for you. The different techniques you work for different contexts.

Dan Neumann [31:07]: Yeah. So you were saying, um, one of the maybe advantages and anchors that agile has is there is an agile manifesto. There’s the values, there’s the 12 principles, you know, right or wrong. They, you know, they get referenced, et cetera. And then OKR have emerged kind of a crowdsourced practitioners. There isn’t a Canon of OKRs what would you point somebody to when around the principles of OKR. So if they’re trying to take the principles and adapt them for their context instead of copying a Google or somebody else, what, what would be a good resource for folks to kind of start learning?

Felipe Castro [31:44]: Yeah, one of the challenges of, of, OKR right Um, is that the main reference, uh, we have today or most people have, is a book called measure what matters. Uh, written by John Doerr. John Doerr is the, the most successful venture capitalist of all time. He worked at Intel where he learned okay. Or, and then he introduced to Google and several other companies, right? Doerr was an early investor, both Google and Amazon, right? So he’s an amazing investor. He’s called the Michael Jordan of venture capitals, and he has a book in Oakey, Oregon. Measure what matters. Uh, the thing is, the theory and the stories on the book are amazing, really, really good. But the examples are terrible, right? The examples reading that the book down, which is, uh, when the book was largely two years ago was, Oh gosh, and uh, I really wished I could, we’ll do a second edition we do as examples. So the book has some very good examples from Google and YouTube, but some really bad ones. Right? So that’s confusing for people. Okay. So that’s another challenge of OKR and that’s why I started talking about outcome based planning, right? Because as a principal, if you understand the principle that we plan around what you want to achieve, we give the teams the autonomy on how to do to achieve those, those, those outcomes, right? We plan around it, we organize around that, we track those. Um, that’s much easier for people to grasp. Okay. That’s a good idea. That’s not right. Because again, uh, OKR is just a means to an ad, right? Is how to apply those outcome-based principles in practice. Now being saying for awhile now if tomorrow there’s a better tool for doing that. There’s no better tool for implementing an OKR. All right. Okay. Some people have been burned by the brand for some people catch completely new, which is good. Some people tried OKR in the past. Yeah, that didn’t work. There’s like saying, Oh we tried to Azure, that doesn’t work.

Dan Neumann [33:58]: I hear that a lot from. I do hear that a fair amount. Yeah.

Felipe Castro [34:01]: Yeah. And I say I actually know quite a few companies, they use agile were successful. So maybe you should talk to them.

Dan Neumann [34:08]: Yeah. And I like to follow that up with, so what, when you say agile, what, what does that mean? What did you do that was called agile because um, I’ve heard some people describe things that, um, and again, you know, so the principles are historic, but you look at what they’re doing and it’s like, well, okay, so you ignored technical excellence and it bit you in the butt. That’s not a big surprise. Oh, you didn’t actually talk to your customer. That’s a problem. And not something I would consider agile. And so you get a chance to explain. So when somebody says, OKRs didn’t work for me. Well, great. Well what, what did they look like? How did you use them? You know, how are they rolled out?

Felipe Castro [34:44]: Yeah and even if you take something like Scrum has the guide right, is constantly updated. So there’s a reference, right? You can ask them, right? Even if it’s like Scrum people, people do they do crazy stuff with that. Imagine. Okay. Which crowd source, we’ve only had the problems way bigger, right? So people do crazy stuff,

Dan Neumann [35:08]: I love it. And you’ve got a beginner’s guide to Scrum on your website, so we’ll point, geez man, we’ll leave that blooper in there. But yes, you have a beginner’s guide to OKRs on your website and I found that to be a really handy reference to, it’s just a real concise PDF.

Felipe Castro [35:25]: Yeah. I have a beginner’s guide to OKR. I have a post on, on agile and OKR, I have several webinars for that. I mean, examples, several twos. There’s lots and lots of material here, but we can’t afford people coming from agile. I’ve learned that the very first most important thing is understanding that you need to unlearn some things, right? We need to evolve, we need to look for that. So that’s also looking at, Hey, this is a historical document. Huge contribution, very important that just tweak it. Right. Cause some of those things that don’t make sense anymore and I’ll say the whole thing doesn’t make sense anymore. Right.

Dan Neumann [36:07]: Okay. Understood. Kind of revisit some of it. I love it. Time has flown from my perspective, hopefully from yours and from, uh, from our listeners as well. One of the questions a lot of times we ask folks at the end is, you know, what are you, what are you reading or what’s got you excited from a continuous learning journey? And I also understand you’re working on a book that, um, you know, we’ll be coming out in the future. I don’t know if we, could you elaborate on either of those? Good. What are you learning about these days? And then maybe a little bit about your, uh, to be coming out book at some point.

Felipe Castro [36:39]: Yeah. Um, I’m writing a book on outcome based pain in OKR. The factors aligned how to use outcome-based pain in OKR to drive a business impact. And it’s about how to use that in practice. What are the principles and the techniques to use it in practice? Cause I’ve learned you have to do both the principles and to put it in practice. When I’ve read books that I recommend, uh, when you start working on outcome based planning, one of the things people really struggle with is, okay, now I don’t have a future. How do I choose which feature, how to run experiments, how they test my ideas quickly. So how to test ideas with how to run experiments. That’s a major gap that most people have and that’s a key enabler of outcome-based planning. So we have two books, uh, that came recently around around uh, experiments. The first one is testing business ideas again, testing business ideas by David Bam, right. The second one is by Ron Kohavi trustworthy online experiments. Ron Kohavi used to run the experiments back for when Amazon did. He did that for Microsoft and now he’s at Airbnb. So he kind of know how to run experiments on a couple of things. Yeah, David’s book is very practical guide. Several examples of experiments and when to use each one. We recommend if you want to move documents, planning, running, how to do experiments is crucial.

Dan Neumann [38:09]: So testing business ideas and trustworthy online experiments.

Felipe Castro [38:14]: Exactly.

Dan Neumann [38:15]: Okay, wonderful. Well, I, I’ll go read those. I have not read either of them. I’ve seen stuff and consume things from bland in the past and it’s been good and I’ll look forward to picking up some new things.

Felipe Castro [38:25]: Fantastic.

Dan Neumann [38:26]: Wonderful Philippe. Well, thank you very much for taking some time to share outcome-based, um, outcome based planning with us.

Felipe Castro [38:34]: Thanks for having me.

Outro [38:36]: This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions, and information expressed in this podcast are solely those of the hosts and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.

Speakers

Dan Neumann

Principal Enterprise Coach

Dan Neuman is the Director of the US Transformation and Coaching practice in the Agility guild. He coaches organizations to transform the way they work to achieve their desired business outcomes.

With more than 25 years of experience, Dan Neumann is an experienced Agile Coach with a deep knowledge of Agility at the team and organizational levels. He focuses on achieving business outcomes by shifting both mindset and practices, resulting in a disciplined, yet practical approach to solving problems.

Managed Services

Nowadays, Information Technology (IT) has become, along with people, the spine of the operations of almost every organization. No matter the business you are running, technology is now what supports the entire company operation.When technology started being an important component of organizations, it was somehow limited to some computers running accounting software and any other tool specific to the business. Companies used to hire “IT guys” with enough knowledge to fix PC issues and skills to learn about a couple of applications to assist the end users whenever necessary. The IT department was, in many cases, a small team of two or three guys who used to report to the general manager or any other manager who could or not have IT knowledge.

7 min read

August 16, 2022

Podcast Ep. 78: Exploring OKRs with Felipe Castro

Intro [00:03]:

Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.

Dan Neumann [00:16]:

Welcome to the Agile Coaches’ Corner. I’m Dan Neumann and today I’m excited to be joined by Felipe Castro who is an expert on objectives and key results. Spends a lot of time talking at conferences, delivering training, and is an author, so very excited to be exploring OKR with you today.

Felipe Castro [00:37]:

Thanks Dan. Thanks for having me.

Dan Neumann [00:39]:

I know I’ve learned a lot from uh, I’ve seen you deliver live presentations and then you have some, uh, really nice artifacts on your website, felipecastro.com and we’ll put a link to that in the show notes so people can get the spelling of that. Uh, and I was curious for folks who don’t have an inkling for what OKRs or objectives and key results are, could you maybe give them a little bit of a, a working definition on that?

Felipe Castro [01:07]:

Yeah, definitely. Um, OKR or objective key results is an agile approach to setting goals. And creating alignment. It was created in Silicon Valley and used by several companies, including Google, Twitter, Airbnb, Dropbox. Several companies use, uh, objective key results. Uh, as the name implies, you have an objective, which is a qualitative description of what you want to achieve in a set of key results that actually measure if you’re succeeding, measure, if you’re actually being successful.

Dan Neumann [01:38]:

I was watching one of the, one of the talks and he said, it’s like the objective ought to be memorable. Like you said, it’s, it’s qualitative. It’s something that it’s maybe a catchy tagline. It’s okay to use the word awesome in an objective.

Felipe Castro [01:52]:

Well, yeah. Yeah. The, there’s a very useful way to think about it. Uh, Intel created the original concept behind OKR, uh, the seventies and eighties, and then it was, then Google took it and then improved it, et cetera. But the original concept was to create a good goal. You have to state there’s a, there’s a formula that they use, which is I will, and then you say, as measured by, so there’s two components, what you want to achieve, but also how are you going to measure it? So the crucial words are as measured by the idea is in the current more modern approach to OKR. They do try to create the, I will part it what you, what you make it more compelling, make it more motivating and inspiring. Because goals don’t have to be boring, right? So you can make, you can either write it in a very boring way, but it can make it a fun creative and it can use awesome words such as kickass, depends on your culture. You can actually write great sentences. There’s a classic example of objective from Google from 2008, uh, make the web as, as fast as flipping through a magazine. Right? That’s clear, right? We want to make the web fast. That’s, that’s inspiring. That’s something you can relate to that that’s memorable. Right. Made a lot of sense in 2008. Right? So that’s the, the, the, the idea of an objective, right? Uh, one that I worked, I was working with uh, engineering team and they created one which was party like it’s 99.99% of the time. So in starting off saying world-class have the ability for something very boring, they created the ad. This, that’s memorable. That’s interesting. The idea is that the objective should be clear first and easy to remember. But it doesn’t have to be creative. It doesn’t have to be like, that’s not the point. You can do that if you want, but it can be also simple something that describes a problem and that’s, that’s something that has to be clear. Memorable describes a problem, right? The, the key results are the answer to as measurable. How do you know it’s succeeding? How do you know what’s working right? How do you measure if you’re being successful? And the main thing people notice about OKR is that instead of planning for the whole year, you plan around quarters. So usually the natural cadence of OKR is quarterly planning. So you plan every quarter, right? You also can have a annual longer term OKRs for high level stuff, but usually the teams, depending on the quarter, you can customize that. But most teams start with quarterly planning and that’s really fits the agile approach. You learn from it to iterate during the quarter. So describing OKR in a tweet I would say, here’s a system that force you to sit down with your team every quarter and discuss how are we going to measure that will be successful. That’s it for session every quarter. Simple one. That’s it.

Dan Neumann [04:49]:

And you were discussing, we were talking a little bit before this and exchanging some emails. It really focusing on outcome based planning. So objectives and key results is focusing on the outcomes and I think that would be as opposed to activities. So outcomes versus tracking tasks.

Felipe Castro [05:07]:

Yeah. The, the idea is uh, OKR it’s just a means to change the way people work. It’s just a means of, it’s the forcing function to, to, to, uh, enable you to adopt new ways of working. Right. And the core of that is the concept of outcome-based planning. The idea is that we plan around the outcomes we want to achieve instead of the a series of activities of projects, features that may or may not work. Right? And the idea is that instead of giving the teams a feature to build, you give them a problem to solve. You give them an opportunity to tackle, right? So you don’t say builders, you say that’s the big problem, that’s what you’re talking about. Explain the context, explain the strategy and let the teams come out with, with, with ideas. Let them innovate. They can task several different ideas, run experiments and then figure out what actually works. What do we actually move the needle? So, uh, outcome based planning is the stepping stone for creating powerful, uh, small teams that can actually drive innovation and they are the heart of Silicon Valley success, right? So breaking those networks off small powerful teams and planning is crucial for that.

Dan Neumann [06:30]:

I know war metaphors get overused, but the one that came to mind was, you know, seizing a Hill. Like the objective is to take the Hill, or like you said, with the search, the objective is to make search as fast as flipping through a magazine. You know, the how around that then is really up to the team or you know, whether it’s as they go for that objective. Is that, is that valid?

Felipe Castro [06:55]:

Yeah, usually. Um, the, the, the way I like to describe it as, uh, the why comes from leadership, right? That’s the context. That’s what we’re trying to do. That’s how it fits into overall strategy. Right? And then together with the teams, they talk about the what, okay. Given that’s the context given that’s what we’re trying to achieve as an organization. Right? Uh, what your team can contribute to that and then you have a conversation. Okay. And as part of the conversation is what we’re going to measure as measured by as part of that. So the team can come up with a set of metrics, uh, and then presents to the leadership, and then there’s back and forth. And it does, what do you call it by the rational conversation.

Dan Neumann [07:37]:

So it’s not a hand off. Yeah, I’m sorry. It’s not a handoff of here’s the objective. I don’t care how you get there. It’s, it’s a collaborative effort to build the how.

Felipe Castro [07:47]:

Yeah. And, and, and, uh, the, the challenges, um, first of all, two, two to two challenges, right? One of the most common mistakes in, in OKR is to treat OKR is a glorified $2, right? It just lists all the deliverables because we’re used to thinking about activities, right? We used to think about that’s how we use to work. That’s how our brains are wired. And also most people never worked in a company where they have to think about outcomes before. Right? Um, so making a distinction between, Hey, what we want to achieve and how are we going to imagine we successful versus our ideas, activities that may or may not work. That’s crucial, right? Making this distinction, right? Where people are working in agile, there’s two techniques that you can use. First of all, if it fits in JIRA is not a good result, right? If something that is don’t copy things from JIRA, JIRA is, is important. Uh, very important for tracking deliverables. Striking activities, right? OKR is how you measure if those things are working, okay? So outcomes are, they relaunched the feature. If nobody’s using, who cares? Right? And there’s a great technique to help you. Very simple technique to help you create key results, which is a software test. Good, good results. They make difference. They add value for your company. Your employees are customers and they pass the, so what? Test. So imagine your team is, has you have 10 minutes to present your OKR to the board, right? That’s it. And you’re going down and say, Oh, my first key result is to deliver the new app. So what? I don’t want an app. I want people using it. I want to, I’ll do it. All my customers are using it. They like it. Is it helping any issues? Are we making money out of it? Does anybody use it? I don’t. So what? Right. Or you can say, I’m launching those new marketing programs. So what I don’t want on new marketing program, that’s not the goal. Right? So if you keep asking the so what question, it helps people create better, better, OKRs, uh, the first time you do it, it sounds very aggressive in your face attitude. But as you learn, you say, I’m actually helping people by asking this question, right? So very simple task to say, does it add value? Does it make sense? Is it, how do you imagine if it actually succeeding?

Dan Neumann [10:19]:

Right? Yeah, I like that so what test, and again, before we clicked on record, we were talking about a Sprint review in Scrum. And sometimes let’s say we want, we develop an, I’ll put on my stereotypical developer hat sometimes wants to show a piece of code or show an activity or show a thing that they did. And I think that’s, so what test also applies there. So why did we invest time doing the activity to build the thing? Like what’s, what’s important about that to the overall objectives that team is trying to achieve.

Felipe Castro [10:52]:

Yeah, so lots of lots on back in there. First of all.

Dan Neumann [10:56]:

And if it’s too much of a rat hole, we can come back to the mistakes.

Felipe Castro [11:01]:

But first of all, the main idea of outcome-based planning is that we instead of giving teams feature to build, give them promise to solve, right? So it’s not about, Hey, stakeholder, what do you want? whatever you want instead actually, Hey, that’s the problem. Now go ahead and right to solve it.

Dan Neumann [11:22]:

So a problem that I encountered at one place was they had an abandonment rate in there. They were selling insurance through a website and one of their problems was a huge abandonment rate as people would go through this funnel. And so that’s the problem then that they were asked to solve, okay.

Felipe Castro [11:38]:

Yup, they gave me this feature. Right? So the idea is, especially with dealing with technology, the best ideas often come from people who have had that technology. Engineers are often the best of the best ideas on how to solve what technology just enables us. Uh, designers can come up with a usability issue that’s out for programmers. So give them problems to solve, right? And there’s a big shift away from the way, uh, uh, agile frameworks stand to, to work, right? So if you think about the classic book from subtler twice to work and half the time, that’s an efficiency mastery that doesn’t pass the Sol test, right? So, uh, okay. I delivered twice the work and half the time, but nobody used it. Nobody bought it. Maybe you didn’t make any money. Our customers are not happy about it. There’s no value in it. So what? So instead of doing that, I want twice the outcomes, right? So we need to, to, one of the things that is sometimes hard for, for people who are in agile is that when you’re trying to learn some concepts, I do agile is crucial agile are very important. But, uh, to take a next step, we need to move closer to, Hey, what are you trying to achieve? Uh, uh, real autonomous teams, self organized team. A full turnout focuses on outcomes, right? Is that about telling you what to do? Right? Is that about, Hey, stakeholder, what do you want? And I’ll go out and do that and deliver for you. Right. Um, and, and the challenges and uh, sometimes people, people who are very, let’s say dogmatic about agile, they have a problem with it. Is that the manifesto is a historical document you described how peopl work in 2001. It was never meant to be a, that’s a religious document you can change, can evolve because it goes against the very idea of agile, which is to learn and improve. Right? So if you go to the manifesto, the manifesto is exactly what? Because the seventh principle States, the primary measure progress is working software, which is a very output based activity based view of the world. Uh, so if she puts a software, there’s working that has zero bugs, zero value, cause it doesn’t solve the customer problem, nobody’s using it. They don’t like it. So, so what? Right. So uh, in agile we talk a lot about value, but there’s a an evolution on how we perceive value, right? If you believe, if you look historically what before agile, the proxy for value was, are we following the plan, right?

Dan Neumann [14:33]:

Oh man, I waterfall project managed and yeah, boy where we did we have the right estimates where our actuals tracking to the estimates, Oh yeah, you were on that schedule. You are a rockstar PM.

Felipe Castro [14:44]:

That’s the proxy for value, right? In waterfall, right? Are you following the plan? That’s it. Then comes out and says, no, the plan is a terrible proxy for value. Don’t do that. Things change, embrace uncertainty and they say the proxy for value is working software. The proxy for value is regularly showing working software for your stakeholders and getting their opinion, okay, that’s the proxy for value that had in 2001 right. They had the idea of the voice of the customer because a developer can never talk to it to a customer. Oh my God, that’s impossible. Right? So you have to have the voice of the customer, right? Somebody telling you what you do almost 20 years later, that doesn’t represent how high performance teams work anymore. Right. Because the opinion of the stakeholder is just that their opinion, right? And we need to move away from the hippo model, which is highest paid person’s opinion, right? People. Right? And instead of asking for stakeholders of your opinion, we actually show to real customers, put them in their hands and get them to use it, right? Real users, right? So you make decisions based on real evidence and not of the opinions of the stakeholder. So sometimes when I explain outcome-based planning for teams like no be focused on value, no you don’t. You focus on get the proxy users is really bad. You focus on getting your opinion of the stakeholder. I want you to move away from it. And I want you to measure better leading indicators for value. Do a prototype. Do your tasks to show actual product to actual users, right? And those are the lead indicators of future business impact that we can deliver, right? So in the age of 2020, we don’t need somebody to be the voice of the customer anymore. People can run experiments, they can interview customers. Can do user research? Right? So in that approach, uh, some of the agile frameworks and the language that we use no longer represent how high performance teams work in your training.

Dan Neumann [17:08]:

That’s, that’s a good set of examples and I think that all kind of fits under that. Um, the mistake of treating OKRs as a glorified to do list, it’s really shifting away from whether your to do list is user stories or tasks or whatever the case might be. Shifting to really a focus on outcomes.

Felipe Castro [17:24]:

Definitely. And um, first of all, using OKRs to track activities is a huge race of time. Lots of people are starting to use OKR and they get burned by it or it’s not working, et cetera, are just using it as a copy of JIRA. Sorry, putting the same information in two places. It doesn’t add value. Right. And by the way, it’s very common for engineers to say, I don’t see the value in OKR because they see the same information in two places. And I say, why do I need this new thing if I have JIRA or whatever I’m using, I have my backlog, I have my roadmap. Right. So the idea is an OKR is about the outcomes you want to achieve. JIRA, your backlog is different ideas so you can task them quickly, iterate and find that works.

Dan Neumann [18:13]:

Yeah. Put your experiments in there. Yeah. I think you’ve said there were two mistakes. So one of them was a glorified to do list treating. Okay. Ours is a glorified to do list.

Felipe Castro [18:22]:

Yeah. And there’s, there’s several, uh, fake news around or, or bad advice out there around, around, uh, uh, but when you move away from that idea of, Oh, okay, it’s not a to do list. I need to shift from level where again, I give teams problems to solve and it’s very common when I work with, with companies. Yeah. They embrace the outcome. Yeah. It makes sense. You should do that. Yeah. We need to measure if he’s a working day, embrace it. But they still see the role of engineers as, yeah. They assist to call. That’s what they do.

Dan Neumann [19:02]:

They kinda like to solve problems. That’s what gets them excited.

Felipe Castro [19:04]:

That’s why you become an engineer? Because you solve problems. So instead of just telling them a technical problem, give them the whole problem, get their opinion, and they’ll find you ways to use technology to solve a customer problem with business problems or whatever. That’s the whole idea of a technical business, right? So even tech leaders sometimes flip forward to that model where, no, my, my job is technical, right? Uh, and Marty Cagan, who is the de referencing back product management, that default leader usually says that if you’re using your engineers to code, you’re getting half their value, right? Only using engineers to code, you’re getting half the value. I strongly recommend reading Mark Marty’s book, Marty’s work you can go to as cpg.com the website, he just posted a, uh, an article saying that the things that, the most important stuff is to have empowered engineers introduced that can actually focus on the solutions, discuss the problems, and not only build features, right? So that’s something that even people in agile struggle with because the old model, people are so used to it that they’ve found a hard time thinking about, yeah, we can actually tell them, let them use their talent. Right.

Dan Neumann [20:26]:

Yeah. You know, I think back to um, Oh, the skunkworks project that led to like the stealth fighters, I can’t imagine that somebody was telling the engineers exactly how they were going to build it. They’re like, you know, what we need is a jet that doesn’t show up on the radar. You go figure it out.

Felipe Castro [20:41]:

Definitely. And again, this idea of our autonomy is not new by any chance throughout history. Several groups that working, they always come down to the same model. Autonomous teams, folks on emission. You talked about military, right? There’s a concept of mission command, which is very similar. Describe the context you’d have a problem to solve. That’s it. Uh, this goes down all the way to the Prussian army. 19th century goes all the way back to, uh, innovation labs in the forties and fifties. So Indian is about giving them the autonomy to solve problems, right? Not to do the work, right. Trust them, but it’s not about letting them do whatever they want. Right. You are accountable for the results. They should be it. You need to act. And when you say accountable, I’m saying in a positive accountability, right? I own this. I’m contracted to it. I’m not talking about necessarily about punishment, but Hey, you have to own this fan. You have to hear about it. That’s a clean, accountable, in a positive way.

Dan Neumann [21:48]:

Yeah. Accountability. I for the longest time, and even a lot of times now, I still hear it. It’s a euphemism for being able to fire somebody if they screw up. And that’s just such an unfortunate thing. And then at one point I heard somebody say, accountability really means give an accounting for. So give an accounting for why you made those decisions. You know, was it reasoned, et cetera. It’s not you get fired if you screw up, but it’s being able to explain why you went this way, the decisions you made and how they were hopefully in this case, in search of an outcome that was planned.

Felipe Castro [22:21]:

Yeah, definitely. Uh, when you say accountability is not about punishment, right? But about Hey, do I care about it? Do I own this result? Yeah, we did this. We tried it didn’t work, but I care about it. I own it. I’m trying to work on it versus I don’t really care, right? I’m not doing anything right. So it’s being accountable in a positive way. It’s not about punishment. Uh, one of the things you have to have the, the, there are some enabling factors to, to work with uh, outcome-based planning, right? Uh, and one of them is psychological safety, which is a concept was developed by a professor from Halvar, Amy and Melissa. And then after several years, Google did a study and found Hey, that’s the main factor that distinguishes high performance teams from the rest. So psychological safety is an environment. People feel safe to give ideas, express talk, right? And yeah, this is a crazy idea. Let me talk about it or talk about a problem we’re having. So that level, psychological, safe to sharing and expressing ideas is crucial to making the alphabet spending work. And definitely if you have an environment where everybody is afraid of punishment, psychological safety, the first thing that goes up goes away.

Dan Neumann [23:39]:

Yeah. So when the, when there’s a lack of psychological safety, it’s an inability to bring forward new ideas, ideas that might be ridiculed or aren’t kind of safe ideas to offer.

Felipe Castro [23:50]:

Yeah, exactly. Exactly. So, uh, the thing is, um, if you think about the concept of goals, goals, they have a very bad rap in companies today, right? You say goals, people think about, Oh gosh, that thing I have to do once a year, did it punish me? And then I don’t know what to add to that. That changes. There’s a forum. So they have a very bad rap. Right? Um, it’s very common probably, but OKRs are not goals. I just say, sorry. OKRs are within the general category of goals. They’re just not your standard corporate ways of doing goals. Right. So, first of all, goals work. We have 50 years of scientific research that when properly used goals, improve performance, right? So, but OKRs are not the traditional way of setting goals. So we have to change, uh, one very obvious thing you would need to change is if you want people to work in teams, how can we do, if I’m rating them as individuals, that doesn’t, that doesn’t make sense, right? So there’s a great quote from Dr. Mark when he says, we want you to, to try to innovate, uh, and work as a team. Why working, uh, for individual goals that you have to do that you can’t miss?

Dan Neumann [25:06]:

Yes. Yeah, it’s a total disconnect. And then reward systems, financial reward systems get tied to the goals that you can’t miss. And it’s a wonder why people get dysfunctional at times about those. And one of the differences with objectives and key results, as I understand it, is these are more, um, they’re very aspirational. They’re stretched, they’re, they’re, um, like I said, qualitative reaches. And so you’re not expected to hit a hundred percent of your objectives and all the key results. Does that help? Fix what I said. Yeah.

Felipe Castro [25:37]:

Yeah. That’s another misconception, right? Um, one of the things around OKR is that OKR was crowdsourced, right? It was not created by a consultant or a, an academic, right. Was treated by practitioners. People who were doing their job, like she overcompensated or engineer or whatever, and they improved over time. So there are several different versions of it. So, and on one end it’s good because it’s highly customizable. On the other end, it’s very confusing because people give you very different. Right. Okay. One of the common misconceptions around OKR is that every single OKR has to be aspirational. The idea is you have to shoot for the moon. And if you go online is every single key result. The idea is that you should reach it. The sweet spot for achieving a target is 70% right? And that’s the myth, right? So let me break it down. First of all, that 70% there’s zero signs around it, zero. That’s completely made up, right? The zero side, around 50% 80% or a hundred percent it’s all completely made up. Zero signs around it. That’s just a rule of thumb. The Google faded and that’s it. Right. And maybe you, and by the way, if you go to, uh, say Google ax, which is where we create the, uh, autonomous cars, et cetera, they have to work with 20% because it’s way more ambitious than the regular product.

Dan Neumann [27:14]:

Okay. So a much lower, much lower expectation,

Felipe Castro [27:17]:

Different approaches. Right. Okay. So don’t one size fits all. You can also have a OKR. There are similar to regular goals were, Hey, yeah, we expect that you’ve a hundred around a hundred percent. Right. Some of those seeds are aspirational because they’re unpredictable. Some of those things would be more regular. Yeah. We expect that you have this. So when you’re working with more regular, uh, results, those are for keeping the trains running on time. Yeah. Yeah. This is like, I need this number to be more predictable when I’m working with innovation where I’m trying really hard things. Yeah. You can try more aspirational stuff. Right.

Dan Neumann [27:58]:

Okay. So kind of kind of connecting it to the, uh, from a, uh, there’s a framework, the three horizons, and I think I’d seen this reference. So, so for the, for the horizon one stuff that your bread and butter, what you’re doing all the time, you would expect a, the trains should arrive on time. We should be very good at that. And if we’re shooting for the moon or Google X, then maybe a lower attainment rate of OKR.

Felipe Castro [28:20]:

Um, that’s one way to think about it. But it can also have things that you’re doing that should achieve results. This is an experiment I new idea we never tried to before, right? So it can be still things that you, uh, which we called horizon one, like improving the existing business, but we just relational cause we never did it before. Right? So it’s more around uh, predictability then, uh, if it’s disruptive or not. Right. And, uh, every single company I’ve worked with and I’ve worked with thousands and thousands of people over the last six years, I always recommend start with things that are predictive. Start with, uh, targets that are like regular goals. Start with things that are hard but achievable. You spec to achieve around a hundred percent of that, but there’s much easier adoption. Okay. Is a journey many people present. Okay. That’s a big bang goal. It doesn’t exist. And especially people coming from agile. I hope people come in from agile. Understand that it’s a journey. You don’t take it and adopt it exactly as this. You don’t copy Google cause you’re not Google. And by the way, there’s a great quote from uh, my friend, don’t copy Google. Not even Google copies Google because Google works in several different ways, right? So don’t do that. So it’s a journey. Improve over time. Baby steps.

Dan Neumann [29:47]:

Yeah, it’s um, I wonder if the urge to copy Google is, is much like the urge, you know, to copy IBM back in the day it was like nobody gets fired for selecting IBM as the vendor. You know, nobody gets fired for trying to copy IBM or GEs model of, you know, you stack rank people and you chop the bottom off. Like, cause if GE was doing it, it must be okay. It just, the mimicry urge I think is pretty strong for, and maybe it’s related to psychological safety.

Felipe Castro [30:17]:

That’s funny. That’s related to psychological safety, right? The analogy is perfect, right? Nobody was fired. Hope to buy IBM because if I follow something to the book, right, I’m telling the book, you can always blame the book, right? Hey, I’ll just follow Google. You can always bet the book, but often what’s happening is you didn’t customize your context. Right? So the very same thing to have agile, we have it, we have OKR, right? Yeah. Uh, so that’s the challenge. You need to understand the principles and customize to your reality. And yes, there are some techniques on how to apply those principles in practice, but it’s always customizable. It’s always about what’s working for you. The different techniques you work for different contexts.

Dan Neumann [31:07]:

Yeah. So you were saying, um, one of the maybe advantages and anchors that agile has is there is an agile manifesto. There’s the values, there’s the 12 principles, you know, right or wrong. They, you know, they get referenced, et cetera. And then OKR have emerged kind of a crowdsourced practitioners. There isn’t a Canon of OKRs what would you point somebody to when around the principles of OKR. So if they’re trying to take the principles and adapt them for their context instead of copying a Google or somebody else, what, what would be a good resource for folks to kind of start learning?

Felipe Castro [31:44]:

Yeah, one of the challenges of, of, OKR right Um, is that the main reference, uh, we have today or most people have, is a book called measure what matters. Uh, written by John Doerr. John Doerr is the, the most successful venture capitalist of all time. He worked at Intel where he learned okay. Or, and then he introduced to Google and several other companies, right? Doerr was an early investor, both Google and Amazon, right? So he’s an amazing investor. He’s called the Michael Jordan of venture capitals, and he has a book in Oakey, Oregon. Measure what matters. Uh, the thing is, the theory and the stories on the book are amazing, really, really good. But the examples are terrible, right? The examples reading that the book down, which is, uh, when the book was largely two years ago was, Oh gosh, and uh, I really wished I could, we’ll do a second edition we do as examples. So the book has some very good examples from Google and YouTube, but some really bad ones. Right? So that’s confusing for people. Okay. So that’s another challenge of OKR and that’s why I started talking about outcome based planning, right? Because as a principal, if you understand the principle that we plan around what you want to achieve, we give the teams the autonomy on how to do to achieve those, those, those outcomes, right? We plan around it, we organize around that, we track those. Um, that’s much easier for people to grasp. Okay. That’s a good idea. That’s not right. Because again, uh, OKR is just a means to an ad, right? Is how to apply those outcome-based principles in practice. Now being saying for awhile now if tomorrow there’s a better tool for doing that. There’s no better tool for implementing an OKR. All right. Okay. Some people have been burned by the brand for some people catch completely new, which is good. Some people tried OKR in the past. Yeah, that didn’t work. There’s like saying, Oh we tried to Azure, that doesn’t work.

Dan Neumann [33:58]:

I hear that a lot from. I do hear that a fair amount. Yeah.

Felipe Castro [34:01]:

Yeah. And I say I actually know quite a few companies, they use agile were successful. So maybe you should talk to them.

Dan Neumann [34:08]:

Yeah. And I like to follow that up with, so what, when you say agile, what, what does that mean? What did you do that was called agile because um, I’ve heard some people describe things that, um, and again, you know, so the principles are historic, but you look at what they’re doing and it’s like, well, okay, so you ignored technical excellence and it bit you in the butt. That’s not a big surprise. Oh, you didn’t actually talk to your customer. That’s a problem. And not something I would consider agile. And so you get a chance to explain. So when somebody says, OKRs didn’t work for me. Well, great. Well what, what did they look like? How did you use them? You know, how are they rolled out?

Felipe Castro [34:44]:

Yeah and even if you take something like Scrum has the guide right, is constantly updated. So there’s a reference, right? You can ask them, right? Even if it’s like Scrum people, people do they do crazy stuff with that. Imagine. Okay. Which crowd source, we’ve only had the problems way bigger, right? So people do crazy stuff,

Dan Neumann [35:08]:

I love it. And you’ve got a beginner’s guide to Scrum on your website, so we’ll point, geez man, we’ll leave that blooper in there. But yes, you have a beginner’s guide to OKRs on your website and I found that to be a really handy reference to, it’s just a real concise PDF.

Felipe Castro [35:25]:

Yeah. I have a beginner’s guide to OKR. I have a post on, on agile and OKR, I have several webinars for that. I mean, examples, several twos. There’s lots and lots of material here, but we can’t afford people coming from agile. I’ve learned that the very first most important thing is understanding that you need to unlearn some things, right? We need to evolve, we need to look for that. So that’s also looking at, Hey, this is a historical document. Huge contribution, very important that just tweak it. Right. Cause some of those things that don’t make sense anymore and I’ll say the whole thing doesn’t make sense anymore. Right.

Dan Neumann [36:07]:

Okay. Understood. Kind of revisit some of it. I love it. Time has flown from my perspective, hopefully from yours and from, uh, from our listeners as well. One of the questions a lot of times we ask folks at the end is, you know, what are you, what are you reading or what’s got you excited from a continuous learning journey? And I also understand you’re working on a book that, um, you know, we’ll be coming out in the future. I don’t know if we, could you elaborate on either of those? Good. What are you learning about these days? And then maybe a little bit about your, uh, to be coming out book at some point.

Felipe Castro [36:39]:

Yeah. Um, I’m writing a book on outcome based pain in OKR. The factors aligned how to use outcome-based pain in OKR to drive a business impact. And it’s about how to use that in practice. What are the principles and the techniques to use it in practice? Cause I’ve learned you have to do both the principles and to put it in practice. When I’ve read books that I recommend, uh, when you start working on outcome based planning, one of the things people really struggle with is, okay, now I don’t have a future. How do I choose which feature, how to run experiments, how they test my ideas quickly. So how to test ideas with how to run experiments. That’s a major gap that most people have and that’s a key enabler of outcome-based planning. So we have two books, uh, that came recently around around uh, experiments. The first one is testing business ideas again, testing business ideas by David Bam, right. The second one is by Ron Kohavi trustworthy online experiments. Ron Kohavi used to run the experiments back for when Amazon did. He did that for Microsoft and now he’s at Airbnb. So he kind of know how to run experiments on a couple of things. Yeah, David’s book is very practical guide. Several examples of experiments and when to use each one. We recommend if you want to move documents, planning, running, how to do experiments is crucial.

Dan Neumann [38:09]:

So testing business ideas and trustworthy online experiments.

Felipe Castro [38:14]:

Exactly.

Dan Neumann [38:15]:

Okay, wonderful. Well, I, I’ll go read those. I have not read either of them. I’ve seen stuff and consume things from bland in the past and it’s been good and I’ll look forward to picking up some new things.

Felipe Castro [38:25]:

Fantastic.

Dan Neumann [38:26]:

Wonderful Philippe. Well, thank you very much for taking some time to share outcome-based, um, outcome based planning with us.

Felipe Castro [38:34]:

Thanks for having me.

Outro [38:36]:

This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions, and information expressed in this podcast are solely those of the hosts and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.

Agile Podcast: Agile Coaches' Corner