OKRs, the good, the bad and the ugly

(Upbeat music) - [Speaker] Oh where's the clicker? Oh, there we go, sorry.

I'm off to a great start.

Yes, so getting into it, 20 minutes.

I love OKRs.

I mean, they're not the perfect solution.

I mean, nothing ever is but trying to fit 20 minutes into what I like and don't like about OKRs has been really tough but I'll give it a crack.

So, as a bit of a recap, so OKRs, you basically got your objective, which is essentially what your business or product goal is. This is kind of your qualitative inspirational statement about what it is that you're trying to do, what success would ultimately look like.

You then have your key results, which is basically how you take that objective and how you quantify whether you have successfully achieved it or not. Now in some cases, you can have objectives that will span multiple quarters and so your key results may not necessarily be that you've exactly achieved that objective in full but what it will be is that you've made meaningful progress on to that objective.

The key thing with key results is to really push yourself and challenge yourself to make it measurable. So ideally, it's not we've delivered X.

It's we've delivered an uplift in X, which is a change in customer behaviour and that can often be the tricky challenge. So to work through a practical example at SEEK and this is a good example because it's relating to underperforming job ads, which ties nicely to Cheryl's sheet ads example. So we also realise that they're sheet ads without this so we also try to help.

So the objective here was increasing placements being made by hirers through improving job ad quality. The key result that the team had was reduce the percentage of direct ads on site containing two or more underperforming factors from 14% to less than 1%.

So we know from analysis that we've done, we know in job ads, what can affect performance and basically, we wanted to reduce that.

But the key in all of this is it doesn't speak to the solution.

So doesn't get specifics into which underperforming factors and it also doesn't get specific on how we would actually solve them.

We're really trying to leave that flexibility for the teams and I think for me when we rolled out OKRs almost two years ago, that was one of the key things we were trying to address. We had a business that was talking about very specific solutions from the outset.

We had teams that were narrowing in on one solution really quickly and we wanted to move away from that and we wanted to remind ourselves of what the outcome is we were trying to achieve and give teams flexibility.

So the challenge is in how you write this to make sure that you've given yourself that flexibility. So I'll start off with the good and yes we do actually run with OKR Day balloons and OKR Day cupcakes and I believe that's good.

I think everybody else thinks I am quite possibly mad but that's okay.

So I'll get into some of the good.

So the first one would be clear OKR rituals drive accountability, deeper conversations and alignment. So one of the things we worked out really early on when we embedded OKRs is that you needed to be very clear with teams on the rituals that we believed were mandatory. So prior to OKRs, we had things like KPIs.

The problem with all of that is most of the team couldn't even tell you what the KPIs were Or even worse, they would say, "Oh, that's the product managers thing.

That's their job.

I don't know." And so then I would have product managers who would say, "Oh, I can't leave to go into extensive customer research because I'm worried I need to be here with the team to make decisions." So there's this lack of trust that was going on. So right from the beginning when we established OKRs, we tested which rituals really were fundamental to the OKR cycle and process and to set it up for success but also, we were very clear with teams from the get go that OKRs was a full team process, that when it came to OKR setting, they all needed to participate in setting, they all needed to participate in reviewing them and what we found from that is the teams started to have deeper discussions than we'd ever seen before.

We had one team in the first round of OKRs that had to have seven hours of meetings to align on their OKRs which is ridiculous and obviously, you know, exhausting but that's because and obviously it changes. We don't have that anymore but when they were starting out, because they were coming from such a place of misalignment or even apathy and then all of a sudden when it's like, well, no, what do you think we should be doing and why should we be doing it, all of a sudden there were these really rich debates we were having.

So the rituals that we found that really worked and are embedded into our processes, the first one was around the team OKR setting sessions. So making sure that the OKRs were not being set by a product manager at their desk writing them themselves. We have one or maybe two OKR setting sessions every quarter, which the whole team is expected to go to, to come up with what their OKRs should be for the quarter. The next one is weekly team check-ins.

So when we started trialling OKRs, what we actually found, we almost had an IB experiment.

What we found when OKRs weren't really working that well with a team was because they actually weren't doing the weekly check-in. And so the weekly check-in is to basically check how does everyone feel from a confidence level about us achieving the OKRs and you do silent voting, so you don't get the kind of peer group pressure but then what it does is it forces a discussion around well why do we have different perspectives on our ability to achieve the OKR or if the team is all of a sudden not feeling confident, what do we potentially need to do differently on our idea to try and hit that marker.

So it drives that conversation and that accountability. The other one was end of quarter review and setting. So this is where the balloons come in.

So every quarter, at the end of the quarter, every team comes and presents to our steering committee for half an hour and they present on how the quarter went.

So how they went against the objectives that they'd set out, what insights they'd learned, what customer insights they'd learned and then they spend the next 15 minutes talking about what their OKRS are for the next quarter and what we found is in the beginning, you know, you'd have a fair number of teams where it was just a product manager and the business analyst who would show up and talk, which was good because they were balloons and cupcakes and it was in a big room.

So that wasn't awkward at all, whereas now, fast forward almost two years later and basically we have the full team come every single time and actually we have engineers that speak to most of it. So they actually divide out the content and everyone's playing a role in talking about how they went.

And then last one is we do mid quarter check-ins. So we try to keep governance really light but we do have a large number of teams.

So what we found very helpful is outside of that OKR setting time, once in the middle of the quarter, we get back together. Again, it's another half hour.

They come in and they talk about level of confidence. They also start to talk about well, do you need to actually change any of your OKRs? Do you need to change your targets? Do you need our help with anything? And for the teams, this has been really useful because it forces them to get out of the detail and to actually think about, okay, how are we going? This is an example of the template that we use. So this is the quarter in review.

So it basically shows you, you know, what were your objectives? What was the effort? So then for any team, we can see what their ratio of effort was on all the OKRs. This is really useful not to tightly manage people, but more to say if something was incredibly important, but the team spent 80% of their time on something that wasn't even classified as their OKR themselves, we can get into a conversation about what drove that. We also go through highlights and learnings and challenges and for us, this helps us pick out where there's challenges that might span multiple teams where we might actually need to do something bigger to try and help.

And then this is the next quarter objectives. Very similar.

It talks through what key dependencies the teams have though and it also shows which business OKR they actually ladder up to.

We also like to make sure that we're calling out non OKR work.

So basically, anything they've agreed to do that is not one of their core OKRs and again, it's just that transparency piece.

So going in, everybody's on the same page about what it is the teams are trying to do. The next key learning we had was the quarterly cadence. So the fact that you're operating on a quarter actually drives a number of positive benefits. So the first one is trade off conversations. Three months is actually not a long time and so when you're planning out a three month period, you get real very quick on what it is you can achieve and what it is you can't achieve. And so teams will come to you and they'll say, you know, "We have these three things.

We want to do them but we can't do them all." And so right up from, it forces your hand to say, "Okay, actually, which is the one we want to focus on because we need to deprioritize the others," where in the past, what we would do is we try and do all three at the same time and then we wouldn't really achieve any of them very well, because we wouldn't be focused enough.

The other one is alignment between teams.

Because we've got all teams going through the OKR cycle together, they're all working out their OKRs at exactly the same time. So then what happens is before they finalise their OKRs, they go and talk to all of the teams that they're dependent on and they get agreement on is that team going to be able to deliver on that dependency. And so we have a number of cases where teams will say, "We actually wanted to work on X, but we didn't because we weren't able to actually line up the dependencies.

And so now we're actually going to delay it and we're going to focus on something else instead." And then my favourite one is the ability to say no to the business.

So, one of the biggest benefits I've seen is that now that we're in an OKR cycle, everybody knows.

When the OKRs are locked in, you cannot come in and tell a team, "But actually, we also want this thing or these other priorities cropped up." Again, it's only a three month period.

It goes really quick.

So basically from this process, what we've been able to do is train the business to say that's fine if something has come up, it can wait and we can put it in for a future quarter. And so that's been really, really good at keeping the teams focused and keeping a lot of the distractions away from them.

This is actually my team.

I made them pose for this.

They're excited about it.

But one of the big things is having OKR focus, it stops a business from being solution focused. So we had an example.

We had a team that was looking to build.

So we have a lot of clients that don't come to seek directly.

They use third party software, they use HR software. We've got a proactive database.

It's a little bit similar to LinkedIn that you can go and you can search and you connect with candidates and we want to integrate that into their systems because we know that that's going to be easier and it's going to drive deeper product adoption. From the outset, our Managing Director, our Commercial Director, myself, all kind of had strong views of what this integration was going to look like into the team.

The team decided, well, we're going to come up with a discovery OKR and the discovery OKR was basically we want to validate or invalidate the six riskiest assumptions that we believe exists around these type of integration.

So it was very open.

The team determined what the riskiest assumptions were, not stakeholders and what ended up happening is through that period, they came back and they did use the continuous discovery method that Cheryl was talking about earlier, but they actually came back and the integration looked quite different. They were aspects around searching across their database and our database that I myself would have thought was going to be extremely valuable but they went and spoke to customers and they proved that wasn't the case and we gave them that space and flexibility and they ended up coming back with something that was far better than what was in our minds. The other thing that we've done and when I've spoken to other people who've implemented OKRs, I think sometimes this can trip people up.

We make sure when we're talking about OKRs, we include all the work so that you actually have a full picture of what's going on, not just what is deemed necessarily customer value. So we include the customer value.

We include any security and reliability work and platform health that's going on and actually, our engineers in the beginning were very sceptical because they're like this is a just another way for product to drive priorities. But what's happened is OKRs actually now provide a vehicle for them to surface key platform work that needs to be done, big pieces of work and the value of why we would do it. We also make sure we include non OKR work.

We know there's just be a few things that have to be done. We know this small dependencies between teams, particularly place of SEEK's size.

So we include non OKR work, which we assume to be about 20% of the team's time. And then when we also have bigger pieces of discovery, we also include that too.

So we get the team to write a discovery objective. So we're very clear as a business about what we're trying to do and why for things that are coming up.

So then the bad.

Well, one of the bads is the OKR balloons sit deflated in meeting rooms and they don't look great. That's the first part about the bad.

One of the things that is bad is about unclear decision rights.

So something that I've seen play out a little bit is confusion between teams.

If you read any of the OKR literature, it generally says it's a mix of top down and bottom up. So it's a bit of a negotiation.

I think, you know, the formal way of saying it is usually like the business decides on the objectives and then the team decides on the key results. In practise, I think it's a lot more nuanced than that but it is a negotiation and I think what we've seen over time is some challenges with teams, where teams feel like they should own completely setting the OKRs and then they should just be informing their leaders and the business about what it is that they're doing. So one of the things I would always recommend in installing OKRs or embedding OKRs is making it clear that it is actually a negotiation and being clear on the things that the team can control versus the things that they should be open to feedback on. The next one would be, I talked a lot about the benefit of speaking to teams and understanding to the dependencies.

One of the challenges that can happen is when the teams aren't aligned on the priority of the dependencies.

So what I mean by this is where I've seen this work really well is you've got Team A, and you've got Team B.

So an example we've got is we've got a notifications team that deliver out all of our kind of email products and we've got a team that basically builds our search engine that powers is all of that and we've just gone through the process of building out this new search engine, which is all AI driven now, driven on the power of the crowd and basically needs to be implemented in through all of our notification products.

So the team comes together and then they say, "Okay, we've got the shared work." Now in the ideal scenario, what they will do is they'll have a shared OKR. So they've one OKR that both teams will run with and then it means that they both know that for that to be successful, they've both got to contribute their pieces of work. What happens in some teams though, and actually, this notification one is a good example, the notifications team is saying, "Well, this is our top priority.

We need to get these new search results in. We need to improve the relevancy," and the search team says, "That's fine.

It's just a little bit of work for us.

We can do it.

We're committing to it but we're not going to have an OKR on it.

We'll just have it listed as non OKR work because we're confident it's not that much effort." How many times have you heard that before? "We're confident it's not that much effort." It generally always needs more effort and so what happens in that world is then you get tension because all sudden the notifications team, they're pushing. They're pushing hard to get this OKR delivered. You run into some trouble which for the search team now, it is actually more work than what they thought and they don't want to deliver on it because they have their high priority OKRs that they're trying to deliver.

And so you end up with this imbalance and you can end up with quite a lot of tension and also work ends up stalling a bit.

So what we've tried to do is we've tried to really, really encourage teams that even if they think it's not a lot of work, they calling it out as OKR because we need to acknowledge the priority that that work has. So then the ugly.

I mean, the ugly was probably having donuts with syringes in them, which we did actually have at 9 am in the morning on OKR Days.

I mean, apparently they are delicious, but I think that was just a little bit overwhelming for people.

But getting into the ugly.

So I think the first point is, the reason that we as SEEK went down this road is because we wanted to focus more on outcomes and we wanted to give teams flexibility on the how and we wanted to make sure that we were ideating and being creative on the how.

But the problem is, that's actually really tough and OKRs alone doesn't do it.

So we saw, we rolled out OKRs.

As a business, we were very deliberate in stopping talking about the specifics of the how.

The teams had to walk through different ideas, and we were like, "That's great.

It's up to you, you work through it," but then, for all the reasons, and I've read the book Decisive that came up before, it's a fantastic book.

For all of those reasons, all of our decision biases that we have, a team will still hone in on a solution really quickly even though they've got OKRs that show that they could be far more flexible.

And so the OKR process is a great enabler for it but then you need to look at your discovery and delivery processes and make sure that you're evolving those as well and that's where we have moved into the continuous discovery process which Theresa Torres promotes quite heavily and educates on because what we found is that our teams actually needed more guidance and some frameworks for how to actually think about multiple ideas at once and how to make sure we're engaging with customers all the time along the way.

The second one is teams will always be too optimistic about what they can do.

So we really try to promote focus and we ideally want like one or two OKRs.

You know, I still have cases now where teams will come and they'll have five or six.

And you say, "Well, this can't all be important," and then they'll say, "But, you know, we're a decent sized team.

We can't all work on that OKR at the same time. So we think we can also pick up these other bits and pieces along the way." And the challenge is one of two things happen. You either split your focus, which means then you actually don't end up making meaningful progress on any of them or you do actually focus on one but then the team actually feels bad and guilty for all of the other things they said they were going to do that I couldn't do.

So how we've tried to get around this is, one, in the OKR sessions, force ranking.

So making sure that the team comes with what is the number one priority and so therefore, all of us as a leadership group are very clear. Well, if reality kicks in and you don't get it all done, that's fine.

We know which two or three are actually going to be the ones to drop but then also pushing back.

Like this is one of those times where it is a negotiation and we do actually really try and push back but I think the key here is, having now watched this for two years across more than 20 teams, people are always overly confident on the volume of work they're going to be done, not always on the target setting.

So when you setting the target and you want to set the key result to be aspirational, you get some teams that are far more conservative than others but when it comes to the volume and the breadth of OKRs they can take on, generally you'll find people are pretty optimistic and you need to help with that.

So, key takeaways.

Drive full team accountability from the outset. So making it very clear from day one that OKRs is everyone's problem.

It's everyone's responsibility and embedding that in all the rituals that you do and all the frameworks that you use within it. Having clear rituals and expectations.

So I've talked a little bit about what works at SEEK. We're quite a large organisation.

Some people would potentially need even more rituals, some would need less, but really defining for your business, what are those kind of minimum rituals that you want to have to make sure that OKRs don't become like KPIs, for example, which they can easily become.

Making sure that if you've got work between teams that where possible, you're making it equal priority because this can cause a lot of tension between teams and nobody needs that in their life to be honest. Help teams focus on fewer OKRs which I just mentioned and then last one is really reviewing and adapting your discovery and your delivery processes to ensure that you move away from solution and output focus. We are humans.

We are designed to have a narrow frame of view, get emotionally attached to things, which is a real gem when you're building products but also, particularly if you've got teams that have been quite solution focused for quite a long time, that transition is going to take some time. It's not just going to naturally happen on its own. And I think that's done.

(upbeat music)