Product Agility
The world of Product Discovery and Creation is becoming increasingly challenging due to mistakes and missed opportunities that are prevalent in agile teams, large-scale Scrum and all other agile frameworks. History has shown that when organisations try and scale their product development to more than one cross-functional team, mistakes are made that cut short many chances of getting all possible benefits.
The route of this for many is the need for more attention paid to the incredible advancements in Product Management driven by hordes of professional Product People who prove that making their customers happier is not a pipe dream but a hard and fast reality.
This podcast exists to explore all topics related to Product and Agility and Coaching.
How do you marry the agile principles with Product discovery?
Is it really possible to have hundreds of cross-functional teams (or Product Teams) all working from an effectively prioritised single Product Backlog and a dedicated Product Owner?
How can you embrace continuous improvement and empirical process control for your product, people and processes?
Ever wondered how to overcome the problems people face when trying to scale the Product Owner role and how it relates to Product Management and Product Teams?
Baffled by how to define a product in such a way that enables Feature Teams (aka Product Teams) and why doing wrong means you will only ever be stuck with technical teams?
Scrum Teams are not compatible with modern product management techniques.
Want to know what Product Focus means and how the right focus makes creating a shippable product less painful?
Need to get your head around how to blend modern product management techniques with Sprint Planning and Sprint Reviews to achieve Product Increments that cover the entire product?
This podcast's original focus was on Scaling Scrum vs Single-Team Scrum and how organisations can reap the benefits of Scrum when working on a larger product but still keeping a single product backlog. We found many Product People liked what we said, and then the penny dropped. This isn't a podcast about scaling Scrum or the limitations of single-team Scrum.
This podcast is for Product People & agile advocates who coach or get their hands dirty with Product creation.
We promise there is no Taboo topic that we will not explore on your behalf.
We aim to transcend the conversations about a single team, Daily Scrums, Scrum Masters and the double-diamond and bring everyone together into responsible teams dedicated to working on the entire product to make their customers happier and their lives more fulfilling.
Come and join us on our improvement towards perfection, and give us your feedback (we have a strong customer focus, too), and who knows, perhaps we will discover the magic wand that we can wave over all the broken agile and sudo-products to create a more resilient and adaptable future by bringing the worlds of Product, Agility and coaching together.
This podcast has the conversations and insights you need.
Product Agility
Avoiding OKR Overload: How to Focus on What Really Matters (With Richard Russell)
In this episode of the Product Agility Podcast, Ben sits down with OKR and strategy expert Richard Russell to tackle a challenge many scale-ups face: OKR overload. Richard, with years of experience at Amazon and Google, shares insights on creating effective objectives without overwhelming teams. If you've felt the pain of unfocused, sprawling OKRs, this episode sheds light on simplifying and strengthening your approach.
Key Takeaways:
- The Pitfalls of Too Many OKRs: How having excessive objectives dilutes focus and overwhelms teams.
- Achieving Alignment Without Overload: Why keeping OKRs lean and clear is more impactful.
- The Role of Strategy: OKRs should be an extension of a well-defined strategy, not a substitute for one.
- Centralisation vs. Autonomy: Find the balance between a unified direction and team-led execution.
- Avoiding Task Overload: How to steer clear of overwhelming backlogs and stay focused on impactful outcomes.
Practical Tools & Methods:
- Setting Priorities with Fewer OKRs: Limit OKRs to those directly tied to critical outcomes.
- The Execution Flywheel: Richard’s unique framework that uses strategy, goals, planning, and review for sustainable growth.
Quotable Moments:
- "OKRs are meant to guide focus, not create it. Without a clear strategy, they’re just more tasks."
- "A few strong objectives will take you farther than an endless list of ‘nice-to-haves.’”
Links and Resources:
Connect with Richard on LinkedIn: Richard Russell LinkedIn
Want more insights on OKRs and strategy? Visit Richard’s website at richardrussell.co for resources and tips on practical, lean OKRs.
Host Bio
Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.
Stay up-to-date with us on our social media📱!
Ben Maynard
🔗 https://www.linkedin.com/in/benmaynard-sheev/
Product Agility Podcast
🔗 https://www.linkedin.com/company/productagilitypod/
💻 https://productagilitypod.co.uk/
🖇️ https://linktr.ee/productagility
Listen & Share On Spotify & iTunes
- Spotify - https://open.spotify.com/show/0lkwAYJzVSuk5zfJ1vIDZq?si=4c691fb12f124a56
- iTunes - https://apple.co/3YvTX8p
Want to come on the podcast?
Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80
Different teams have different OK Rs or different things at work. I always find it funny when someone says I'll assess your OK Rs and just send them to me and I'll give you advice on the OK's. And sometimes there are things that are that are can be helped with in a certain level. But without the context of this, what this business is and what the strategy is, what the team is and what the team's doing and what the nature of the team is and how aligned they actually are and how mature they are, whether they're experienced with tasks or with strategies, with how they understand the strategy, how much initiative they have. And without the experience of who the leader is of that team and how good they are at coaching, it's really hard to actually tune the OK R to get it right for that context. Welcome to the product Agility podcast, the missing link between agile and product. The purpose of this podcast is to share practical tips, strategies and stories from world class thought leaders and practitioners. Why I hear you ask? Well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard and I'm your host. What has driven me for the last decade to bridge the gap between agility and product is a deep rooted belief that people and products evolving together can achieve mutual excellence. Hello, welcome to the Product Agility podcast. I'm back in my little office studio, not at a conference this week. The last 2122 episodes, I think that have come out of all bin from productised and now we're here for a more traditional episode and it's very nice back in my home studio and very, very nice to be joined by Richard Russell. Richard who is ex Amazon and ex Google. So yeah, you should listen because clearly that's a huge, huge thing to be read X Both of those organizations is somebody who I came across via my friend Kareem Harbour. Actually he said, oh, you should get this guy in the podcast. And when I got hold of his okay Launchpad, which is a great little download you can get for you for not a lot of cash. And I thought, actually, I do need to get this personal podcast. So with with this amazing experience of being at Amazon and Google and more recently working with scale ups and working with the exec teams, helping organisations overcome a lot of those kind of scaling challenges that come into place. We're going to be talking about OK Rs today. But before we do delve into it too much, Richard, would you mind introducing yourself in a little bit more depth for our listeners? Sure. So in my background, you may hear from the accent. I'm Australian, but I lived in London for 10 years and while I was in London I worked with Deutsche Bank for a bit, helped create the financial crisis through some technology that I was working on. It wasn't really my fault. And then I went to Google for six years. It was at Google did a whole lot of stuff on advertising with big advertisers like Adsense stuff and then public transport on Maps and Google check Out which is the precursor to Wallet and a bunch of stuff with advertisers. A couple of start-ups then came to Luxembourg where I live now and I worked for Amazon for a couple of years where I helped Amazon DE have multiple languages and various other associated projects with a team of about 100 people. Since then I've had about 8 years independent and I've been working as you said, mostly with scale UPS. So businesses usually they've got some seed funding, not always or at least some seed funding through to sometimes series CD and even E. And occasionally I work with larger organizations, like I work with Vodafone and SLA and Botherwas insurance and all sorts of random companies, CNBC, IKEA. So I've done various bits and pieces with those things, those companies off and on, sort of like innovation topics usually around OK Rs and off and on strategy. So that's what I tend to do. My clients are usually either the CEO or the business unit leader in those organizations. Quite the resume. I like to think so. You know, I've, I've, I've worked on it. Yeah, I've been a real, I haven't been idle for the last like 20 odd years. You've actually been doing stuff. And it's good to know that you also help create financial crisis. You know, I, I, I said did I did I do my part in that? I don't know. I was working in collateral management. You were in banking as well. I think you were a Deutsche Bank at some point. I was a Deutsche, yeah. Yeah, in 2006, I think it was. All we were doing is making it really easy to trade all the, you're using a, a software tool to make it easy to trade all of those things that came up in the news a couple years later. Nice. I remember I was doing collateral management. So we were moving around assets on behalf of pension funds and things like it's a JP Morgan. And I like to think that I was kind of doing my bit to protect the pensions. But I'm, I'm sure I had some, some part in the financial crisis. I don't know. But then that's why a good man, most of like we're working for failing banks. It was a Deutsche Bank and it was all the traders and the, the yeah. And so I was just, at the time, I was pretty much just a minion. So I'm pretty sure you'd either be like, well, no, I'd say wouldn't be in prison because not many people went to prison for that financial crash. But I'm pretty sure it would be coming on my podcast if you were responsible for it. I'm pretty sure he'd be retired on an island somewhere. Yeah. Selling his. Unfortunately not. Yeah, I know. Damn it, if only I destroyed the lives of 1,000,000 because I've never had to retire to say over the last 15 years I've been doing more productive things than my friend. Yeah, yeah. Trying to repent some more. But it's really fascinating because we hear the talk about OK IS when you're also kind of ex Google. And I think one of the ways in which lots of people found out about OK IS and probably part of the reason why they became so damn popular was because Google, you know, released lots of information around this. I think it was part of their rework agenda, wasn't it, Which is going back. God, that's a long time ago now. And, and, and also there was a, a book written about it as well. Yeah, exactly. And I, I just really interested to hear, like, how different was your experience of OK? I was at Google on comparisons. What was publicized? Yeah. So I think it's, it's interesting. A lot of the stuff that comes out of Google is kind of like, hey, Google's really magical. It's like the Chocolate Factory. And we should all copy exactly what they do. My experience, I'm just going to tell you my my experience with. OK. I was at Google. I joined Google as an individual contributor and the HR team of the HR Claire was onboarding us and sort of going through all the different things. How to do your own. Holidays and expenses and all that stuff. And then she introduced, okay, ours and sort of said we have this goal setting system. It's a bit different. We think it's a bit special. Here it is. And I remember thinking, so, okay, you've got goals in some sort of structure with some headings. Well done. It doesn't seem that exciting to me, but I'm glad you've got goals. That's good. So congratulations. I was, I was very cynical at the time and I still, I, I still maintain some level of cynicism, but when I saw this, I was like, OK, that's, that's great. Cool. Got on with life, got on with work at Google and we learned a whole lot of stuff. Now, what was really interesting is as I on boarded to my team, we was talking about talking to people about, you know, what are we trying to achieve here and what, what, what do I need to know? What do I need to learn? Everyone is using kind of the same words about how what we're trying to do and how we measure success and what metrics we're trying to. And we talked about the same metrics. And my experience in previous organizations like Deutsche Bank and some of the smaller businesses and the governments that have department that I've been in before was that whenever you talk to someone, especially as a new person, you get 15 different views on everything. And then you have to sort of piece it together and figure out what's really important. And everyone's focused on on the minutiae, like the details of what they're doing. And what was interesting about Google is that everyone sort of had this good understanding of what are we actually trying to achieve and how do we measure success and why this and not that and what are we doing now as opposed to the last quarter of the quarter before. And as I when I left, one of the reasons I became a manager there as well, I started to use them in that role. But as I left, I sort of figured out what what's going on here. Part of this is about just the management style and management technique and how people manage. But part of the way that that works or the reason that works is because people were using OK Rs in order to create these objectives and key results and and propagate them around the organization. So people were constantly having that conversation about what are we trying to do the objective and what does success mean? That's the key result. And so that was a really useful realization, a really healthy realization that that conscious effort to really define good was it was there because we do this every quarter and every group would do this kind of thing. Now that was my experience of it. And that was like where I learned the value of it. What I found to be less useful about this way, the way the Google does things that I don't recommend people is certainly at the time, everybody, every single team, every individual, every manager had a set of OK Rs. And so every manager would have their accounts and then the team would have a team of accounts and then individuals would have individual accounts. And then you'd be working on a product and then be product OK Rs and be working with a, you know, commercial team and they'd have commercial OK Rs. And it was just like this massive, I don't know, just like so many OK Rs everywhere. And So what the effect of that was a couple of things. One is that we'd spend a lot of time setting OK Rs. And the second thing was that we'd, when you were trying to figure out what to do, you'd have to look at your OK Rs, your manager's OK Rs, their managers OK Rs, your divisions OK Rs, the company's OK Rs, the product area's OK Rs, your products OK Rs, the commercial team's OK Rs, the engineer. And it's not like I have like 45 objectives and that I convinced it as see and interact with and you know. That many times 5 key results and they're not really confusing. And that's the opposite of what we're trying to achieve with the OK, OK Rs. So that's the thing that Google would do. And that was the thing that drove a lot of people crazy about OK Rs at Google. It's just a bit too much. And that's what I advise people not to do now. I advise them to have as few OK Rs in the organization as you can so that you can get the focus. So given your, your experience there was your area, the shipping era was successful like by some measure, but but when it's successful in spite of all of that or, or because of the OK Rs. So here's the thing, when you say successful, I mean Google and that by nature, you know, but we all know the story and it's a very successful company. When I was there, I joined at about 3000 people. When I left it was 50,000 people. Revenue grew, you know, similar sort of pace or faster. Profit grew like crazy. Every product would get a lot of traction. I mean, you know, Google Maps, I was on Google Transit. We suddenly had, we have transit everywhere now. And this is one of the things that I was doing. And so we were able to get that result. Now why were we able to get that result? There's a number of reasons. One is because we had some great people. Another is because we had some great strategies and great products, great opportunities. Like, I mean, you know, if you, if you set up a great search engine and you put advertising on it at that time when there was no other good search engines around, you'll make a lot of money. And Google sort of like just sat on this money printing machine and it was amazing. In a sense, it didn't matter what they do, they make a lot of money, right? And so quite a lot of things happened that had a lot of overhead. Like Google had this 20% time. It's kind of like people going in lots of different directions, lots of new ideas. Some of that's great, some of it is just a lot of waste and you can, not every company can do that. One of the things that I realized when I went to Amazon, I mean, Amazon's margins are much, much lower. They have massive growth rates. But in retail, the margins are like, you know, single digit percentage as opposed to 40% at Google. And the discipline around what are we doing and the productivity was much, much, much higher. And so at Google we had because of that, there's a lot of overhead, a lot of waste, a lot of sort of like different directions. But we had great people. We had people focused on trying to answer that question of what are we trying to do and how good should it be? And we were pretty productive. So it's a bit hard to tell in some sense because there's so much going on there. You can't just look at that and go, oh, they did OK, ours, we'll copy the way that they did them and get the same results because it doesn't work like that. So you are you saying and this is kind of. A little bit, to coin a phrase, blasphemous. Obviously I'm saying it tongue in cheek. And these were blasphemous because radical. On our previous episode, she talks about being blasphemous around OK Rs. But are you saying that OK Rs aren't magic? They're totally not magic. I mean a lot of people, but why? Why, Richard, this makes no sense to me. Surely, you know, I've made a career from selling magical OK Rs that are going to come in and fix something and make everyone just as successful as Google, whether they've got a good product or not. And there's a lot of, and I'm not present company excluded. There's a lot of OK Rs who a lot of consultants or people doing the OK R type of business who love to complicate it. And we, they complicate it because as a consultant, you make more money selling something complicated than selling something simple. How, how do they complicate it? Well, so, so with lots of rules, like, you know, if we look at, if we look at agile and, and scrum, for example, a lot of the, the essence of that is really sensible and simple, But then you start to add complication rules and processes to it and eventually come up with Safe. And Safe is a massive money maker for the people who are selling it. And it's very complicated and you have all these project managers and all these process people designing this system and running this system. So there's a lot of complexity there. So as a, if you're Accenture, selling safe to a big organization is great money. It's fantastic as a business, but it doesn't necessarily help the organization in the way that it could be helped. And so people do the same kinds of things with their cars. And part of it's a bit of cargo cold work. Part of it is just like we complicate it because it makes it easy. It makes it more money, so it's you can do more work, so you get more paid more by making it complicated. So that's one of the things that goes on here. The other thing is that I think there's a lot of people who have this a couple of misconceptions. And one of the misconceptions is we'll just, we'll use OK Rs as a proxy or as a replacement for management. We'll automate our management with OK Rs. If we set the right objectives and the right key results, then magic will happen. And it's very tempting to sort of go in this hands off sort of style and say, I want to set a really concrete objective, clear targets that are sort of like, here's what I wanted to do and here's how I'm going to measure you. And if you don't do that, then you'll, you know, you'll, you have a low performance review or whatever it is. And so then I'll just magically get the results. But the nature of the case is that most of the work that we do in especially in start-ups, product companies, any more sophisticated organization is ambiguous. And you require a lot of context and a lot of other work that is not OK as like OK as help you manage, set this the framework for management help you set the conversation, set up those conversations about what are we doing and how good is it and how do we know it's good? And is this the right thing to do to get that result and that kind of thing. But that active management is really, really important to get it done. And then the third thing I think is also that people use OK as, as if it's a strategy tool, but it's not. So if you try to go into OK, as in with the idea of setting strategy using them, it's really, really hard because the only thing is you're then trying to decide what goals to set. With no guidance because you don't have a strategy. And so separating these things out. So we go, OK, let's set the strategy now let's set some accounts. Let's use the accounts in our management processes with people with context and with coaching and so on to guide results. And then let's assess the results against their expectations of those people. Separate topics, right? That's really the the way that we should be using this in the way that the way it works. But it's a lot easier to present OK Rs as a magical solution. And the book you mentioned, Measure What Matters, has this thing about superpowers of OK Rs. And everyone wants these super powers, but on their own they don't do a lot. You need to have the rest of the management system around it. Yeah, it's funny. I think I've seen and some of it comes from Measure What Matters. Some of it comes from other well known, see well known, known authors and things. And I look at some of the ways that people go about and create OK, Rs and the number of OCS they want to create and they look what they do. I think, I think you've just kind of overcomplicated this a little bit because it really seems like so much hand holding is required to get people to come up with something, especially if it's a first pass. They've never done it before. Yeah. And they make it so complicated and kind of give this illusion of being so difficult and using all these words when actually do you know what, if you have got a clear strategy and people do know what to do and actually coming up with something isn't that hard. Sure, it's not going to be it's not going to be maybe the most lovely polished, like well worded thing, but you know what? That comes from practice. And so I think I really, yeah, what you're saying like they've they've the complicatedness of it or the desire to have five, OK, five objectives or five key results as a standard and have that cascade for your organization. But that does create a huge opportunity to people for people to make money. Yeah, exactly exists with this. The more people need consultants to help them solve those problems. But actually the real solution is to do less, fewer OK Rs, right? It's one of the solutions. And the rest of it is like, let's do some more management, let's do some actual management, let's do some strategy, and so on. I always find if people struggle to set OK Rs, it's usually for two reasons. One is sometimes 3 reasons. One is because the strategy is unclear. 1 is because the organization doesn't match what you need to do, and it's just not to fit for purpose. And people have the wrong kind of unclear roles. And the other one is that people don't understand through how to measure success and what metrics are at all. And this is one of the areas where there's a lot of rules around OK Rs. And it's one of the areas where I think it's really necessary to be very flexible about what works and what doesn't work. But also just to, just to have a, a gut feeling or an insight into how do we actually define good? How do we define success? Like what is the, what is the meaning of success here? And how we would track this and really understanding detail of the work that's going on so that you can come up with a good metric. There we've been on this for a second whilst I indulge myself and tell me if this makes only sense. This something came out my head for AI don't know a good year or so I think. And at the moment it's kind of really in the forefront of my mind, which is when you're working to create OK hours with a collection of people, they use those kind of selection of words quite specifically. And those that collection of people writing an OK R, creating an OK R is kind of end up having a baby. And all babies are unique to the people that create them. I won't go into any more detail than that, but I hope that's clear enough. I've got, I've got three of them and they're all unique from each other. Exactly. Yeah. You know, they precisely, you're never going to create the same 1 twice. Probably. There's always going to be something, a different concoction that happens for whatever reason and that. So I think one thing that I think that people don't understand, and this may be me not understanding it as well, is that each team creates an OK which is very specific to them and it is unique to them. And when you look at different types of collections of people and the Okis that they create, you can almost see archetypes and the behaviours that come from those roles that those people are playing coming out and they're OK are. So if you have a team that have been using Scrum and the only thing to do is focus on what we can do every next two weeks, and then you say to them, what do you want to achieve in the next three months? We haven't ever had to think like that before. And so that when you start maybe working through the OK R with them, some of the things they'll fall upon first are the types of things that maybe they would be talking about in the retrospective. Because those are the problems that they because they're thinking of fixing, because those are the ones that they're used to in the same way that there are. Then you listed a few ways that Okis maybe don't work. The one thing that I see is the difference between a team and a group. Yeah, because when you have a team and they're working together all the time and that's so they have got some of those powers to kind of think into the future, it comes together quite well because it's OK, great. As an entity, this is what we we know what we want to achieve. We know where we exist. We know how we work together, we know how we argue together. And so coming up with something for us to achieve is quite easy when it's a group and actually there is no shared goal. And day-to-day they don't work together and yet they're asked to create an OK. And again, that provides it a different challenge because they've never had to come up with something together before or they haven't got those muscles and how they they can work together to come up with something they can all agree upon and so. I'm not saying that Okis in those particular situations aren't valuable. I think that actually some of the learning that comes out about using Okis in those environments is more for the teams and the groups to reflect upon them and why they exist and what they're trying to do rather than the OKR itself. I don't know if that don't make any sense. There's a whole lot you've sort of covered there, which I think is a lot of it has. There's a lot of nuance and interestingness. One of the things that I've just ripping off the thing you've said it towards the end there about there being a group of people in a team. One of the things that I've found really useful that OK ours is because it's kind of like a thing that we want to do. We want to set OK ours. And then there are some, there are some rules or guidance to do this. And then we try and set them and we have some challenges. What I like to do is use the cows to put the elephant who, which is in the table, this right in the room onto the table. So we go, OK, here's the problem. We've got this challenge here. And so often enough, the problem is exactly that thing. We have these people who are a collection of people. They're not necessarily A-Team. And this happens a lot at executive level like the CEO and their and their reports, because often those people have come up through their functions and they see their first team as being their functional team as opposed to the executive team. Their best loyalty is with their function and their mission and their function as opposed to the mission of the company and the purpose of the company. So it's very hard for them to then. And often people, you know, the natural thing to do when we're doing things, we often think about breaking things down. So we like to have an account for engineering and one for marketing and one for sales and all that sort of stuff. Whereas in reality, if you can pull this together as a company and really understand what the company need is, then that creates the need for collaboration. And that's quite hard for people to do right. But it is actually where one of the benefits is. Because if we're saying we want to have three objectives across the company and they should be cross functional as one of my guidelines, then that's one of the things that really they have to start thinking about company level problems and broader thing and then start working as a team. And then we often get into Patrick Lancioni, 5 dysfunctions of a team, sort of topics like where's the trust and what's the accountability and all that sort of stuff. And how do we actually get to to make sure you're having the right conversations? But I use the Oks and the rest of the sort of management system around it as a tool to make sure that they're having the right conversations and have this sort of almost like an external lever to make them have the conversations sort of to guide them down that path. But then they start to form a team. And you said at the start as well, like different teams have different OK Rs or different things at work. I always find it funny when someone says, I'll assess your OK Rs and just send them to me and I'll give you advice on the OK's. And sometimes there are things that are that are can be helped with in a certain level, but without the context of this, what this business is and what the strategy is, what the team is and what the team's doing and what the nature of the team is and how aligned they actually are and how mature they are, whether they're experienced with tasks or with strategies, but they aren't how they understand the strategy, how much initiative they have. And without the experience of who the leader is of that team and how good they are coaching, it's really hard to actually tune the OKR to get it right for that context. Because the matter what matters here is like. Not is this abstractly a good way of defining success for this abstract function or or team, But what matters is what effect is this going to have in practice in this team with that manager and these collaborators and these people and this strategic context and this background. And I find that so many teams, they're just especially if they've even very senior teams can be, it can be focused on tasks so much because we've, we're, we're very project managing type society. We've had a lot of people have done a lot of that kind of thing. And it's very hard for them to make that jump into outputs. And there's ambiguity between the output and the task. And that piece of ambiguity has to be the thing that the management and the team can actually handle. So sometimes some teams you have much less scope for ambiguity and you need to be more more explicit in defining these are the inputs we want to work on, right? And this is how we keep everyone aligned and this is what we need to do. And sometimes it feels a little bit like a micromanaging, but the really question is, what's the context here? What does the team need? What is the leader need? And what is the context of the organization need? And how much divergent can you have? Because the other extreme is this vague vision peddling where it's kind of, you know, we get this very, very high level output, but there's so many different paths to get there. We have 10 people in this team across the executive team and now we have 15 different ways of doing it. And they're all going in different directions and not aligned enough. And, and if they don't have that maturity to be able to align and face up to those things, you have to be more constraining with them. And so this is what I'm getting at. Like some of these, I use the Ocas in order to highlight some of those gaps. But then also you use the, the way of setting Ocas or the way of talking about them, you tune them to the specifics of that situation because what you're looking for is a way of expressing what we're trying to do and what good looks like in a way that helps me as a leader and the leadership team and the team get the best results. Yeah. And that's really, it's very pragmatic approach. I, I don't believe in strict rules. I believe in like, let's do the pragmatic thing here and then try and improve. I think there's definitely a strong element of, you know, meeting people where they are and understanding that, you know, you're not going to, you're not going to come up with a book worthy OK R and OK R experience if it's the first time the organization's ever done it, because the organizational system is not designed to enable people to, to work in this way. And I think to, to vastly kind of paraphrase what you're saying is that if yeah, when OK R, if you take that team approach to OK Rs and see it as a way to get people to work together, then they part of the goal of using them, I think, which should be to find ways to make it individually beneficial for people to cooperate with each other. Because I don't think that there is much benefit for people to individuals to cooperate in most organisations, particularly at a senior level. And I mean, and that's where a lot of this starts because as you said, everyone has their own department. They are rewarded upon how well their department does and there is no, there's no need. And this is a crisis. But even then in times of crisis, often people then just kind of say, well, you know, good luck, not my problem right now. I mean, apart from, you know, obviously people have got some level of interaction like HR got interaction for talent development and finance, have got interaction for funding things, etcetera, etcetera. But actually on a day-to-day basis, solving problems that help the organization move forward isn't something that these teams have to do. So there is no benefit. Why? Why was that exactly? This is why I think it's really important to set kind of cross functional accounts that represent what the business is trying to achieve. And then getting those people to the people within that organization to actually pay attention to the what they're doing and what each other are doing so that they can get to that result. And I have quite a lot of examples of this. One of them in particular was a company that I worked with. They're a tech startup, about 203 hundred people. And I remember being in one of the early executive meetings and every when the, when the marketing team sort of were talking, I mean, there was a sound at the exec meeting where there was a bit too much round table update, right? But whenever the marketing team was talking about marketing, the VP of engineering kind of literally would just tune out like you're just like, well, that's marketing stuff. I don't know anything about that and just tune out and vice versa. And this happened across the organization with different areas where clearly that's your level of expertise. So I'll just tune out of that and I don't know anything. About it. And So what I did with this is we set OK hours that were very, very cross functional, like we were trying to enter new market or set up a new product or get or you know get traction in a in a with a new a new basically they're trying to go down market like going to self-service. And so there was changes to the product, changes to marketing, changes to sales, changes to operations all across the board in order to read this objective. So we set that objective, which then meant that they had to collaborate. We got everyone to write 11 page plans and the one page plan, the magical part of that is that it's short. So I can read your plan quite easily. And then I got them to ask questions of each other, to understand each other's plans and provide feedback and made the point that, you know, we need to have your engineering analytical mind to put some attention on their marketing plan to see if it makes sense given what you're doing. Does it, is it compatible with what you're doing? Do you have any insights or ideas? Do you understand it? Because if you don't understand it, how are you going to make a product that's marketable with this plan and vice versa? And so he's trying to sort of like have these questions going around. So some of the questions were very simple and basic. And we'll just educate people on, you know, like here's how we do software development, here's how we do marketing. This is what a marketing funnel is, that kind of thing, which was great because now the engineering team understood what our marketing funnel was, right? But some of it was just like you have this, this summer, we're having this challenge, that challenge of what are we trying to achieve here? And some of the engineering, for example, might say, well, we can solve that with this tool that we have. It's really easy and suddenly you get these benefits. And when I had one other customer who had exactly the same kind of situation with them in that they had a problem, everything went through this one system and this one system was really slow. And so they're trying to solve the problem. And engineering was like, we have to solve that problem. We have to rewrite that system. It's going to take us six months for half the team. It's a massive problem. But by setting this sort of objective level of like we need to make it so that customers can get that result quicker and spreading that knowledge around as having people in the same across functions. Looking at it, they found just here's an alternative way of doing it entirely completely consistent that would work. And all we had to do is move, migrate clients from one interface to another interface. And suddenly they, they broke this bottleneck and that saved them like six months of work. But the purpose here is that the whole point here is that we we're solving the actual problem and we're getting people to collaborate across functions by to solve the actual problem. And I suppose that when you're looking at that cross functional OKR. What isn't going to be easy is getting people to agree upon that focus for the next quarter if there is no overarching strategy or mission that people have bought into. Because the marketing team will just choose with the thing that they think is the highest priority for the next quarter, which may not be actually the thing which the engineering team feel is the most important thing for the quarter. So like, how do you then get those conversations happening between that exact team? Yeah. So this is a really common situation because so many organizations think that they have a strategy and they've had a strategy deck. And it's 60 pages and it has lots of pillars and road maps and onions and everything else and all this sort of almost jargon kind of things. And people look at it and they go and they feel like there's a lot of intelligent work and effort gone into that, and there's nothing disagreeable. So they agree with it, but then when it comes down to it actually setting a goal, there isn't clarity about, well, what do we actually do? Like, given that's the strategy, what do we do? And that means that we don't actually have a strategy because a strategy, the whole purpose of a strategy is to help you figure out what to do. If you don't know what to do, you probably don't have a clear strategy. So in when I find organizations who really cannot align on a set of goals like which is very common, we go back to the strategy and I have two main ways of doing this. One, my my first way is, is the way where if they're, if they, you, especially if they think they have a strategy, I just literally get them to align on, let's write it down. And I have a little method of doing that, the one, my one page strategy method. But basically you write down the strategy and I get them to talk about it. And then we discover this misalignment. And because we're setting OK hours at the start of the quarter, we kind of, we can't just have stop everyone. Let's have a strategy retreat and sort this out over three weeks. It doesn't work. You have to literally make a decision. So then we end up sort of getting the CEO or some of the peak leaders to decide something, at least for the short term direction. So that's OK, we're going to do this. And then they use the quarter to really develop the strategy longer term. In other situations, people are a bit more aware that they have a a gap with this strategy. And so we spend more time setting the strategy. What I find is, you know, I use tools like like, like Playing to Win, which is a great book and various things like that, which are really helpful. And what I find is that do we do that? We think we're clear. We go to set the goals and it's unclear which goals to set. So we have to go back and revisit the strategy and figure out, well, where are we playing and how do we win and what capabilities do we need to win that? And what's the difference between what we're doing and what the alternatives are doing? And then that then helps us understand what goals do we set in order to get there. But it really is a, to me, it's a very conscious difference. And so often in those, those okay debates that we so often have when people are trying, when executives are trying to set, okay, ours, the reality is that we're having a strategy conversation now. And So what I do, I highlight that and I say, this is really cool, but this is a strategy conversation. So we need to have a strategy conversation. Let's just leave the goals and talk about strategy. And then let's come back to the goal, come back to the OK hours. Because if you're trying to set OK hours and strategy at the same time, you're using the wrong tool and it just doesn't really work. Yeah. So what advice would you give to people who are perhaps working at a lower level of the organization, who don't have access to the exec team and they are feeling that maybe there isn't a strategy, or maybe they know there isn't a strategy. They're not quite sure what on earth the organization's trying to achieve. So they're working with a team, they're trying to set them OK, but they just can't really come out of anything meaningful. What advice would you give them for trying to OK, sleep better at night or maybe even make a difference? So I, the way I think about this is, is that there's always some sense of strategy somewhere along the lines. There's some priorities that exist and you can listen to that. You can sort of go and you know, if you have your meetings with your stakeholders, with your manager, maybe your skip level, various other people, you start to sort of piece together what you think is important. And then what I would do with this is two things. One is write down the strategy that I think is the overarching strategy for the company or for the product area or the business unit or whatever it is. Just write it down and say, this is what I think we're trying to do. Is this, is this it? And, and literally most people have never seen their strategy written down. And when you write it down and you disambiguate, you remove things like we want to be the best at this or that or anything like that. You make these choices explicit, like we're going to do this and not that we're by not doing that, we're going to be able to do this to that level and be competitive competition or whatever it is. You can make some of these things explicit. So that's one thing which really helps the organization and the management actually clarify what the real strategy is. But the second thing that a bit often that's very hard and it's harder to get access to those people. It takes a long time and there's resistance and especially lower down in the organization you don't have that influence. Then the second thing is to literally write down the strategy as it impacts you, like your area, what your strategy is in order to help what you think the organization needs from you, right from your team. And by writing that down, excuse me, you can at least contact clarify quite a lot of the context that you have. The other tool that's really useful for this is actually writing your goals and writing down what you're doing, what's on your plate, and you do some work to figure that out. You're writing them down as a team or as an individual or whatever you need to do. And then you go to your manager and your stakeholders and say, well, this is what I'm trying to do and this is what I'm not trying to do. And by having that, that good, those goals and or a one page plan of like here it is written down, this is what I'm going to do. This is what I have capacity for. Are these the right things? And you can literally have every time something comes up that someone says, oh, we used to do this, we used to do that. And the other thing, you then bring back your goals and your strategy and you say, sure, we can do that, no worries. What else do we drop in order to do it? And you're, you know, sort of very granular level, very piece meal level. You're piercing together the strategy and assembling it from from those, from that input. And what you'll find is that, yeah, there's often not clarity and there's often a lot of change. And then you have that conversation with like, I've had 16 changes. That's why we're going slow here. How do we actually align on this and make sure we do it? But it's, it is very much a hard slog. Yeah. And I think that's a nice little takeover for people because of the the conversation. Well, if we're going to do this, what's going to drop is one, it's been around since the dawn of time. You know, people always say, well, if we're going to do this, what else can be dropped? Because everyone gets to that realization that they can't just keep on saying yes to stuff. But what you don't often hear is when people say that the reason why those conversations can be successful is because you have a strategy which is enabling you to make those priority decisions. And I think that that's maybe the missing link for some. So perhaps, yeah, if people feel that they're in a situation where they are saying to people, well, if we're going to say yes to this and what are we going to say no to? What needs to drop? And people have said, well, no, it's just a, it's just an, and this is not an all this is the work you're going to do. Then it does feel that then perhaps they're lacking that focus which is born from them, their vision, mission and strategy. So often that is the case that there are that there is that lack in the rest of the organization and it really does hit people in. It hits people exactly with that whole thing of like, let's do everything and you have to do all of the things. And now I'm burning out, right. If I don't have to push back against this, the, the way to deal with that is literally to write this, Write down what you're trying to do, but then also go a bit deeper and write down like how I allocate my time. Like if you can turn that into a calendar or an allocation of time for a team or whatever it is, then it becomes quite clear. Like, do you want me to be working 60-70 hours a week? Is that, is that what we're trying to do here? Because if that is what we're trying to do here, well, at least I need to know that so I can structure my life and maybe change your jobs, whatever the right answer is, right? But I mean, often when people are faced with that, they're like, no, I don't want you to do that. Let's figure out a more efficient way. It's like, well, where's the efficiency we can get here? I need some coaching. I need some help. How do we, how do we get all of the things that you want to get done, done given the resources and time that we have? I don't know how to do it. I need some help, right? And that I need some help is there's one thing, two things that happen there. 1 is you get some help. And the other one is people realize that this is unrealistic. We need to change our expectations and as an individual, as a, even as a manager, even as a senior manager or an executive managing upwards and even as ACEO managing your, your, your investors, managing upwards and setting those expectations of what is actually realistic is partly about being open about well, here's what I'm doing, here's the trade-offs I'm making. Can you coach me? Can you help me? Because this is what I'm doing. I can't do better than this. What to do differently? But then by doing so, you're then helping people understand what the reality is. And people deal with reality all the time because reality is what it is, right? And it's always better to see reality as a manager, as a leader, as a board, right? Oh, we're not going to get all of those things done. Let's now talk about what we should do and what we should not do. Hey, press do, we're having a strategy conversation. And these, as I say, these things happen at so many different levels in the organization. And it's it's, it's necessary to to sort of provoke them. Yeah. And it's that provocation, I suppose, isn't it? And the appreciation that these things can take a lot of time. And and also I think for some people that it's just the appreciation that there's only so much influence we're going to have in an organization. All of us can be as fortunate as you and I kind of working with senior leadership teams to kind of have an opportunity to talk about the strategy making impact. Sometimes people are their hands are tied, they're lower down the organization from a hierarchical perspective and they may be asked to use OK Rs or told to do OK Rs, but actually they don't feel like it fits. And it just ends up being, you know, a sticky plaster, what is actually quite a foundational kind of crack in the organization. Or they'll just keep it on with time, but they're not going to get for too much longer because we are kind of unfortunately running out of time. But what I'm really interested in, Richard, is that you've had quite a career and you've got some great opinions and ideas of what makes OK Rs work really well. What have been the biggest influences for you personally like on the journey, which you could share for listeners so that maybe they can, they could, they can do some Googling. They could, they could, they can buy a book, they can listen to a podcast like, well, how would you? Yeah. What were your biggest influences on this journey for you? It's actually, I haven't done a lot of much thinking about that. So I don't have a great structured answer for that. Perfect. So this is going to be a little bit sort of stream of consciousness. I read a bunch of books about OK House and about management. I've been reading books about management and management theory and practice for the 25 years because I always wanted to be a manager. So that's one of the things that I've just read a lot about. There's a few books here like this one here just there, which is foot management is really good, right? This is by by Andy Grove from Intel. Yeah. So I found that really useful. There's a few others there like systemology or Ben Lamort's book on on the DOK field book, the the field book, I think it's called Christina Vodka's radical focus tools to books like that. But there's also, if you go broader, I mean the thing with. Any management technique and method, methodology or anything like this is that in many ways people are the same as they always have been. Organizations are the same as they always have been. What we're trying to do is it's different, but it's kind of the same, but they always have been. We're always trying to create outputs. Reading books about strategy, books about management, books about execution, books about metrics, books about planning. You sort of piece together bits and pieces around this place. Now they, when I think about this, putting a lot of this together, where the biggest influence was was actually Amazon. And ironically Amazon, at least the part that I'm in, I was in didn't use OK Rs. Most of Amazon does not most of Amazon, there are parts that do, but most of it doesn't. And what I found really useful was that they, Google was kind of like, here's our OK Rs and here's what good management is and go, there's nothing, no other structure around this, right? Amazon is a very structured management context. And so there really is this thing of like, let's spend some time on strategy. Let's articulate the strategy through a document and write it down and read it. And we all read it and we all understand it. Let's gather data and analyse the data and see how that impacts our strategy to see what, what, what are, what are the inputs? How do we understand inputs? Let's write down our plan and figure out, does our plan actually help us deliver the goal? Should we change our plan and all these sorts of things, having them this sort of relatively structured way of doing it? Amazon's quite peculiar in the way that they do things. And they have lots of, lots of ways of doing things that I can't say work well for other people, other organizations, because they're very, very, very heavy duty documents the way they like to write. But what you can take from that is there are methods. And my take on that is I sort of pulled this together into a sort of framework, which is basically set the strategy now set some goals and now sit and write some plans and go back and check if you go as a realistic and go back and check if your strategy is realistic. Now start doing the work like, you know, delegate actions, write them down, track them, all that sort of normal stuff that you do when you're when you're specifying things like delegate them to whole, try and delegate a whole job worth of stuff as opposed to a whole lot of tasks. To people that sort of deliver the plans and then review, review the data, review the feedback, review anecdotes from customers, review what your stakeholders are saying about things and look, compare it to your data and see where it is and use that to then inform your strategy. And so that's sort of five piece, I call it the execution flywheel or management flywheel. It's basically as you keep doing this, each one of these things feeds into the next. So your strategy helps you set your goals, your goals help you write your plan. Your plan helps you actually delegate things. What you've done gives you data, right, to be able to review things. When you review things, you get a better understanding of the picture so you can improve your strategy. So you're going around that sort of cycle and always getting more of momentum. But it also means you have a diagnostic because you can always go backwards. So if it's really hard to set goals, you go back and figure out what this strategy is. If you don't need a strategy, try and understand. The data around your business, the inputs and the outputs, the feedback from your customers, what your customers are actually saying, that kind of thing and all that sort of stuff. So each one of these things, you go and go backwards and forwards in that. And I found that an incredibly useful framework for helping people structure their own management. And in each of these areas, like goals, OK, ours are one of the techniques people used to set goals, but there are others and they're kind of similar. Let me smell goals. There are some similarities there. Management, my directing, there's some similarities there. There's lots of common knowledge that we can use, and we just have to find methods that work for us in our context and our people. I know CARS is great in some ways because people, it's a good brand, people like it. But practically speaking, what we're doing is setting goals so we can write a plan, so we can execute, so we can review it, so we can set a strategy so we can write goals. And you don't get anywhere unless you've got that focus that comes from the strategy. Yeah, exactly. I mean, this is the the biggest gap that I see most organizations have is with the strategy. And that's usually the starting point. Everything is from vision through the strategy. Like what are we actually trying to do here? And that usually comes from understanding customers as and looking outside as opposed to inside. Awesome. Richard, thank you very much for your tips, your advice, your stories. It's been fascinating. It's been over there. So there's a lot to learn for people, you know. And I hope that the listeners, I hope you've been making some notes or you've been making a mental note of nothing else. Let's go and look at some of these books that Richard mentioned. I'm going to be looking at Playing to Win. Actually, that was what I've made. Playing to Win is an excellent book. It's my favorite strategy book. I'll just show you on the screen just because it's this one here by Roger Martin. I found the thinking in here, the structured framework for understanding what a strategy is, to be the most useful way of thinking about strategy I've ever come across. So I use it all the time. I was actually, I was talking to someone who's coming on the podcast. I was talking to them yesterday and they mentioned another book you have from your shop there, Good Strategy, Bad Strategy. Actually that's I've got that here as well. Yeah, they're great books. I think Good Strategy, Bad Strategy helps you understand what, how to write a strategy, how to make it feel right. Things You Win has a bit more depth to it to me. But a lot of these things, if I can leave one thought at the end, please, there's so much complication. You go back to the very start. There's so much complication around so many of these things. And you know, I'm in this space and I can talk about these things for hours. The reality is that most of this stuff is not that hard. The hard part is making the decision. The hard part is making the trade off is actually, actually engaging people, connecting what you're doing and what you want to do with their motivations and, and understanding it and, and solving these communication problems and actually doing it. And the techniques themselves are tools that help you do that. And if you obsess too much over the techniques, it feels very intricate and sort of like detailed and lots of, lots of nuance. The reality is that once you start to understand the framework, the process itself is easy. The hard part then becomes the actual work, which is what it should be. You should be spending time as a leader, not on frameworks, not on tools, not on processes, not on buzzwords, but on your business and on your customers and on your people and the work. You know that's where you want to spend the time. Awesome, excellent. Last words. I will not try and add anything more to that, so thank you very much. Richard. People want to find out more information about you. LinkedIn is the place to go, or is there somewhere else? Linkedin's great. You can find me on LinkedIn, Richard A Russell on LinkedIn, but you can also find my website, richardrussell.co. It's not, unfortunately, itsnot.com. I'm trying to get the.com, but someone's got it and they don't want to say, yeah, just one letter, one letter difference. You know, just see that M Just see that M. Thank you so much, Camille and everyone. Thank you very much for listening. If you do have questions for Richard, yeah, get him on LinkedIn. We're going to be obviously making this episode known to the world via LinkedIn specifically, so feel free to comment on any of the posts that you see going out. Tag Richard and he will hopefully chime in and give you an answer. Or if you are too scared to, he just want to have a chat with me, but just tag me and I will maybe make an introduction for you. So much. Thank you so much for giving up your time. It's EA, but I really appreciate it and I think all of our fair say hundreds of listeners, not thousands yet, I don't think, but hundreds of listeners also really appreciate you giving up your time. It's a great service. So thank you very much. All right, thanks very much. It's a pleasure and there thank you for listening. We're back again probably next week with someone different. Who that will be, I just don't know, but let's leave it as a bit of a surprise for you. So thank you for listening again, Richard. Thank you for coming on. This has been the Product Agility Podcast.