To OKR, Or Not To OKR

Flavia Neves at UXDX Europe. Video: https://youtu.be/GYBp8WJ-g-M

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Are OKRs a management fad?

[00:00:00] 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 going 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.

[00:00:19] It's my second time here at UXDX, and I'm very excited to be back. My first talk was dedicated to my experience implementing dual-track, which somehow generated a flurry of queries around OKRs. 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.

[00:00:49] 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 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.

[00:01:24] Unfortunately, this is very common: 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. 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.

[00:02:04] With that said, how do we know if we are a healthy organization, or if OKRs work for our own needs? 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 or non-existing alignment, lack of focus, et cetera. And unfortunately, it's very common to see these problems 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.

[00:02:41] 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?

[00:03:11] I think this is exactly what OKRs are. They are a language. They're not a solution for anything. 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? 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.

What happened when FREENOW used OKRs to fix its problems

[00:03:40] 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 to be more efficient. But unfortunately that led to the introduction of OKRs.

[00:04:08] We've been through five cycles already, and in my opinion, we have failed every single one of them. With improvements, for sure, we're making progress, but only now in our last cycle did we have a couple of tribes for which OKRs actually worked. I want to tell you exactly why I think we failed repeatedly, and why not only did OKRs not solve our problems, but the problems we had prevented us from doing OKRs in the right way.

[00:04:36] 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. Because we didn't have realistic goals, as soon as we started executing we realized that 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.

[00:05:12] On top of this problem, we continued reporting against these OKRs. But because they were obsolete, the process became heavily bureaucratic with no real benefit added. This was one of the primary issues that we had in the very beginning.

[00:05:30] 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.

[00:05:54] The 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. If there are foundational problems preventing us from aligning with other areas of the business, such as, in our case, not having clarity on roles and responsibilities, nor shared company goals, then those have to be resolved first before we attempt to do OKRs. Otherwise, you'll probably continue 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, you're going to be even more frustrated.

[00:06:47] The next one is project-based OKRs. Since Q4 of 2019, we spent the majority of our time going through migrations post acquisitions. 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.

[00:07:17] But, hey, we still went through with the process and spent time figuring out how to put on paper something that wasn't quite measurable, because it was yes/no, done/not done. 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 maintained the good old update sessions that we had before. 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.

Bottom-up without a shared strategy

[00:08:00] 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. Bottom-up was the right way to go, or so say the principles, but because we didn't have the shared strategy or goals, 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.

[00:08:37] Where did these ideas come from, or what were they 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 prioritize 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 our lack of alignment even further.

[00:09:06] Everybody was pushing in different directions. There was no clear guideline in terms of where we were heading, and therefore we couldn't effectively prioritize the initiatives. Each team was pushing to get their stuff done, which created an even bigger gap between the teams.

[00:09:28] 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.

Four pre-existing conditions: team structure and data

[00:10:06] 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. 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.

[00:10:35] It doesn't mean that these are the only ones, or that if you nail these four you're definitely going to succeed at implementing OKRs. It simply means that they're so critical, so fundamental for the business, that if you fail at one of these, I think the likelihood of being able to pull off OKRs successfully is quite slim. I also want to talk about the principles around the framework. 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 implemented the principles in the wrong way.

[00:11:16] 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?

[00:11:31] 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. You have to make sure that you give your teams autonomy, and that you define everybody's role in the wider strategy. 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.

[00:12:05] 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, and that we give them the conditions they need to perform and to utilize their skills to the best of their abilities.

[00:12:39] The next one is data. You have to know and live the metrics. This is something that we have to work on in the very early stages. Right after you build your team, hire the right people, and structure them in the best way, is to look after data. By this, I mean making sure that the data is accurate, that we describe 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 we sometimes use to make us look good.

[00:13:14] This is really important. 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 as simple as seasonality, or the market evolves, product changes, or even users change their behavior, our teams need the data sensibility, the data maturity, to take this information and make the right decisions. And when it comes to OKRs, make sure that they understand when an OKR no longer makes sense mid-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.

[00:14:05] 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 a target value, I think it's obvious the direction of your change is obscure. 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 make the right decisions based on it. We have to work on this before we start using the framework, and it's very, very essential.

Leadership and strategy

[00:14:47] Now we get to one that'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 or negative net value to a company. This is amazing. This is more than half of the managers.

[00:15:13] 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, is in my opinion a net 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. That doesn't really matter.

[00:15:52] If we hire the right people and then we empower them, we have to trust that they have the day-to-day covered. If something goes wrong, they will be able to fix it by themselves, and if you need that information, they will come to you and let you know. When it comes to OKRs, our job is not to pass along the template that they have to use 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 objectives that were set.

[00:16:43] And now, the pièce de résistance [?], the strategy. I get a little bit triggered by this one, so bear with me. 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 and what's the best way to solve them. And also to understand which levers to pull, and what dependencies they might have.

[00:17:13] 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 you don't, you might end up with the same problem that we had. 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 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.

[00:17:46] When I talk about strategy or company goals, I'm not referring to a very lengthy strategic 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 the direction is, and why we are rowing in this direction. It could be a one-pager, or it could be just one slide with the pillars, clarifying expectations. Why are we going in this direction, and what exactly are we trying to achieve with this?

Do OKRs work at FREENOW now?

[00:18:26] Okay. We have established that OKRs don't solve the problems that we tend to use them for. 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?" Generally speaking, they don't. But in some areas of the organization, they do. And that's because we tackled these problems that I discussed previously.

[00:18:50] In my last UXDX talk, I shared how we structured 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, 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.

[00:19:32] It's almost like a real-life, 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.

[00:20:02] It's almost like a real-time, real-life, flawed A/B test, which proves the importance of this business transformation exercise that I've been going through, and that I recommend all companies go through. 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 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, solving our most rooted problems that were preventing us from being who we are today, or where we are heading.

Suggestions: motivation, the basics and baby steps

[00:20:50] With all these caveats, if you're still embarking on this journey, you might be wondering what we need to think about when we first start 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 our motivations are the right ones, and we know that we might have to tackle these problems. So what do we do? I gathered some suggestions for increasing your chances of succeeding when you start implementing OKRs.

[00:21:22] 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 every company will benefit from using OKRs, and I don't think that's true. If you are an early stage startup, for example, or if you have to move really fast, maybe OKRs will not add much and will only slow you down, so you probably don't want to use OKRs. Same if your company 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 BAU, you have to do what you have to do. You're not going to be able to extract that much from OKRs.

[00:22:14] 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. You don't have to give up on OKRs just yet, but think about whether now is the right moment.

[00:22:38] The next one is the basics. Make sure that you're embarking on the OKR journey for the right reasons, which is 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 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. If you want to reap the benefits, work on the problems, and then start implementing OKRs if you think that it's going to help you.

[00:23:20] Baby steps is the next one. Start 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 they'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 provide more focus and, more often than not, better results. 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.

[00:24:04] If you think about the timeline, you might be 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 you keep repeatedly failing at them, you're going to end up, in five cycles, 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. It's going to take you as long as the other approach. But by the end of those three, four, five cycles, nobody's resenting the process, because you started small, you decomposed [?] the framework, and you started mastering one or a few things every cycle, until you can work with OKRs flawlessly.

[00:24:56] 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 you implement OKRs. Use it the way that you deem fit, in whichever way works for your own company.

Flexibility and the pre-existing conditions

[00:25:15] The last one is flexibility. Don't adhere too strictly to the principles. I always recommend adjusting any framework to the company's specific needs, whether that's OKRs, dual-track, Agile, the Spotify model, whichever you're implementing: adjust it 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. We shouldn't have forced it.

[00:25:49] The same with bottom-up. The principles say that OKRs should be bottom-up, but because we didn't have the right conditions to do bottom-up, it was a failure. 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, 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, or even the official principles of the framework.

[00:26:40] 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. Just like I told you about 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.

[00:27:10] Make sure that you have hired or trained the right team, that they have the right structure, and 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, a guiding strategy that everybody can turn to, to know exactly where they are, where we're heading, and why we are heading in that direction. Work on these things, and I think you'll see the biggest jump that you might want to get, not from 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 efficiency.

A readiness checklist

[00:28:03] To finish off, I put together a readiness 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 have your best foot forward to implement OKRs. I won't go one by one, but go through the list and see if it is a good reflection of who you are and what your company is, or if there are certain things there that are red flags. For example, 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 change how you're tackling the problems or the objectives.

[00:28:48] But 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. That's it. 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 a 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. See you later.