OKR for Tech Leaders - How they actually work (and where they go wrong) with Andrew Murphy

Speaker A: Welcome to Strategy Candy, the podcast that's about doing better work with an incredible strategy, setting and achieving audacious goals, using objectives and key results and building amazing products. I'm your host, Tim Newbold. Today's podcast is actually recording of a live stream we did with Andrew Murphy from the tech leaders launchpad. On, um, this live stream we're talking with senior leaders from different engineering businesses, particularly CIOs and CTOs and these types of people. It was really bringing in a key lens around what does OKR mean for tech leaders? We go into some of the concepts around what you need to consider when introducing okrs, what does it mean for projects and also technical debt and these kind of things. And Andrew also shares a bit of an interesting story where he had a project that he saw go for six months and after launch it was thrown in the bin because it was realized that it didn't deliver any value. And he talks about that one still hurting to this day. So there's a few examples of what we should be avoiding. But also we talk about how you can apply okrs to deliver value sooner, how you can build confidence in the rest of the business around the delivery capability that you have and ultimately how you can create a world class engineering organization. Let's get on with the episode, Tim.

Speaker B: So I always ask everybody this icebreaker, what's your favorite tech gadget that isn't your computer or your smartphone?

Speaker A: All right, this is going to be really bad because I'm meant to be the focus guy and choose one thing. I could only get it down to two things. Is that okay?

Speaker B: Yeah, go for it.

Speaker A: All right, all right. So look, there's the thing that we use every day but we don't know is there. And this is super geeky, but it's called, uh, Firewall purple. And it's a firewall that basically keeps all the bad stuff out of our network. It's one of the best things. You give me a confused looks, I'm like, yes, you need to look into these things. They are amazing. So really good for security and all that sort of stuff. So to totally geeking out and that allows me to easily VPN in and all these sort of things. So I love it. That's m a geek out moment. But really the thing I use absolutely every day is my Apple Watch Ultra. This thing I use to track my running, gym workouts, all that sort of stuff. Sleep, sleep time. It is the absolute bomb. So I'm a bit of a data geek. Shock horror into okrs. And so I like to pull the data and see what's going on and yeah, that's one of my favorite things. So, yeah, two, two gadgets there for you.

Speaker B: For some reason, that data gathering thing does not surprise me at all. We definitely should talk about that personally, you and I, over a beer or a coffee at some point because I'm a little bit of a data holder myself.

Speaker A: Absolutely. Do you have any devices that are tracking what's going on with you? Do you have your orb or your watch or.

Speaker B: Yeah, so I have my smartphone captures everything, but I actually record pretty much everything that goes on my computer. I've got an elgato stream deck that I use to trigger various automations to do various things like. Yeah, I'm definitely showing you my home assistant dashboard at some point and how I capture, uh, all of my data into my own personal data lake. We could spend the next hour on that, but we're not going to, I'm

Speaker A: going to say I'm into that start too. We've got home assistant, but yeah, we're getting well off track here, so we're going to back up.

Speaker B: Thank you, Matthew. Matthew is just saying good day from Colorado. Yes, very snowy. Uh, it's known to snow there, so that is, uh, quite expected. So thank you for joining us, Matthew. Uh, as you can see here, we do have, uh, the ability to show your questions. Uh, so if you've got a question you want to ask Tim or I, please don't hesitate to ask it. Tim and I can just talk for an hour without that, but I would prefer for you to get your value from it. The reason we do this is to help people. And the best way we can help people is you let us know what you want to know about. So if you've got any questions, comments or suggestions for us, please feel free to, uh, post them. Wherever you're watching this in LinkedIn, YouTube or Twitch, just post your questions. They'll come up and we can post them, uh, on the screen and answer them. Yeah, Tim, the first question I ask everybody after the icebreaker, uh, is we're obviously here to talk about OKRs, but we also want to know a little bit about you. But in your case, I think those two things are like quite linked. Can you give me like a history of Tim and also, why are we here to talk about okrs? Why is it the thing that you want to spend an hour sharing with this audience?

Speaker A: Yeah, that's a good question. So I'm going to try and make this pretty quick because there's a bit of story about why I got into this. So it was really back in the early stages of my career. I uh, was doing basically a placement. It was like industry based learning it was called at the time and internship I think is another word to call it.

Speaker B: Uh.

Speaker A: And basically I was working with a variety of teams and after that I wanted to move out of the organization and go somewhere else to get some sort of more experience. Actually thinking about one of the big consulting firms. I didn't end up making that move and I'm glad I didn't. They said look, if you could have any position you wanted here in a junior role, what would that be? And so I end up getting into what was called a business systems analyst role. And no one, uh, haven't seen it for a long time. Anyway, those roles don't exist anymore because basically you, back in the olden days you had a business analyst that would take requirements. What do we need to build for this thing? The business systems analyst would do like a technical design and even getting to a lot of detail code and all this sort of stuff and then that would be handed to a developer. Absolute insanity how it was done. But uh, that's how they did it back then. And for me that sounded interesting because I was talking to business people and tech people and as I was going through the journey of basically creating these system documents around what people should be building, I was asking a lot of questions and going, this doesn't really make sense to me how this is going to work. And we need to be, don't we need to be talking to people actually going to use the system? And again, someone who was pre grad at that point, ah, am I really qualified to be writing pseudocode for senior engineers? And is that really a good idea? And one of the other people, they really did want to help me. They, one of the, one of the senior blokes there, they sat me down and said look Tim, I don't actually think you get how this works. And I'm not sure this is the industry for you. And for me that was a bit of a moment of okay, this is a bit weird. Then dropped the bombshell which was I've been working here for 18 years and not one of the documents I've created has ended up in a system that's being built. And I had this huge crisis. I'm thinking, hang on, and this sounds really bad, but what your last 18 years of your work was a waste of time, it was a pointless activity. And this is what I should expect if I stick with this. And that was a uh, point where I actually really freaked out thinking, hang on, this is what technology is. This is not what I was told at all. And I started thinking about, do I need to shift industry? I started having a bit of this moment of thinking this is probably it for me, for my career, I need to get out and maybe go back to uni. And uh, at that point I luckily got put onto a project. It was one of the first um, sort of agile projects that they were doing at the time. And that was much more about talking to customers and getting feedback and doing things iteratively. And that was where I became obsessed with making an impact. What's the actual outcome of the thing we're trying to do here rather than just trying to deliver a thing. What's the impact? And this was well and truly before okrs was being talked about. They would have been back then and they were happening at uh, Intel. Google had adopted them but there wasn't much more adoption at that point. This is again really quiet in the early days and from there uh, I basically started searching for the right sort of framework. And yeah, for the past sort of 15 years, I'm going to say probably not quite 20, but 15 years I came across okrs and have um, been continuously trying to apply and improve the framework. In the beginning I made every mistake in the book. Like I was really bad at it when I first started, uh, but since then been refining it and really having worked with teams for a while, this is back in 2015, I realized that although we can find different ways to do work faster and better, and this is what I was helping a lot of teams do, was really trying to work more effectively. I was at Seek at the time and we got a deployment down to two weeks from start kicking off a piece of work. Right. And that's about as fast as it can get. But I realized there's no point in doing those deployments if it's not actually making an impact. And that's where I became obsessed with okrs and really got started. Uh, trying to find better ways to think about what problem are we trying to solve, become curious about the problem to solve and measure the impact. So that's a little bit of a long winded story, but that's how I got to where I am today. Obsessed with outcomes and getting teams behind hitting those outcomes.

Speaker B: Yeah, that's great. I love that. I think I'm a big fan of Lean and the kind of um, theory of constraints type stuff but one Thing that stuff often forgets is you can optimize the process as much as you want, but if that process is producing things that are of no value to anybody, then it's irrelevant. At the end of the day, you're just producing more things that people don't want.

Speaker A: Yeah. And still most businesses, this is what they value. Right. They think about. You still hear people arguing about velocity or story points delivered or number of points, another number of features delivered and you really go, well, to what end? And Pendo is a analytics platform and they've got some really great data on this. They looked at all the different SaaS products that basically that been installed on and they're looking at feature usage, what percentage of features were being used. And basically if you looked at features that were rarely or never used, it was about 80% of the features. So the vast majority of the work the teams were doing was.

Speaker B: And this is, people hate me saying

Speaker A: this because it comes across pretty harsh, a total waste of time. These things not only are, uh, they just, you go, we gave it a go and there's no point. It's fine, it's there now, we'll just leave it. That's adding user experience depth to your product. Right. It's getting harder to use now because there's 50 different features that you don't want to use. But now it's basically there as a distraction. So only 20% of features are uh, regularly automated, often used.

Speaker B: And it's maintenance step. You know, you change something, it has an impact on something else. The more features you get this kind of exponential growth of maintenance where you've got to support everything else. So it's not just about the user experience. It costs you more as a business to have a more complicated product. Absolutely. That's the why behind okrs and the why behind Tim. Uh, but we've used this three letter acronym, this TLA a few times. Let's just go into what is it? Not the why, but the what.

Speaker A: Like what is it all about?

Speaker B: Yeah, like first of all, I don't think we've actually said what OKR stands for in the past few minutes. So let's, let's delve into the quick, 2, 3, 4 minute timer on what okrs actually are.

Speaker A: Yeah, I'm okay with that because when I do my training, I tend to not actually talk about what an OKR is until about halfway through. Through. I think we're still ahead of time here. Only 15 minutes in. So OKR, it stands for objectives and key results. And it was a Goal setting framework. I hinted at this before created Intel. It's not new, it's actually from the 60s like all incredible things are uh, and uh, it's been basically developed over time at intel. And a lot of the early engineers and senior leaders at intel have gone on to other roles, particularly adventure capital type roles and they are the ones that have helped other organizations in Silicon Valley embed okr. So Google is probably the most famous. That's when they just started, started. There's basically them in a garage, they had a server, uh, the two founders and uh, a fellow by the name of John Doyle headed on over there and said look, how are you setting your goals? What sort of structure do you have? And we don't have one. He said do you want to try out this framework called Objectives and Key Results? And they said sure, let's give it a uh, go. And so that's how it really became popular. Once you see that the likes of Google, Facebook, LinkedIn, all these sort of businesses like Reid Hoffman, who was the founder of LinkedIn, is a huge fan of them. So you see all these businesses have had a lot of success with them and that has made them very popular. I don't think the format of the OKR is what matters. It's more that it is about driving focus. And so really this is what it is. It's a goal setting framework to get crystal clear on your biggest problem to solve right now. And if we can get the whole business behind solving that problem, or at least a large portion of it, all of a sudden you can see that these organizations do incredibly powerful things. And there's a lot of good stories that go uh, with it, which we can come back to later in the talk if it makes sense. But yeah, it really is about that sort of focus. When we talk about what is in an okr, I talk about a little bit more, a few more components than what a lot of people say. So what it says on the team, you've got your objective, a statement of what you want to achieve, you've got your key results. They're measures of progress. They're basically numbers, uh, that you want to see move or metrics you want to see move. And ideally for a team you're going to have one objective and somewhere between two to three key results. You can have anywhere up to five, but not much more than that. And that gives you some really nice focus. Ideally for a team you do have that one okr. If you read a lot of the content out there, they talk about five objectives with five key results. That's 25 different data points to be tracking every quarter. It's insanity. You'll go mad. So don't do that. So basically what we want to have is that objective, those key results. But that doesn't give us the full picture. So we often have a statement of why is this important? The objective is like a newspaper headline. It's punchy, it's short, it's inspiring. Doesn't always give you crystal clear clarity on why is this important? Because often that requires. Requires a bit more context. So we like to have a why is this important and why now? And also we have initiatives. So often people confuse the key results with initiatives. They might have a key result. One, uh, deliver the MVP of this product. Now that's not a good key result because you might find a different way to solve that problem. And it might not be an mvp. It might be a different process. It might be to stop doing a process. There's all these different ways you can achieve that outcome. So what we talk about is what is that problem to solve? So maybe we're hoping the new version of the product is increases conversion rate. Okay, let's just focus on that. We want to increase conversion rate. How are we going to do that? That might be through an MVP release or something like that. Mvp, by the way, for those of you at home, is minimum viable product. Probably one of the most contentious words out there. But anyway, we often see ones like that. So I talk to it. Yeah, so that's the OKR framework in a nutshell. I want to throw one more thing actually into this, back to that having one area to focus on right now. We started working with Domino's and so there's sort of two parts to Domino's. So for those of you in the States, there's Domino's us and then there's Domino's rest of the world. And that business is, uh, it's an Australian business. And uh, basically 40,000 people from Asia to Europe to Australia, New Zealand, all over the place. And they, at the top level they had uh, seven okrs per quarter. And they were just not getting progress. They were just feeling like they were selling them and not much would happen. And when I first started with them, we took it down. So we got it from seven when I started because I basically started when they were setting the okrs. I'm like, okay, we're not going to course correct this. We got it down to, I think it was around 4 the next time, 3 the next time. Eventually we got it down to 1. And when we got it down to 1, they had 30% sales growth in that quarter. So you can see the power of having that focus. And so that really wraps up what OKR is all about and how it can make incredible impacts.

Speaker B: That's a really powerful story. Just focusing on that one thing drives so much change. That's awesome. We've got a question, uh, some reason Uzma, your name isn't coming in. I can see who you are from my second monitor over there. But uh, Uzma is asking this question. How do you come up with your team okrs and build a relationship between those and organizational okrs so that they are aligned? So as a good, just before you answer that question, can you talk about what the actual relationship, a good relationship between uh, a team's okrs and orgs okrs and how those interrelate as well?

Speaker A: Yeah, it's a really good question. And this is where you see a lot of companies have seven OKRs, right? Is they try and have an OKR for every single team. And so implicit in this question, and it's a really good question, it's actually really important, is okrs should always be aligned. That's not always the case. So what we want to do is we want to have, and typically this, we have an overarching objective and key set of key results for a company. And this is quite often for a quarter. Sometimes companies do it at the annual basis. So uh, it does vary a little bit and varies by context. But you know, let's say quarterly for now. And then each team looks at that and considers how do we align to that. So ideally they're supporting that organizational okr and helping progress that over the quarter. Now the reality is some teams just won't be able to support some of those objectives. Again, a good okr will cover a good part of the business. But there's always going to be exceptions, particularly when you get to a large enterprise. If you're a small startup, it's usually you're all working on one thing that's pretty simple. If you're uh, a 40,000 person business, there's going to be certain things you're doing that sits outside of that. So really it's the role of leadership. And Marty Kagan talks a lot about this in the product operating model around the role of leaders to help connect the teams with what's most important. Right now this is not a command and control thing, it's a context thing. So a lot of people think, oh, we're going to empower the team, we're just going to let them go do their own thing. That's not empowerment. You've got to be able to help them connect with the strategy. So again, your OKR will take a valuable slice out of your strategy. That's what that does for the company for the year. The role of. Sorry, for the year or the quarter, the role of senior leaders then is to talk to each team and say, this is how we see you helping solve this problem. And so it's that sort of context where maybe if we're trying to increase conversion, we can talk to. If I was a, uh, marketing leader, I would talk to my team and go, so look, team, we know that we don't have a great conversion. We feel or we believe or we have an idea that if we can set the context right before a customer actually registers, uh, for our product, we can get them to purchase. Maybe we can also target customers that are more likely purchase a bit more effectively. Right? Maybe you're finding that you do a lot of free resources, but those people don't want to buy something, they're just looking for free stuff. So that might not be a strategy you want to follow. So through that you can come up with an OKR that is focused on what your team's going to achieve that supports a broader organizational goal around conversion. As an example, and similarly for the engineering teams, we might go back and talk to the product teams and go, okay, what can we do? Is it. Can we improve the user experience? Can we make it easier for customers to complete this part of the flow? Do we want to have something that prompts them to upgrade to a paid product, whatever that might be? We can do all these sort of things. And so that context is absolutely critical in a way, and I say this very carefully because I think people get a bit confused by this, because in a lot of the literature it makes it quite, uh, explicit where they say, you've got your organizational objective, you've got your key results at the company level, and those key results become a objective of the team below. That's dangerous to say it like that because often you can cut multiple ways through and often too, you don't want to have an objective that is a key result. Right? Your objective should be focused on what your team can do to achieve and support the company okr. So while that might be true in spirit, in practice it really is. You're just looking at the OKR above you and going, how do we fit into that? And the role of senior leaders is to help connect to the team with their, how they support that. Without that structure it can be pretty confusing for teams and they're making it up on their own. And that's the difference where I see organizations really get aligned and focused on those problems to solve versus those that are teams just make their own thing up and just end up scratching their head why they're not getting progress.

Speaker B: Yeah. Would you say that it is best for the team themselves to come up with their okrs in consultation? Or have you seen negative situations where those okrs have been imposed? What's your experience with that? Those kinds of relationship and kind of power dynamics of setting okrs for teams?

Speaker A: Of course I've seen it go wrong. But the question is, is that a bad thing? This is not about perfection and having it perfectly aligned. And this is where things like balance, scorecard and I'm not going to get into what those are. If you want to go Google that, that's a different thing. It's basically another set of key performance indicators and how you get a business behind a set of goals. Those things are very complicated. They're really hard to do, they take a long time and they're trying to create a really strongly aligned organization and make it perfect. It never works out that way and you spent a lot of time doing it and still not to get it perfect. So the reality is as long as we're directionally aligned, right. So we call about directional, we talk about directional autonomy. As long as we're directionally aligned, moving the same direction. If one team's moving off to the edge a little bit, that's okay as long as we're all focusing on conversion. And this team over here is planning on opening up an ice cream shop. That's a problem. But generally moving in the same direction. Uh, this is where my views differ a little bit to a lot of people. So again, Marty Kagan, he's for those that haven't heard of him, he's a product, he's uh, a thought leader in the sort of product space. He uh, talks a lot about the product operating model. He likes to see a, ah, team get an objective and then the team comes up with the key results. My thing is really to get that maximum buy in. The team needs to understand the problem to solve and then leave them to come up with the okrs. And of course too they can push back if they disagree with the problem to solve again. We can then go and do some more exploration. That gets me onto discovery, which maybe that's a topic for later. But really the team should be able to push back as well and challenge each other. And this is where OKR really is. It's top down, bottom up, goal setting activity. It's not just push from the top. In fact, I work for a large life insurance organization back in 2017, 2018 and the company set their okrs for the quarter and it went all the way down to a junior call, uh, center person who looked at the data and said, hang on, this doesn't make sense for our context. And it ended up going all the way back up the chain to adjust one of the key results. So that conversation is super important and likewise.

Speaker B: Yeah, that's great. I love that. That's such a great example of so many things going right in the culture and the process of that organization that can happen. That's definitely something to aspire towards. You mentioned product discovery and you've said conversation later. Let's hit it now because this is a question that I've got. You're uh, often in organizations, you're not sure what you should build and some people are saying we should build this thing, we should build that thing. Do we really want to plan 12 months in the future? Who knows what the business is going to be like? The market, the competitors. So how does that all play in together for you as a business and as a team go? This is what we're staking in the ground for the next period of time.

Speaker A: Yeah, that's a really good question. So if we think about what is Product discovery is a means to reduce risk. Right. By learning things about what the product should be, we're basically just trying to buy m information and reduce risk. Okr, uh, on the other hand is about focusing and aligning a team on solving a problem and really making sure that you're making progress along the way. One of the key things we talk about is having metrics that are leading indicators so that we can see that we're making progress. You don't want to get to the end of the quarter and find out where you're successful or not. You can't change things you need to know as you go. And this is where if you're in a product team and even if you're not, so a lot of these practices are going to be really important to you. For me, product discovery is often about understanding the reality of the vision and the assumptions we have behind a product vision. How do we know that these are true and what problems do we have? And so you do this by talking to customers. You can run experiments, you can do all these sort of things. You shouldn't be setting an OKR until you've got a pretty clear idea of what problems you want to solve. And people really like nice diagrams. Wish I had my iPad on screen so I could draw this. It's one box to the next, right? And they just want to know it's linear, right? So I do discovery and I set my chaos and I build it and I ship it and we're done. And yeah, it's all fun. It doesn't work like that, right? So we're continuously doing discovery and that's helping us better understand problems, we're better understanding the solutions. So we're doing tests with customers. We might be taking, uh, wireframes or even prototypes of software or even testing real software in production to learn is this a problem worth solving? And once we're validated this is something worth doing, then we go, okay, now it's an okr. And you can continue doing discovery as well, because you still might have assumptions or unknowns that you want to test and validate throughout the life cycle of the okr. And by the end you should have a working product and feature that again, you've released through the way and you've done some really good testing. I'll give you a good example of this that I one of my favorites. So. And it's a little bit cheeky too. So a company called redbubble, I think it's a little bit more popular in the States here, but the really than these in Australia. But the really short version is basically if you want to, if you're an artist, you can get all your stuff printed on cups and T shirts and mugs and all these sort of things. And so they call it a bit of a community for artists. But also you put upload your artwork and then people can download it. It's a really cool website. What they were doing is they wanted to work out, should we add in the Amazon payment gateway during checkout? So in the past it was credit card and PayPal and they thought, okay, do we want to add in an extra option? Does that make sense? And so again, Amazon Payments, um, was maybe is much more popular than in Australia. So they thought, okay, we could spend millions integrating Amazon and doing all the backend processing and all this really hefty sort of stuff. Anyone who's worked with payments knows, uh, that just adding in a new payment option isn't just adding a button. Like it's complicated and it's expensive. And has all sorts of business implications. So they thought, what do we do? We're going to launch a button on the checkout flow and that button says pay via Amazon. And you'd click on it and show a little spinner and go, whoops, Amazon isn't available. But they track that data. They didn't show it to everyone, they just showed it to a subset of the audience. And this is again, this is how you do discovery. They had a bit of an assumption, a bit of a hypothesis that customers want to use Amazon. And sure, you talk to customers and they say, yeah, I really want that, but do they really want it? You know, let's do the test. So the click through rate on credit card, no change. People kept on clicking through on that PayPal, no change. All of a sudden though, a bunch of people who would normally be dropping off would click on the Amazon payment button, get the error and then go, that's it. And they would then bail. So they've just really come in with crystal clear data. We know that, we know the subsequent conversion rates once you've clicked on that button. So we know that if we add this button we're going to get this much extra revenue. And that allowed them to put the button in with a lot of confidence. And they could also do other campaigns and all these sort of things. So you can imagine for them an OKR would look like, you know, really trying to make this new payment opt successful and that would mean marketing campaigns and building the functionality in and all that sort of stuff. That's an OKR where you get a lot of alignment, but also you're doing some good product discovery as part of it.

Speaker B: I love that example because a really important point which you mentioned, but I just want to nail for people listening, is there wasn't a reduction in the sales for credit card and PayPal, which meant it was a really clear indicator to them that this was going to be an increase in revenue, not just a move of revenue from one payment provider to another. And that straight away gives them a really clear indication that they're going to get an ROI and know what their ROI is for doing this piece of work. Whereas if they haven't done that experiment, they might have put all the work in and they're not seen any increase in their revenue. Because you just had people who were going to use PayPal, uh, now use their actual preferred one, Amazon, as such a great point. There's a question that I want to ask that's related a little bit. We've mentioned some Things like lagging and leading indicators. And I want to, my, my background, my experience is software development. Yeah. And I'm a nerd and I love tech and software, I love building software and I love running software teams. And one of the or two of the frameworks that we kind of use within software development are dollar metrics and or space. And these are two frameworks that we use to think about how productive we ah are uh, as engineering teams. And this is back to the conversation we started in the beginning. So for those of you who don't know, the idea behind DORA is we're going to measure these things that are meaningful about the way that we work as engineers. And it's things like meantime to recovery, uh, change failure rates, uh, change lead time, deployment frequency. All of these things that are uh, not necessarily to do with the outcome we produce using the words we were using earlier are more to do with the uh, output that we create. Can you talk a little bit about how those interact with OKRs? Are they good leading indicators and key results or should they be entirely separated from the concept of okrs and thought about us as an internal to engineering? Kind of don't play any relation to the other stuff.

Speaker A: Yeah, you want to set targets with management and then you obviously get whipped if you don't hit those targets. That's my head. No, this is the thing, right? Metrics, any sort of metric is giving us a reflection of reality, but it is only for what that data point is measuring. Right. And so that doesn't actually mean it's measuring what you think it measures. I know that sounds a bit weird but roll with me here. So things like productivity, those can be a useful insight if you've got these different types of metrics. The oldest old school one was like lines of code and we just know how bad that is, right? You know like just. Yeah, we don't need to get into that. So those sort of metrics, right, they can be useful for particularly introspection for a team or self reflection but rarely would I have a target around it unless there's a really good reason for that. And to be honest for this scenario I can't really think of a good great one to be using this. Um, because again so I think Deming said effectively that the moment a metric becomes a target and people's jobs rely on achieving it. Paraphrasing him. But basically they'll destroy the enterprise in order to achieve it. And so what that means is uh, setting targets and making people's jobs dependent on it or Making bonuses depend on it. You get some really weird behaviors. So for me, targets are perfectly fine just as long as you use them in a practical, mature way sense. Right. We've got to be smart about how we do it. So for a lot of those sort of metrics, I wouldn't be looking at something like that. But you raise a good point. Right. We've got these leading and lagging indicators. Let's talk about what those are first. So leading indicators essentially predicting something's going to happen in the future. People talk about it being like headlights on a car. You can see what's coming up. Your lagging indicators are more like your tail lights. Things you can see. That's happened in the past. So if we give an example, if we can increase the conversion rate of a product, whatever it is, could be a shopping cart checkout, it could be a SaaS product. LinkedIn premium pitching. I don't know if they give us more points for pitching their products here. Uh, but we know we increase that conversion rate, that's going to give us a bigger profit at the end of the year. Right? We know that's a pretty good case. Right. In most cases you can map that out. So the conversion rates leading indicator for the profitability of the business. At the same time, the. There's a, uh, more leading indicator which is the number of views on your sales page. Right? Let's say you got a sales page. The more people viewing that sales page, the more likely people are going to click through. The further you go up the leading indicator side of things, the less effective it is as a predictor. So we've got to be very careful about how far do we go down. And I'm actually quite comfortable with this. A lot of people talk about vanity metrics like views on a page and those sort of things saying, that's no good. It's just a vanity metric. It doesn't mean anything. Actually it does. It depends on the problem you're solving. If you're m. If part of your problem to solve is getting eyeballs on your content, then impressions might be what you're trying to hit. And that's perfectly fine. It comes down to what problem I solving. But you gotta realize it's less predictive of a lagging event. Right. Views on. I put a LinkedIn post, I'm like, I've had like a thousand views before. Zero business came from it. I've had posts where I got three likes and I've had two people call me up to do some work with us. So Very dangerous using that as a predictor. So that's where we have these leading and lagging indicators and trying to use them as predictors. You've got to be very careful. But the more leading we can get, the better. I'm curious for your take on this, Andrew.

Speaker B: Yeah, it's what I said earlier. Like I'm a fan of this stuff because I'm also a fan of things like theory of constraints and lean and thinking about the systems of work and the way we do work. Because at the end of the day, if we're producing good outcomes and we can optimize the way we produce those good outcomes, then we're going to produce more good outcomes. And I think they have a place and they have an important place, but they have to be couched with what are we actually doing with this newfound productivity, what are we actually doing with this new ways of working? And if you can't tie those two things together, that's where you're making a mistake. And that's when they become internal vanity metrics. Who cares about how many releases production you've done if those releases haven't added any value to the user, uh, or the business, great. You've deployed a hundred times in the past 24 hours. How many of those have increased any of your business outcomes in any way? It's important because often they're indicators of T dysfunction or process dysfunction or a disconnect between how teams get value out into the real world. But they can often be seen as a means to an end themselves, which I do not think they ever should be.

Speaker A: And this is interesting, right? So for me I, so I look at an engineering team and I minimum bar for me is you're deploying every two weeks, right? And I've literally had this situation pop up in the past couple of months with a customer of mine. Normally I'll talk about who our customers are because we like to have very open relationships here. But I mean the work sense, to be clear, so my m don't get in trouble. My wife. But we know that with some of these bigger enterprises they're a bit more secretive. So I can't say who this one is, but it was a big business and large enterprise and they were uh, looking at trying to embed the product operating model. So part of okrs, uh, is important there, but also really great product practices is what they're trying to do. And when they were releasing it was really ad hoc. And so every six weeks, every quarter, it was massive. And so we basically said we've got to get that down to every two weeks. And that's for me, is a minimum bar for a product team. Ideally it's multiple times a day or a few times a week, but let's just get it down to every two weeks. We didn't set an OKR for that. And an OKR wouldn't have been helpful in that situation. Right. We just knew that as a team, do we want to do this? And the answer was yes. Well, let's just go make it happen. So you don't need an OKR to achieve everything.

Speaker B: Right.

Speaker A: It's about communicating what your focus is, getting aligned behind that. And a lot of the OKRs they're working on deploying every two weeks was actually a set of initiatives to enable them to achieve their goals. Because again, if they're not deploying frequently, they can't actually achieve those customer outcomes. We've had teams where they might be working on a project that takes six months and go, how do I set an OKR for the quarter? And while there are ways, if you really paint it into a corner, you should never have a project that is running for that long without delivering value. You shouldn't have a project that's running for more than two weeks without delivering value. Like, you've got to be getting stuff out in some shape and form.

Speaker B: Yeah. Just to tie two of the threads here, just to tell a little bit of a story. I was working for a large company and we, when I joined there was one of my teams that had been building a feature, uh, for six months. Like they. And the feature went live just after I joined the company and the feature didn't move any of our business metrics at all. And so was shelved two weeks later. And this is as well as being a huge waste of time for the business and a huge waste of expense, it completely demoralized the entire team. They'd spent six months building this thing and they built it really well. They architected it and crafted it and their output was amazing. Like, they, they crafted this masterpiece, but that masterpiece was not something that anybody wanted to buy. That that whole team was just completely demoralized. It's not just about the wise spend of company money. It's also about the people that, uh, have to be motivated to do a good job. And I had to work really hard to rebuild their company confidence and get them to put that same level of dedication into new things because they were worried that those new things were just going to get shelled after they spent six months on it. Again. And that's both the downside of having a six month project and the downside of not doing the product discovery and all of those tied together.

Speaker A: Yeah, yeah. It's an interesting thing that you see where to me there's a few problems popping up there for the team. So the first is that expectation that you've just got to build the thing and get it done and that's going to be successful. So it comes from a place of we're not going to come back and have another chance to fix this up. And this is one of the biggest things that I've seen with teams not wanting to take on tech debt to test uh, stuff out in market. That redbubble example, it took a couple of hours to develop. It was super quick. I think the most part was getting analytics to work properly. And this is also the time before there was good a B testing frameworks where they could easily pop it in with the framework. It was all very manually done but you know they did it and it was very hacky and they just did it to test it out and then they're going to rip it back out again. And so often we get caught in this situation where oh no, it's got to be perfect and it's going to be architectured that it can handle a billion users and all this sort of stuff. And it's not what's that problem we're solving really coming down to allowing ourselves to test stuff out. But that trust has to exist that the team knows they get permission to come back and fix that this up. And conversely the leadership need, team need to have trust in the team that they're going to clean up the messes they're making as well. So there's a bit of that trust. I think the other part too is, and this comes back to discovery, it's about the natural curiosity of your work. Uh, I think we often get caught into just doing the thing. I just want to put this thing out there and it's so much easier to think like that. But actually being curious about your work and why am I doing this and what's the impact of this and why would people engage on a product like this and what would it mean for them? All these really deep philosophical questions. Questions. It feels a bit like a waste of time. But that's how you get down to the core of what problem you're solving and that's where you start creating really clever solutions and products.

Speaker B: Yeah, that's so important. So important. We're getting to the top end of the hour. And I'm going to ask Tim a question in a minute that's going to, I'm sure, be an incredibly quick question to answer. Hint, it's not going to be. But while Tim's answering that, if you do have any questions, this is getting to the point where it's going to be the last chance, uh, for you folks to put your questions in chat and get them answered before the end of the hour. So please do that. Like I said, I want to hear some tricky ones. Uh, there you go. The way you get the best out of this is by you asking questions. So I do definitely encourage you to do.

Speaker A: Sorry to interrupt, mate. But it also helps me learn. Right. It's all these sort of conversations I'm hearing. What questions, what are people struggling with? What are they having issues with? And I can then answer the question here. But also gives me ideas around content and. Yeah, uh, always appreciate questions.

Speaker B: Yeah, no, definitely 100%. Uh, so the very quick question I want you to answer is, we've mentioned this a couple of times and you gave the example of this life insurance company who ticked all of these boxes in having that slow through and have the junior analysts able to impact the all wide, uh, okrs. A lot of the ways in which, I guess those layers of leadership and executives can negatively and positively impact the way that okrs get implemented. What are the things they should do? Um, what are the things they definitely shouldn't do?

Speaker A: That's a really good question. I'll tell you what, I could go on with this for a little bit, so I'll try not to do. Give me a nudge if any questions come through because I know we're at that point in the session. I'm hoping we get a few more. Okay. One of the key things that most really progressive organizations look for in their leaders is not necessarily their background as a leader or the things they've achieved, achieved as an individual, but their ability to coach people. And obviously experience is one of the most important things you can get. But that is useless if you're not a good coach and, uh, leader of people. Right. I think a lot of people that. And this is. You see this a lot in the tech field. And to be honest, I suffered from this in my first job. So I'm quite passionate about this. In that situation where I was told that I need to exit the industry, the senior leader in that role, they were incredibly technical. They were really great technically, but they were not good leaders. And they kept on getting pushed into roles where they just were not effective. In fact there's a whole law and whole different topic about that. But we have these people in these positions where they should not be in these situations. And what that means is that you end up with really subpar outcomes. So with all your leaders, you want to have them both. Great experience but also really incredible coaches. And so for OKRs to work well, when you've got a command and control type culture where people just come in and just say get it done, just do this thing, it's really not an inducive environment for OKRs because the team is going to be fearful if they don't do this thing. They're going to get in trouble and therefore they're just going to deliver the projects. And you don't really need okrs, uh, if you're there just delivering stuff. And in fact this would be like general advice. If your organization wants to become outcome focused and wants to make it an impact, genuinely start working with OKRs. Even if you're a bit obsessed now with the projects and the to do list, you can transition. But if to your core as an organization, you know what I just want to say, do this project and they do the project and it's done. I move on to the next thing. OKRS is not for you. It's going to cause you so much more pain and problems than just going with the uh, just tell people what to do. If that's your style, don't agree with it, but that's fine. Like I'm not in your business, I'm not. I don't own your business. Go do what you do. But if you're genuinely there to make an impact. So you want those leaders who are focused on coaching and so their role is to number one, connect the team with the strategy and the company okr so they know where they fit into it and helping them support to create their own sort of plans. But it doesn't stop there. This is where it goes wrong for a lot of teams. Again, it's this whole idea of empowerment is just letting the team go do their thing. It's not you're there to support them basically going along. We want to make sure that the teams are tracking their okrs regularly. Right. I talk for most teams it's a weekly thing. If it's an important biggest problem to solve right now. Now weekly feels barely enough. Right. Like it should be every week. If you've got bi weekly or every two week cadence, maybe you got sprints or something like that, that's cool. Every Two weeks is fine, but generally weekly. I, I suggest for most teams, executive teams is always weekly. Like you gotta be talking about this stuff weekly. So, uh, the role of the lead is to be coaching the team on having really good conversations, being able to celebrate their wins, talk about how confident they are and where they need support, talk about what their focus is for the next week ahead and if they've got a pretty clear plan or if they're a little bit confused. So that's that role of the leaders to really help guide and facilitate that. So as you can see, none of this is command and control. This is all about conversation, helping the team be successful. And then of course, beyond that, when they're actually executing on their strategies, helping them find better ways of doing it. Uh, I think in Australia we have a bit of a drought of really great product leaders. And this is something where there's some great ones there and there probably are some listening in right now. And so that's great. But in general, product is not a strong capability here. And so I think that is a major gap for us and something where it's hard for people when they don't have a great product. Leaders know what they're doing. But just in general, in business, whether you're on a tech team or not, having that leader that is able to help coach you and train you on, here are some practices you might want to consider for your role based on their experience is really important. So that's where I think those leaders need to come in and help on that journey. And uh, of course, again, at the end of an OKR cycle, reflecting and learning, how did it go, what worked, what didn't, how do we want to improve the framework? The other thing is, people often stick with the OKR framework they start off with, and it's like clunky and it's hard and they don't have alignment with other teams and they just keep doing it going. This is painful. It's like walking along with a, uh, uh, stone in your shoe. If it's not working, change it, make it valuable for yourself. And that's the role of the coach, right? Helping make that happen, connecting the dots.

Speaker B: That makes a lot of sense. I can see how that mindset can be difficult for a lot of people to get into if they come from that kind of commandment, control, mindset. Are there any kind of, I don't know, uh, resources, places you can recommend for people to get into that mindset?

Speaker A: Tech leaders, Launchpad. How much are you going to pay me for that. No, look, I've seen your content. This is why I want to put the course up on your site as well. Because I just thought it's so fantastic what's in there. But definitely I think there's a few different layers. I'm of course going to say come join us. Uh, we have monthly executive workouts. You spoke at one of them. Uh, we're changing the name because some non execs go up. Can I attend that? But it's like workshops where you can learn how to be more effective in your work, a bit better, coach as a leader, all this sort of stuff, uh, how to use okrs better. But really there's stuff that's super accessible which is reading online, checking out. There's a lot of really great books out there. I'm trying to think of one. Give me a moment while I think of the book. But it's basically the guy's name is Bill. He's like the, I think the billion dollar coach or something like that. He's like Coach Steve Jobs and all these sort of guys. So I think it's the billion dollar coach, something like that. I'll have to, I'll have to look it up for you. Um, but otherwise meetups, this is one of the big things I found. I think it's a little bit less of a big deal now. But definitely meetup events where you can go and talk to other people and just hear others experiences. So uh, if you look in meetup.com and your local community, you'll see a bunch of events there. We can go and get that help. But yeah, definitely. I think for me it really is just really leveling up on that sort of stuff. The other thing I'd say is if you jump on our website and download our resources, we have a few things that come through. It's basically here's the resource, here's a bit of training on it. Uh, we then also if you want you can reply and you probably love and I send you how to love. Okay. So having your team love okrs, that talks a bit about coaching. So there's lots of resources out there. You just got to get off and find it.

Speaker B: Yeah, and that's. And uh, that's okrquickstart. Ah dot com. That's the website, isn't it? That's it.

Speaker A: Okr.quickstart.com if you go there you'll see a resources page or we also have okr quick start. I think it's forward slash podcast or podcast. I don't Know, someone can have a look and tell us because we've got our podcast. We also direct people there for all our resources. They're all there for free. We've got free training on there. People can jump on.

Speaker B: Awesome. All right, last question before we finish up. This is another question from us. So I don't know why your name is coming through. Uh, other standard ways. For example, diagrams show the impact of our efforts. So basically I think the question here is, how can Ausmuth demonstrate how her team's OKRs impact the org's okrs? Are there any kind of standard ways of doing that?

Speaker A: Yeah, there's a few different words for it. Uh, there's impact maps or strategy maps. If you Google those sort of terms, you'll find versions of it. We've got one of our own that basically talks about, here's an objective. In fact, there's also another framework called this is more used for product discovery, but it's similar intent, opportunity, solution, trees. It's basically talks about what we're trying to achieve, talks about the problems and solutions. We break that down a little bit. But effectively problems and solutions and then different ways, uh, that you think you can solve that. So basically any of these sort of frameworks, you can actually map metrics to it and talk about, okay, if our strategy is to, uh, enter a new market, what are some of the key numbers that we know are going to, uh, be important for us as part of that strategy? So you can actually have really good numbers in there and then tie into, well, for our team, how do we support those numbers for you, it might be, again, you know, it might be acquiring customers. We're the marketing team, so we know that we can, you know, feed in on power people, uh, number of people coming into the business, uh, number of people filling out forms, all those sort of things feed into that. So that's how I do it more as a sort of strategic planning piece. It's literally. And again, there's lots of different ways to do it, but I just keep it simple. What, what, what's the sort of. What's the strategy? How do we support that? And what are the sort of numbers that we can track to make that happen? And how do our numbers, how do our teams influence those numbers? The other one is good. OKR tools also let you create alignments. So you can actually say, uh, this objective supports this key result at the company level and you can actually expand it down. If you've got multiple layers of OKRs with an organization, you can keep drilling down each sort of layer. So we've got a big defense customer that uses this and uh, you can see right down to the, the frontline team level, how it ladders up the chain. It's a really nice way to visualize and see what's happening. Yeah, I hope that answers the question.

Speaker B: Yeah, I got something out of that. Uzma, if that wasn't an answer to your question, I think it was. Let us know.

Speaker A: Also, people can hit me up on LinkedIn. I think somewhere on. I don't. I'm. You and I are in a different space right now. We're not on the LinkedIn page, but somewhere here you'll see my name. Click on it. Let's connect. You got questions. Always happy to answer questions. That's uh, yeah, again, I love getting questions. Just drop me a LinkedIn message or hit me up on email.

Speaker B: Yeah, and that's a great segue to the end of this. Normally at the end of this I say, where do you want to send people, Tim? But you've basically answered that. But let's just nail it again. Okrquickstart.com that's your company, it's your website, bunch of resources, your LinkedIn page. You post regularly on LinkedIn. You've also got a YouTube channel. What do you want to post on that? Are you going to uh, podcast? There you go. Tim is, is like me. He's everywhere. That's it.

Speaker A: Too many places. But yeah, the really quick version is, look, we got really lucky. I've got an incredible team I work with. Obviously I do the work. It's not like one of those things where I just vanish off in the distance. But we've also got people based in the us, Europe, all around the world. So wherever you are. I'm not going to have many people at Europe at this time. But unless they're uh, up trying to watch this to go to sleep, never know. So, yeah, so we're always up for a chat. But yeah, if you want to chat on LinkedIn, you can check out YouTube. As Andrew said, that's got really. I try and put stuff up there that people can apply. I hate content, I hate talks where it's like, like just a waffle. We make it really practical. We have resources and templates on those videos. Things you can go and do. We've just done a video on uh, basically how to set okrs, how to run OKR Workshop and it's an eight minute video. So super short. Uh, but yeah, we've got heaps how to Embed okrs. A lot of key things you need to think about if you want to bring OKRs into organization. Don't just start doing OKRs. Think about what problem you're trying to solve, taking people on the journey. So all that stuff's up on YouTube, but, uh, yeah, there's loads of ways to find me. The best way, I'd say is just drop me a note on LinkedIn. Always keen to chat. So there you have it, team. That's the end of the episode. So a few key things that I took away from that. So we talked about one of the fastest ways to kill your okrs is have too many of them. So try and always keep it down to one objective with only a few key results. One objective and two key results is more than enough. Particularly when you were getting started. Keep it really simple. Okr, uh, is not going to solve all your problems. So we talk about it being more like a vitamin less than a, uh, medicine.

Speaker B: Right?

Speaker A: It's something that's going to help you be a little bit stronger. But if you've got fundamental leadership issues in your business, it's not going to solve for that. And if anything, it might actually make it worse. So you really got to invest in your people and build up that leadership capability. Now, a lot of people start off with okrs and they come in with, here's the thing we want to achieve. They might even start with a project. I want you to reverse that and work backwards from the problem to solve. Here's the problem that we want to solve. The outcome, what does success look like of solving that? Or how do we know that it's been solved successfully? And then step backwards from there. Work your way backwards to understand what are those key things that you need to do and how would you measure success on that. So if you start off with that way, you're going to create meaningful OKRs that actually help you deliver value in your organization. If you want to get more content, you can jump onto our website. So okrquickstart.com podcast. We've got a whole bunch of material there. If you found this valuable, I'd love it if you could leave a review. It's the best way for me to learn about how do I make better content. What topics are you interested in? How can we do better? I'm always keen to hear from you. Otherwise, have an amazing rest of your day. Stay awesome.