OKRs for modern teams with Felipe Castro
Felipe’s Leader Origin Story
Scott Levy:
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?
Felipe Castro:
There’s a famous speech by Steve Jobs, where he says that you cannot connect the dots looking forward, you can only connect the dots in your life by looking backwards.I'm an engineer by training. I started working in startups. I did business development, product sales. I did everything you can do in startups. I lived in the Bay Area for a while, and after that I completely changed my career. I became an executive recruiter, a headhunter. I started recruiting for that company. I helped them build a team. After a while, I founded my own recruiting firm. We hired four companies, and then eventually, some of the clients started asking me, “Hey, can you help us with other stuff besides recruiting?” That led me to help them with performance management, which led me to help them set goals and helped me to realize, “Hey, this is broken. This is not working.”
At the time, we were doing work with companies that use Bounce Cards or something like that, where in October, you're trying to predict what you'll be achieving in December of last year. So it's 14 months later, and it basically worked for everything that the companies have been doing for a while, but anything that is new, like a new product, or any uncertainty at all, it was totally broken. I started looking for a solution, and then when I found OKRs, it felt like an agile, interactive way of setting goals. I started doing that in 2013-2014, and that’s 100% of what I do now. I started with the pain.
Scott Levy:
I take it that your engineering background led you to the phrase “full stack.” Didn’t you call it full stack OKRs in one of your presentations?
Felipe Castro:
Yeah. I used to call it full-stack agile, or end-to-end Agile. But the idea is that, the way companies use Agile, it’s for delivery only. The way they set the strategy is waterfall, the way they plan is waterfall, the way they reward people and compensate them is waterfall. If you look at either end-to-end or a stack with several layers, only one of them is Agile, and the rest is basically Waterfall. One of the things we need to do is stop doing Waterfall work. It’s annual, big-room planning, telling people what to do.
You Can’t Just Sprinkle OKR Pixie Dust
Felipe Castro:
The way I see it is that my work is to experiment with different narratives to see what helps people learn. Over time, I’m basically changing my product or my narrative because some narratives work better to achieve the learning outcome. Although the concept of the “enhancement” Agile or full-stack Agile is something that helps people, I’ve evolved to other ways of explaining the same thing. The way I explain it now is that the main problem we have with OKR is what we call the Tinkerbell Approach. Basically, you take a traditional company using traditional management and traditional ways of working, and you sprinkle some OKR pixie dust on top of it. Companies believe that if they just sprinkle that pixie duet on top of it, they’re suddenly going to turn into Google and fly away. That, of course, never works.
Two real stories. First, a huge bank, a couple of years ago, changed the label of their dashboard. They had a KPI dashboard - one week it was KPI, the very next week it was OKR. That was all they did. Second, I was in Europe a few years ago at a conference, and a group of Agile coaches reached out to me. “We’re using OKRs, etc., and we’re having problems. We’re writing really bad OKRs. They’re getting bad results, and we want to talk to you about how to solve that.” There were 8,000 people involved, and to train them, they just sent a one-pager on how to use OKRs, which is a very common scenario - thinking that all you have to do is just say OKR.
OKR Implementation Requires Unlearning
Felipe Castro:
Somebody once told me that the default state of corporate goals is to suck. They are things that aren’t measurable, a list of 2 activities that are just called OKR. That’s not how it works. OKR comes from what I call the start-up wheel of working - companies like Google, Amazon, Netflix, they aren’t start-ups anymore, but they fight to still work like a start-up. The best example is Amazon, where Jeff Bezos always says, “It’s always day one.” The message is that we need to work like a start-up. You can take something that came from that model and apply it over to the traditional company without changing the company - you just need to change how you work. There’s a lot of unlearning involved.
There are lots of things that no longer apply. There’s a great book by Barry O’Reilly called Unlearn. Barry defines unlearning as the process of moving away from behaviors and mindsets that were once useful, but now limit your success. Tools that, 10 years ago, were amazing, and now? Not so much. The way most teams work today is radically different. One of the things we need to unlearn is the idea that by spending more time planning, we can reduce uncertainty. Not at all!
Another example of unlearning is that often, when traditional companies reach out to me, they say, “We want to be a data-driven organization.” The very first thing they need to unlearn is the phrase, “I have 20 years of experience in this industry.” Your experience isn’t data or evidence. We need to unlearn that idea, and instead ask what the evidence is that backs this idea. I’m not saying throw away your experience; I’m saying that experience isn’t more important than evidence. It’s very hard for people to learn that because they’re used to having all the answers.
OKR Teams Should Avoid Becoming Feature Factories
Scott Levy:
That was one of the other things I liked in your downloads, you’d taken that idea from Spotify of the traditional Kanban style, where we’re working on this stuff, we’ve finished this stuff, but in the traditional style, they’re missing a column. It’s, “we got the result we wanted,” The idea is that everything up to that point is about learning. You want to deliver, but if you’re not learning, you aren’t actually agile.
Felipe Castro:
The idea that the Kanban board is missing a column is from John Cutler. The idea is that the way most things work today is like a feature package. It needs to move like a conveyor belt, you view the feature, and then you never see that feature again. You need to measure it again and see if it works. I was just on a call with a client, and they were saying, “We have a problem. We launched our app last year, and the app allows you to deposit a check. We launched it and we never touched it again, and the numbers didn’t go up.” You have to unlearn this idea of a feature factory, and begin thinking about a product. You give a team a problem or opportunity to solve, and they’re working on the same thing until they move the needle. That’s a big difference between shifting from a feature factory where you’re just measuring outputs and how many things you ship, versus, did we make a difference? What’s the outcome, what’s the result?
Replace Cascading OKRs with Conversations and Context
Scott Levy:
What are your thoughts on cascading your OKRs? Should you? What are some of the traps you’ve seen people fall into with representing their strategy?
Felipe Castro:
Cascading is one of the things that we need to unlearn. It’s so old that people believe there isn’t an alternative. It became a synonym of ‘spread’ - if you want to spread, if you want to align. If you think about it, a cascade is a natural phenomenon which is unidirectional. There are no feedback loops, no adjustments, and it ends up crashing. It’s not exactly the analogy you want. If you want to become an agile organization, you’re waterfalling your goals, but that’s not the best way to do it. The idea should be to have a conversation.
One story is when John F. Kennedy launched the Lunokhod. In the 60’s, during the Cold War, the Soviet Union was way ahead in the space race. They had the first satellite, Sputnik had better rockets, they put the first man in space. At the time, people were like, imagine what the Soviets would do if they controlled space! People were terrified, but another problem they had was, people may like freedom, but when they see that the Soviet Union is way more efficient, maybe we should align with them. They’re a dictatorship instead of a democracy, but what they’re doing is working. So JFK had an image problem that he was trying to solve. What happened was, JFK asked if they could reach out to NASA via his vice president to ask what they could do. NASA said that the Soviets had way better rockets and that they were way ahead of us, but going to the moon is so hard that they would have to start from scratch, just like us. For that, the investment they have today is meaningless. So, JFK and NASA decided to go to the moon. Kennedy presents the story by going to Congress and saying, I believe the nation should commit to the goal that by the end of this decade, we take a man to the moon and bring him safely back to Earth.
He describes that as a problem to NASA. He doesn’t say, “I need a three-stage rocket, here’s the spec, go build it with these features.” No, he gives NASA a problem to solve, and that’s what they decided to work with. It’s not about saying, “Hey, Scott, give me that feature” or even “Hey, Scott, work on this problem.” It’s, “I believe we should work on this problem here. What do you think?” Then, we have a conversation. Let’s say we want to reduce churn and increase retention. We believe we have lots of bugs, so we need to solve that. I ask you, what do you think? Then, we have a conversation. Maybe you say, “It doesn’t seem like bugs are the main issue. It seems like a lack of value in the product. We need people to use the product more and engage more with it.” The real power is in the back-and-forth of the conversation. You explain the problem you’re trying to solve, and the context.
One of the management principles of Netflix is lead with context, not control. That’s exactly the idea. We have the Cold War, we have the Space Race, and the Russians are winning. What can we do? Can we put a man in space first? No, the Russians are way better at that. That’s that. So, let’s try to go to the moon. So not only in this story was the government giving NASA a problem to solve, NASA was a part of selecting the problem.
Another historic example was 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. It’s the problem they needed to solve. The concept was, it’s after the Second World War, we need to rebuild the country. The economy needs to grow. It’s taking too long for people to go between the two major cities and Japan. Train is the main way, so we need a faster train. After several years of innovation, they launched the bullet train, which when 120 mph in 1964, which is really fast for that year.
Startups vs. Traditional Companies: Weekly Cupcakes and Annual Wedding Cakes
Scott Levy:
Handing off the specification … there’s so much attention today put into teaching people just to write a relatively clean spec. It sounds like a lot of companies don’t, as you say, provide the context, and say, “Is this the right spec?” versus, “I’m just going to give it to you.” That’s a very different way than a lot of people were taught 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.
Felipe Castro:
The idea is that when Agile was created, and Agile frameworks like Family Compound were created, we didn’t have lots of the techniques that we have today. We knew how to run experiments and test things, but it’s totally different than the way it worked 20 years ago. It doesn’t make sense to use Azure or Scrammer Command the way they used it 20 years ago. The idea is, if you use a Scrammer, where does the backlog come from? But, what if instead of having a stakeholder tell people the background, we gave them a problem to solve, explained the customer need and the problem, and we let the team test different ideas until they figure out the solution?
One analogy I like to use is in the traditional model, companies spend 12 months building a wedding cake. It’s the best cake on the planet, but it’s very expensive. They believe that the plan is correct, the spec is right, and they have 20 years of experience. A start-up works very differently, where instead of building a wedding cake in a year, they try to sell a cupcake every week. Every week, they test different versions of the cupcake. 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. Instead of a good business wedding cake, figure out how to win in the cupcake market. Let’s figure out how we can make money and make customers happy in the cupcake market. Let’s figure out a gazillion different ways to make cupcakes, and see which one works. The team has autonomy and techniques, as well as the context.
OKR Operating Rhythms
Scott Levy:
What type of cadence do you find is most helpful? When you go into clients and help them adopt OKRs, how often do they look back to see how things are going and what they might need to change?
Felipe Castro:
The idea is that OKRs work just like those Russian nesting dolls. You have a large doll with more dolls inside. So, you have different cadences and cycles. The idea is that you can have a long-term OKR for the company, usually ANO, which are higher level things that take longer to change and are more stable. Then, you should have quarterly OKRs for the teams. We usually track OKRs every week, and we say, Ok, based on what worked and what didn’t, let’s go again. If it’s not working, you try something different. If that cupcake is not selling, you try a different cupcake. That’s it - what cupcakes did we try last week? What are our next hypotheses? Let’s try it again. It’s not a feature factory, it’s putting something to compare about the same line. The idea of learning is crucial.
Individual OKRs vs. Team-Based OKRs
Scott Levy:
Do you have an opinion on whether people should use team based or individual OKRs, or both?
Felipe Castro:
It usually depends on how the team is structured. The idea is OKRs are how you keep score, how you know you’re winning. It’s the scoreboard for the game. Some people play individual sports, where each person has an individual scoreboard, and some people play team sports. If you’re working on a team, like a cross-functional team or an agile team/square, it’s usually the case that you have a whole team of people working together to achieve the same outcome. So, together, we’re going to achieve that OKR. You don’t want to have the designer report an OKR, one of the engineers report another, and the other engineer, a third one, all going in different directions.
On the other hand, you have functions like sales or recruiting. A recruiter usually works alone. They’ve got positions they’re filling, they’re hiring people, so they can have their own OKRs. Another example: let’s imagine, if you go back to Team Of Teams, you don’t have an actual team. There are lots of individuals that report to the same person. Imagine we are part of the social media team, and you handle Facebook, I handle Twitter and Instagram. You can have your OKR, I can have mine. The idea is, you use a team OKR when you have a team structure, and you use individual OKRs when you have individuals that work together. If you have an agile team or a product team/square, usually, you stop at the team level. Spotify doesn’t have digital cards anymore, Twitter mostly doesn’t, lots of people at Google on the engineering side or product side don’t use digital cards.