To OKR, Or Not To OKR
To OKR, Or Not To OKR
For the past few years, tech companies have been adopting OKRs as a silver bullet for a number of organizational problems. While it certainly has had a positive impact for some teams/companies, it has also become a common source of frustration among tech teams and it’s often used for the wrong reasons.
In this session, Flavia Neves will discuss how FREENOW has navigated the OKR process, what pitfalls they tried to avoid and what they learned throughout the way.
Hello everybody, welcome to “To OKR or Not to OKR”. For those of you who don’t know me, my name is Flavia. I’m currently the VP of Product at FREENOW where I’ve been shaping a high performance team, and also through a very interesting business transformation exercise. Before landing in Barcelona, I worked in Portugal, Ireland, and Silicon Valley, and spent most of my career between product growth and product management. It’s my second time here, at UXDX. I’m very excited to be back. And my first talk was dedicated to my experience implementing dual-track, which somehow generated a flurry of queries around OKRs. So listening to that, I decided to share my thoughts and learnings in a more organized way, as well as share how I think OKRs mesh with product management, and especially the organizational structure of companies.
So, the first question that I’m usually asked is whether or not I think OKRs are a management fad. Or, in other words, am I pro or against OKRs? And the truth is neither. I think, in a way, any framework that has become extraordinarily popular in the last decade, decade and a half, seems bound to get the fame of silver bullet for fixing organizational dysfunction and also increasing performance. I think most, if not everybody listening, has worked for a company that at some point took the easy and perhaps a little bit lazy route of trying to fix a broken setup with the adoption of a framework. And this is very common unfortunately that tech companies have problems, and they adopt one of these frameworks in an attempt to have the implementation of the framework fix all the foundational issues that are preventing them from performing really well.
So, my take on OKRs is that, Yes, this framework might and does help some healthy organizations set clear goals, instill more pragmatism, and also alignment among functions. But, OKRs cannot be the substitute for the deep analysis, the self-awareness, and also the openness needed to address structural issues. With that said, how do we know if we are a healthy organization or if OKRs work for our own needs? And it depends, but let’s start with motivations. Most companies that I advised or worked for, turn to OKRs to fix a problem, fix broken teams, poor non-existing alignment, lack of focus, et cetera. And unfortunately, it’s very common to see these problems often leading to somebody saying, “Let’s use OKRs.” Now, can OKRs really help? I don’t think they can. And I hope that by the end of these 30 minutes, you will agree with me.
So, the first thing to have in mind is that OKRs won’t solve our structural issues. We have to go deep. We have to figure out what is really compromising our performance. And sometimes even let go of old patterns and behaviors to start changing, not just the process, but especially the foundation. I really like how John Doerr describes OKRs. He says that OKRs are a shared language for execution. They clarify expectations. What do we need to get done and fast, and who is going to work on that? And I think this is exactly what OKRs are. They are a language. They’re not a solution for anything. They can help us. They can help us increase our performance to a certain extent, but they’re not going to resolve our foundational issues. But now you ask, can’t we do OKRs and fix the problems in parallel? And I want to tell you what happened when FREENOW relied on OKRs to fix our own issues, which I think is what happens to many tech companies.
So when I joined FREENOW there was no clear mission or strategy, teams were not empowered, our alignment was questionable, and there was a lot of confusion around responsibilities and ownership. Therefore, our teams were very demotivated, which in turn affected our speed. Everybody agreed that something wasn’t quite right and that we had to solve these problems if we wanted our—if we wanted to be more efficient. But unfortunately that led to the introduction of OKRs. We’ve been through five cycles already. And in my opinion, we have failed it every single one of them. With improvements, for sure we’re making progress, but only now in our last cycle, we had a couple of tribes for which OKRs actually worked. And I want to tell you exactly why I think we failed repeatedly and why not only OKRs didn’t solve our problems, but the problems we had prevented us from doing OKRs in the right way.
So, the first one is benchmarks. In the very beginning, we didn’t have our entire user journey tracked. And what was tracked was not exactly accurate. Without data—or in this case, trustworthy data—we didn’t have benchmarks. And this means that it was impossible for us to set realistic goals. Now, because we didn’t have realistic goals as soon as we started executing, we realized that these OKRs—these objectives might not be the right ones. We might have to tackle another thing before we get to this one, or the OKR made sense, but the targets were completely off. Now, on top of this problem, we continued reporting against these OKRs. But because they were obsolete, then the process became heavily bureaucratic with no real benefit added. So, this was one of the primary issues that we had in the very beginning.
The other one was alignment. For as long as I’ve been in the company, we’ve had alignment issues and many efforts have been made in this regard. We have regular syncs, force update meetings, we use a million different documents, spreadsheets, confluence pages, we do alignment exercises. You name it, we probably did it. But because none of this ever worked, it was decided to introduce OKRs. After all, it’s the number one framework to align the business. Truth is neither the previous methods nor force aligning objectives for OKRs got us any closer. And that’s because, again, OKRs are a language, they’re not the solution. So, if there are foundational problems preventing us from aligning with other areas of the business, such as—in our case, we didn’t have clarity on roles and responsibilities, nor we had shared the goals, company goals—then those have to be resolved first before we attempt to do OKRs. Otherwise, you’ll continue probably like us, with the same problems but increased frustration. Because now you have another framework, something that forces you to be extremely aligned, but because you didn’t solve the foundational issues that were preventing you from aligning in the first place, then you’re going to be even more frustrated.
The next one is project-based OKRs. Since Q4 of 2019, we spent the majority of our time going through migrations post acquisitions. And there are many ways of doing migrations, but in our case, it was very much project-driven. This means that we had a goal, we discussed the requirements ahead of time, and then we planned this long project to then be executed. The problem is that projects or tasks or initiatives that have binary results, such as done/not done, completed/not completed, benefit very little from this framework. But, hey, we still went through with the process and spend time figuring out how to put in papers something that wasn’t quite measurable, because it was yes/no, done/not done. So, there wasn’t much more than that. How much did this help the teams or even the executive team follow progress? Very little, especially considering that we still maintain the good old update sessions that we had before. So, even if somehow the OKRs helped a little bit with this process, the fact that we still had to maintain our previous processes and reporting sessions was proof that this didn’t quite fit into the OKRs.
The next one might be a little bit controversial, because I bet most of you are thinking, “Isn’t bottom up what we all want and how things should actually work?” And it certainly is. But for bottom up to work, there has to be a clear mission in place. Everybody needs to know what their role in the organization is. So, because bottom up was the right way to go, or so say the principals, but because we didn’t have the shared strategy or goals, then we ended up with everybody giving ideas that would then be filtered by the managers for the executive team to consider before they wrote the company objectives.
Where did these ideas come from or what they were based on? Random ideas, really. Based on each person’s opinion, their area of focus, what they were working on, and also their perceived priorities for the business. And because everybody was giving random ideas and there was no shared vision or strategy that would help us prioritizes the initiatives, this led to lack of focus. We had too many initiatives rolling at the same time. And some of them even with conflicting priorities, which increased even further, our lack of alignment. Everybody was pushing in different directions. There was no clear guideline in terms of where we were heading towards. And therefore, we couldn’t really effectively prioritize the initiatives. Therefore, each team was pushing to get their stuff done, which gave the—an even bigger gap between the teams.
So, what happened at FREENOW at this point was that teams were resenting the process. Every time they heard OKRs, they would roll their eyes. And in hindsight, I can’t really blame them because the process was extremely stressful. It was useless, for the most part, and it only exacerbated our deepest problems. We had performance and efficiency problems that led to the introduction of this framework. And after five cycles, we have the exact same problems, sometimes even augmented because OKRs forced us to do something that we didn’t have the conditions to execute or to utilize.
So now let’s say that you know OKRs are not a silver bullet and that your motivations are the right ones, and you want to know, “Okay, how do we go from here? How do we make sure that we are in a good position to do this?” As I mentioned in our last cycle, we had a couple of tribes for which OKRs worked. And that, coupled with other experiences that I had in other companies helped me compile four pre-existing conditions that I find a must for OKRs to work. Doesn’t mean that these are the only ones, doesn’t mean that these—or if you nail these four, that you’re definitely going to succeed at implementing OKRs. It simply means that they’re so critical for the business. They’re so fundamental that if—I think that if you fail at one of these, the likelihood of being able to pull off OKRs successfully is quite slim. And I also want to talk about the principles, the principles around the framework. I think if you do a quick search, it will return many different articles, some very good ones discussing why companies fail implementing OKRs because they overlooked some principles or because they implement the principles in the wrong way.
I want to talk about something that I don’t see many people talking about, and that has to do with the health of your organization. What is the state of the [Inaudible – 11:24] and what does that tell you in regards to how successful you might be implementing OKRs or not, and how much you will get out of the framework? So, the first thing that I want to talk about is team structure and culture. If you want innovation, if you want high performance, there’s no way around it, you have to invest in your teams. How they’re structured, how empowered they are, how motivated they are, can make or break your company. So, you have to make sure that you give your teams autonomy, and that you define everybody’s role in the wider strategy. You might even have—you might have the best goals in mind. You might even have nailed the prioritization of initiatives, but if you don’t empower your teams, then you are at least setting a ceiling for yourself. You can’t forget that if you hire the right people, then your team members are the experts in their own area. They know the best way of solving problems in their area of focus more than we managers do. We have to look after 10, 12, 15 areas simultaneously, so we have to make sure that we empower our people to solve these problems that we give them the conditions they need to perform and to utilize their skills to the best of their abilities.
Then the next one is data. You have to know and live the metrics. And this is something that we have to work on in the very early stages. Right after you build your team, that you hire the right people, and then you structure them in the best way is to look after data. And by this, I mean, making sure that the data is accurate, that we described the method of measuring correctly and that it’s standard across the organization. And then as, or more importantly, that we choose the right metrics, the metrics that really reflect the user behavior rather than the vanity metrics that sometimes we used to make us look good. So, this is really important. And then once this is nailed, educate the teams from a data perspective, make sure that they can take the information that they get from the market and use it to make the right decisions. Whether that’s seasonality, as simple as seasonality, or market evolves, product changes, or even users change their behavior, that our teams have the data sensibility, data maturity to take this information to make the right decisions. And when it comes to OKRs, make sure that they understand when an OKR no longer makes sense meet cycle. Because if they don’t—and COVID was a good example of that, things changed, we had to readjust—then you’re going to go on a wild goose chase, which will not lead anywhere. And going back to what I was saying about benchmarks, if you don’t know your baseline, if you don’t know what your current performance is, it’s impossible to set a reasonable target value. And if you don’t have target value, I think it’s obvious the direction of your change is obscure. So once again, OKRs don’t fix your discipline in formulating precise KPIs. They don’t educate your teams to be data driven and data aware. And to have the data sensibility, required to use the data and then make the right decisions based on that. So, we have to work on this before we start working, using the framework, and it’s very, very essential.
Now, we get to one bed it’s usually neglected. I think we all know that managers are one of the primary reasons for talent churn, but what may come as a shock is that some studies show that 65% of managers have zero or negative net value to a company. They add zero negative net value to a company. This is amazing. This is more than half of the managers. And this means that managers have to lead better. This idea that a manager sits in their ivory tower and spends the days jumping from sync to sync asking for reports and getting updates on a day-to-day basis, it’s in my opinion a netter fail. A good lead is somebody who unblocks the teams, who sets the direction, who anticipates and disarms bombs, who is constantly looking into ways of increasing the team’s efficiency. It’s not the typical 30 meetings a week to get updates on the day-to-day basis. That doesn’t really matter. If we hire the right people, and then we empower them, we have to trust that they have the day- to-day covered. And if something goes wrong, they will be able to fix it by themselves. And if you need to get that information, they will come to you and let you know. And when it comes to OKRs, our job is not to pass along the template that they have to used to write the OKRs or give them the timeline that they have to work with. We have to take an active part in this process and support our teams, whether that’s clarifying expectations, clarifying the company objectives, helping them formulate precise KPIs, helping them pick the right metrics, or even just setting the direction, helping them find the best way to go about the company OKR—the company objectives that were set.
And now, the PS, the resistance, the strategy. I get a little bit triggered by this one, so bear with me. But how do we expect our teams to be autonomous and high performance without a clear mission or strategy in place. Teams have to understand what we’re trying to achieve as a company and why, in order to assess which problems to tackle first which what’s the best way to solve them. And also to understand which levers to pull, what are the dependencies that they might have. So, we have to make sure that we have a clear strategy or company goals in place before we ask them to write OKRs, because if we don’t, you—and if you don’t, you might end up with the same problem that we have. There’s no clear strategy or guidance or direction, therefore, everybody gives random ideas. Then you end up with lack of focus. Everybody pushing in different directions, which will affect not just the noise that you have in the company. Too many things going at the same time and nobody really focusing on something very specific, and it will exacerbate your problems when it comes to alignment. And when I talk about strategy or company goals, I’m not referring to a very lengthy document, strategical document, or an 80 or 100 slide deck that you put together. It’s something very simple, just to make sure that everybody understands what we’re doing, what is the direction, and why we are going in this—in rowing in this direction. So, it could be a one page, or it could be just a one slide with the pillars and just clarifying expectations. Why are we going in this direction? And what exactly are we trying to achieve with this?
Okay. So, we have established that OKRs don’t solve the problems that we tend to use them for. And I also shared why we kept failing at them and what I find essential that we master, if we want to use OKRs correctly. But now you ask, “Do OKRs work for you after these five cycles?” And generally speaking, they don’t. They don’t. But in some areas of the organization, they do. And that’s because we tackled these problems that I discussed previously. In my last UXDX talk, I shared how we structure the teams, we worked on our data quite extensively, we implemented dual-track, and more recently we have developed the guiding strategy. I have always been a firm believer in empowering my team, so I do that and I take it very, very seriously. So, I think we gathered all the conditions required to be able to benefit from using OKRs, for making OKRs work. But if you look at other areas of the organization, you will see that they didn’t solve most of these problems, and therefore they still haven’t been able to pull off OKRs. It’s almost like a real life kind of flawed A/B test. You have two groups, both exposed to OKRs. One solved most of the problems and their efficiency is higher, their performance is better. The other one didn’t tackle these problems, but they used OKRs, and their efficiency and performance is lower. When the group that solved most of the problems has to interact with the other group, they get swallowed by the old practices and their efficiency drops immediately. So, it’s almost like a real time, a real life kind of flawed A/B test, which proves the importance of this business transformation exercise that I’ve been going through and that I recommend that all companies go through. It’s what—what really changed for us was making sure that we tackled our foundational problems, our rooted problems, what was preventing us from becoming as efficient as we could be. OKRs had very little to do with that. Is it nice to have a—to use a framework that makes us all speak the same language? It sure is. But what gave us a huge jump was tackling these problems, was solving our most rooted problems that were preventing us from being who we are today or where we are heading towards.
Okay. So, with all these caveats, if you’re still embarking on this journey and you’re kind of wondering, what do we need to think about when we first started implementing OKRs? Or even before, are we in the right place? Should we use OKRs or not? We know that it’s not a silver bullet, we know that it’s not—that our motivations are the right ones, and we know that we might have to tackle these problems. So, what do we do? And I gathered some suggestions for increasing your chances of succeeding when you start implementing OKRs.
So, the first one is motivation. Start by assessing whether or not your company is a good candidate for OKRs. Not all are, and it’s okay. I hear a lot of people say that, no, every company will benefit from using OKRs. And I don’t, don’t think that’s true. I think if you are an early stage startup, for example, or if you have to move really fast, maybe OKRs will not add much and only slow you down. So, you probably don’t want to use OKRs. Same if you have—if your company is lives for BAU, if you have a lot of BAU, then OKRs will not be more than added work with no real benefit because it’s—you’re not going to benefit much from that because it’s BAU, you have to do what you have to do. So, you’re not going to be able to extract that much from OKRs. So, think critically about your business needs and try to gauge if your company will benefit from OKRs or not, and also if now is the right time. Because now might not be the right time, but who knows in 3, 6, 12 months, you might be in a different position and it might make sense. So, you don’t have to give up on OKRs just yet, but think about if now is the right moment.
The next one is the basics. Make sure that you’re embarking on the OKR journey for the right reasons, kind of what I was touching on with the motivation. Even if your company is a good candidate, if you are turning to OKRs to solve a problem, you might want to rethink that. You have to work on these problems. You have to fix them first, if you want to use—to reasonably use OKRs. Because OKRs don’t solve anything, you have to put in the work and you have to make sure that you create the right conditions in your company to be able to leverage OKRs. So, if you want to reap the benefits, work on the problems, and then start working on—start implementing OKRs if you think that it’s going to help you.
Baby-steps is the next one. Starts small and don’t try to master OKRs in your first round, which is not the same thing as saying, it’s okay to fail in X number of cycles. I hear a lot of companies who say, “We’re going to start implementing OKRs.” But the expectation is that we’re going to fail in the next three, four, five cycles. That’s not what I mean. What I mean is that sometimes we have to simplify the process, when we start. Sometimes a minimalistic approach is better, it will actually provide more focus and more than often, but better results. So, if you have to start by setting a mission OKR, so be it. Who cares? It will help you master one area and build up from there. And if you think about the timeline and you’re kind of thinking, “Oh, my God, it’s going to take us so long to master everything if we go one by one.” Think about it. If you take three, four, five cycles to master OKRs, and we keep repeatedly failing at them, you’re going to end up in five cycles you start seeing a little bit of progress, but a lot of frustration has been accumulated. Whereas, if you start really small and you try to master a few things, every cycle, you’re going to take the exact same time. So, it’s going to be—it’s going to take you as long as the other approach takes you. But by the end of those three, four, five cycles, nobody’s actually resenting the process because you started small, you did compose the framework, and you started mastering one by one or a few things every cycle until you can work with OKRs flawlessly. So, it might make sense. Start small, and if this helps you master each area and then build up from there, so be it. It’s okay. Nobody’s watching over your shoulder to see how we implement OKRs. So, use it the way that you deem fit, use it to whichever way works for your own company.
The last one is flexibility. Don’t adhere too strictly to the principals. I always recommend adjusting any framework to the company’s specific needs, whether that’s OKRs, Dual-track, Agile, Spotify model, whichever you’re implementing, adjusted to your specific needs. At FREENOW, all teams and all objectives were contemplated in the OKRs, and that shouldn’t have happened. Operational tasks are for us and for a lot of companies as important as other initiatives, but they don’t fit into the OKRs. So, we shouldn’t have forced it. And the same with bottom up, because bottom up the principals say that OKR should be bottom up, but because we didn’t have the right conditions to do bottom up, it was a failure. And so, my message to you is break the rules if it helps you get into the groove, it is okay. Again, nobody’s watching you. Nobody cares how you’re implementing this, as long as you get to a point where you can use OKRs in the right way, whichever way you get there is fine. As long as you don’t create problems throughout the implementation, then use it, adjust the framework to your company, adjust it to what you’re trying to achieve and what you want to get out of OKRs. Don’t force everything that you read online about OKRs, and even the official principles of the framework.
And then, more importantly—and sorry for repeating myself, but I think this is really important—make sure that you meet the pre-existing conditions. What you want is performance at the end of the day. It’s not to tell the world that you’re using OKRs, like Google or any other popular company. What you want is performance. And just like I told you that what happened with FREENOW and other companies that I worked for, what really helps you get there—unless you already have all of these things figured out—is working on the foundational problems of your company. You’re making sure that you have hired or trained the right team. They have the right structure that you’ve covered your metrics, your data. That you educated your teams towards being data sensitive, data mature. That you have the right leadership in place, which is often overlooked. And also, that you have a strategy. That you have a guiding strategy that everybody can turn to, to know exactly where they are, where we’re heading towards, and why we are heading in that direction. So, work on these things, and I think you’ll see the biggest jump that you might want to get, not the OKRs. Then you use OKRs, and that will help you with the last 1 to 5%. But, unless you have all these things already figured out, this is probably what’s going to get you the biggest jump in terms of performance, and also inefficiency.
To finish off, I put together a ready checklist that you can go through to ensure that you’re ready to start this journey. You have made your decision, you want to start this, and you just want to do a final check to make sure that you are—that you have your best foot forward to implement OKRs. So, I won’t go one by one, but go through the list and see if this is a good reflection of who you are, what your company is, or if there are certain things there that kind of are red flags, such as if your company—if there’s a lot of micromanagement in your company, you might want to look into that first. Or if you have a lot of projects going on, then you might want to rethink using the framework or at least changing how you’re tackling the problems or the objectives. But if you don’t, if it’s a good reflection of who you are, then you’re probably good to go, or at least you’re in a good position to make this framework work for you. So, that’s it. I thank you so much for listening. I hope that my experience and tips are useful to you. If you have any questions or if you want to get in touch, my contact details are available here. I love a good discussion and good debate. I love exchanging experiences and knowing how other companies are tackling these problems. So, feel free to reach out. Thank you very much. And I hope to see you later in the Q&A in the panel. So, see you later.
Got a Question?
More like this?
Thu, Jun 18, 12:30 PM UTCEmpowering Teams To Create Impactful Products
Chief Product Officer, Clue
Tue, Oct 06, 1:00 PM UTCAligning Product & Business Objectives
Global VP of Design, SumUp
Chief Product Officer, Transformation Practice, Keyot
Director, UK&I Business Partner, Global payments
Wed, Oct 07, 7:00 PM UTCHacking Within An Enterprise: From Startups To Intrapreneurship
Product Team Lead, Workday