Master OKRs & Product Flow @ Scale (With Jeff Gothelf & Daniel Terhorst-North)

Daniel North and Jeff Gothelf, two legendary figures in the world of agile and product management, bring a wealth of experience and insight to our latest podcast episode. With backgrounds spanning several decades and a plethora of roles from development to executive consulting, both have profoundly influenced how organizations approach product development, delivery, and organisational agility.

Daniel on LinkedIn: https://bit.ly/3XhVKAq
Jeff on LinkedIn: https://bit.ly/4ehrCuY

In this episode, Daniel and Jeff delve into the intricate dynamics of operating a product business at scale. They explore the unique challenges large organisations face in competing with nimble, smaller companies and share transformative strategies for fostering innovation and agility within a corporate structure.

Daniel and Jeff also share their experiences working with top-tier companies, highlighting both the successes and the common pitfalls encountered when implementing agile practices at scale.

Key Highlights:

🔍 12:45 - Importance of Cross-Functional Teams

🔍 22:10 - The Role of OKRs in Driving Alignment and Focus

🔍 35:50 - Overcoming Resistance to Change

🔍 47:30 - Real-World Examples of Successful Agile Transformations

Listeners will gain invaluable insights into how to overcome common barriers in large organisations and implement effective strategies for enhancing product delivery and customer satisfaction. Join us as Daniel and Jeff share their extensive knowledge and practical tips, equipping listeners with the tools needed to achieve unparalleled success in a competitive marketplace.

Tune in to transform your organisational challenges into opportunities with innovative strategies and expert insights from two of the industry's most respected thought leaders.

Jeff's book, 'Who Does What By How Much?: A Practical Guide to Customer-Centric OKRs' - https://www.amazon.com/dp/1732818444?language=en_US&ref=cm_sw_r_mwn_dp_HWFHSM6KYPQ07JQMEBM9&ref_=cm_sw_r_mwn_dp_HWFHSM6KYPQ07JQMEBM9&social_shar

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

🔗 http://bitly.ws/GFwi

🐦 http://bitly.ws/GFwq

💻 http://bitly.ws/GFwz

Product Agility Podcast

🔗 http://bitly.ws/FdVJ

🐦 http://bitly.ws/FdVT

🤳 http://bitly.ws/FdW9

🎶 http://bitly.ws/FdWj

🎥 http://bitly.ws/FdWy

💻 http://bitly.ws/GFuS

👤 http://bitly.ws/GFvy

Listen & Share On Spotify & iTunes

• Spotify - https://spoti.fi/3XzuzND
• 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

Transcript

0:02

Uh, oh, I need to get my podcast brain on. Are we ready? Anytime you want to redo anything else, just let me know. We can always just leave nice clear marks so I can get back and edit nicely. Okay. Hello and welcome to the Product Agility Podcast. I am your host still Ben Maynard and today I am honored, humbled, nervous to be welcoming to people that I would say at least in my eyes are... Legends people that I admire greatly and I'm just so excited having both here. It seems like a Strange dream to think that back in October or November I met Dan North for the second time or toyed down to horse nor for the second time ever at a conference and we were talking about many things we released an episode after the conference and it's kind of led to this today So yes, it was a huge pleasure that we have a Jeff Cotthell and a Dan to horse north joining us today for a very special episode. Jeff, Dan, welcome to the podcast. Thanks very much. having us. Wow. And don't worry if we talk over each other, it will happen. It's the joys of having three people on the podcast. We had an episode come out a few weeks back and there was four of us. And that was a nightmare to edit. Oh God. That wasn't too bad. Anyway. So for those people out there that perhaps haven't heard of either of you, I mean, where the hell have you been people? But for those people that haven't, I wonder, could we get a short introduction from you? both and perhaps we can start with Jeff. Sure. Hey folks, my name is Jeff Gotthelf. I have had a career as a designer, a product manager, a team leader, an entrepreneur, an author, a consultant, a coach, keynote speaker, all these kinds of things. These days, I focus heavily on the practice of product management and product discovery and objectives and key results. I've co -authored a book called Lean UX with Josh Seiden and another book with Josh called Sense and Respond and Josh and I are writing a third book together called Who Does What By How Much, which is about objectives and key results. And I tend to work with large organizations, primarily mid -sized large organizations, helping them put the customer first in all of their product practices and try to help them become sort of more nimble, more agile, more responsive to the realities of the world as they change quickly around. Jeff, thank you very much. And Dan. I'm not going to be nearly that eloquent. That was beautiful. Could I just copy that and just change the word product for software? Although I haven't, I've yet to complete a book. Okay, so I've been in the technology space, I guess, for 30 years. It kind of breaks into decades. The first decade, programmer. writing software, various different companies, different roles, different kinds of so being an employee, being a contractor. Beginning of the 2000s joined ThoughtWorks International Software Consultancy as their first tech hire in the UK. So they opened a London office and there were a little handful of us. And we grew that to like 250 people over a bunch of years, which was really exciting. So I was a consultant there for the best part of a decade. And that's where things like behavior driven development happened, continuous delivery. It was a very, very exciting time in terms of how work works, if you like, in the technology space. Left there at the end of 2009. And then when I worked in a trading firm where I discovered that I can still code, which was nice, and that I was able to consult myself out of a job. So. So. I was in there as a developer and then kind of working with the CIO on helping him improve his organization. Very, very smart guy. Again, medium -sized trading shop, I guess, at 500 people. And it was all a little bit complicated in terms of how work works. And we managed to simplify that over a bunch of time to the point where I kind of no longer had a job. So I left. And then for the last 12 years or so, I've been independent. So I go into again, like Jeff medium to large organizations and cause mischief, but I tend to cause it on the delivery side. So I'm looking at technology. I'm looking at ways of working. I'm looking at org structure. I'm looking at teams, looking at leadership, looking at connecting people across the organization into like practices or guilds or communities or whatever your, your favorite term is. And. And I had the absolute luxury joy pleasure of working with Jeff for a good couple of years, relatively recently, where the way I like to think of it is he's the do the right thing and I'm the do the thing right of the setup. So yeah, I've failed to be right. I'm failing to write a book after 10 years, which is now morphing into two books that I'm failing to write, which is great. Nothing like scope creep. If you can't build one feature, build two. stop starting and start finishing. No, start two things. Start more things. And yeah, so so and these days you find me again just about to I'm on the on the cusp of annoyingly it's not ready for today, but on the cusp of so what I've been doing for the last 10 years or so. I'm in the very exciting process of turning that into a thing, if you like. So mostly to get what I do in your organization, you hire me, which doesn't really scale because there's one of me. So I've been trying to kind of articulate what it is I do and how that works, which is pretty much ready to go now. And then that will be, I'll be working with a very small number of like brilliant partner organizations where how I do things is a product. So I'm excited to be nearly launching that. So that brings you right up to date. Thank you very much. And I'm going to make sure I use the choice quotes out of what you said there, Dan, like do more things. Jeff saying, do two features instead of one. That kind of thing is absolute social media gold. Yeah, yeah, just a message. context, Jeff Gotthalf needs to be a meme. Check. I would never do such a thing. So we had a conversation before we began and we just spoke about perhaps where we can start this conversation and where we ended up as a jumping off point so we can talk about the things that I suppose are relevant to your experience of you guys working together. But also your transformation as a service, perhaps Dan and Geoff, your new book is the question of a statement when you're looking at operating a product business at scale, how do you do it in a way? which allows you to compete with much smaller organizations. And I think that one of the interesting things you were saying, Dan, when we were kind of warming up for this is that when you are a large company, maybe for a long time, it was all about the, it's all about relative speed. For any company's relative speed, you don't have to be the fastest. You don't have to be faster than the competition. And when such large organizations have been disrupted by smaller people who can get to market much quicker, then all of a sudden that relative speed is much quicker than it ever was before. And how can large organizations then, be it put themselves in a situation where they can actually compete with these much more nimble, smaller organizations. And perhaps we'll take that as a starting point. And Dan and Jeff, I will throw it over to you as to decide where we begin. So I'd like to start, there's a lovely quote, and I don't know who to attribute it to, probably Einstein or Mark Twain or someone usually. But the idea that innovation or invention isn't about seeing new things, it's about seeing exactly the same thing that everyone else sees but in a different way. And one of the epiphanies I had over, I don't know, a bunch of time is that it's not about big and small companies. like the fact that small companies can go faster isn't because they're small. And the fact that big companies can't go fast isn't because they're big. It's what tends to have happened, and this is classic management theory over the last probably century or more, is that as you grow, as a company scales, it scales by specializing. So you have engineering, you have sales, you have marketing, you have... was just getting to the good part. you know, all of these things. And they all have leaders and they'll have hierarchies and they'll have reporting lines. And then you end up with incentives in each of those areas. So you have marketing has incentives and engineering has incentives. And what Ellie Goldratt was talking about in the 80s and then Don Reinitsen in the 90s with the goal and product development flow respectively. is the idea that value creation happens across those organizations. Value creation is sales and marketing identify the demand, the need, engineering or manufacturing or whatever builds the thing that meets that need. And there's all these feedback loops. And if you have that, then you have flow, what's what they call flow, product development flow. But we don't structure organizations like that. So the slowness isn't a function of size, it's a function of being the wrong shape. And effectively, if you can make an organization the same shape as a small startup, but you can have a bunch of those operating, you know, quasi independently, then guess what? They can go as fast as a startup and they have the benefit of this brilliant hive mind. Right. So that means that they can, they should be able to innovate at, you know, the large organization should be able to innovate faster than any of its competitors because it has this enormous institutional learning. this enormous wealth. The problem that most organizations have is they have no way to store that. If they can store it they have no way to tap into that. They have no way to do any of this in a timely way and and they blame that on size rather than structure or habits. So that's my pitch. thank you, Dan. So Jeff, thinking about that, I mean, if you two are kind of two sides of the same coin here and Dan's looking at the organization and the engineering and that creation element here and Dan, you're bringing that, sorry, Jeff, you're bringing that product lens. Like, what do you think of what Dan said? Like, is that, does that ring true? Is there more that needs to be added? So I was gonna talk about learning as well. I think that that's part of the reason, right? So an organization that is big is successful. And with that success comes confidence, maybe perhaps a bit of arrogance, but certainly a sense of we know what the market wants, we know how to deliver it, and we know how to keep this machine moving forward. When you build learning into the process, as Daniel was referencing, it... challenges the hierarchy. It challenges that confidence. It challenges that arrogance because all of a sudden you might learn things that conflict with the prescribed direction or with the general sort of beliefs of the organization. And what that forces is a forces of reckoning with reality, which a lot of organizations don't deal well. They don't deal with that particularly well. because it means that somebody, and typically it's somebody with some kind of power or authority, has to stand up in front of people that work for them and say, I was wrong. They have to admit that they, I had this idea about going this way. It turns out we've built this learning engine into our work. We figured out how to operationalize it, how to share it, how to store it, et cetera. And what we're learning is that the direction that... we've chosen and by we it's ultimately I have pushed us in, right, is no longer the right direction. And we need to change course. That happens so rarely, right? This idea that we can change directions significantly, right? Like varying, like, oh, we're gonna make it red, we're gonna make it blue, we're gonna move the button three pixels to the left or right. That stuff still happens. But the more sort of fundamental decisions, we should not build this. right? Or this isn't going to deliver the expected return on investment or the value. Those conversations are still so rare. One of my biggest clients right now is a multinational financial services organization. They're all over the world. You know them. And I've now worked with, I've been working with them for a couple of years. I've probably met a thousand product managers, at least in those two years, right? Every single one of them. How do you decide what to work on? someone tells me. What happens if you decide it's not a good idea? Well, we ship it and then we see what happens. Okay, and if it's a bad idea, after you've shipped it, what do you do with it? Nothing, you just keep working on the next thing, right? To me, this is where that time to market breaks down. This is where that organizational agility breaks down. It's this unwillingness to, everything works on these, at very least these annual cycles and this unwillingness to break that cycle. and to humbly admit that, you know what, this wasn't the best idea. And so before we go pouring another nine months into it, let's pivot, let's change course, let's do something else. It's so rare. And that hinders these organizations. It's incredible how much production is incentivized and how risky it is at least perceived to be wrong about your organizational prediction. Hmm, it just reminds me. Go on, Dan. that came to mind as you were sort of talking there, Jeff, one of failure and one of success, both from back in the day. So IBM was one of the great technology innovators of the 60s and 70s. They invented, they came up with one of the first databases. It was a hierarchical database called DB1. And the idea was that you would model your world as a hierarchy because we just think of the world as hierarchies and your products and your whatever it was, your business processes, and you would put them in DB1 and it would store all your data. And one of their research fellows, like one of the most senior people in IBM at the time, a guy called Ted Codd, Edgar Codd, came up with a different way of storing data, which we now call the relational database. He said, what if things aren't hierarchical? What if they... What if things can relate to each other and back and forward and they can be connected and it's not quite what we thought? And they built a database model based on Ted Codd's ideas at IBM and they called it DB2, obviously, because it's the successor to DB1. And then IBM promptly sat on it. They said, what are you doing? They said, well, clearly if we ship this and it is amazing, it's going to cannibalize all our DB1 sales. And that's a different line of business. There's a different, you know, VP of DB1, who's going to be very unhappy that the VP of DB2 is stealing all their sales. So, so again, you know, Conway's law to scuppers everything. One of the lead engineers on DB2 rage quit, his name's Larry Ellison. He then went off and set up a competing organization, which you will know as Oracle, which... took the relational database idea and turned it into a product, got it to market before IBM decided to release DB2, and did okay. So Oracle only exists because IBM's executives couldn't see that the market was data, not DB1 versus DB2. That's my counter example. My success example is, and I love Andy Grave because he's also the progenitor of OKRs and a lot of other really cool ideas. is the story of him and his, I think CTO at the time, more, sacking themselves. So Intel was a memory company, they were a very successful memory company, and they could see that the market in memory chips was diminishing. They were still leading the market, but they could see the market was gonna diminish based on competition. But they and their executives are all doubling down on memory. And he had a meeting in his boardroom and he said, right, if this wasn't our company, say you and I came in and you just inherited this company right now, none of the history, nothing at all, just what you can see in the market, what would you do? He said, well, I'd move to CPUs. CPUs are the future, memory is going to become a commodity, CPU is the differentiator. And so Andy Grove said, right, I'm going to sack both of us. So he sat both and they left the room, came back in, said, right, we're gonna pivot, we're gonna become a CPU company. And that decision, in their incumbent form, they knew they couldn't make. They had to kind of cut themselves loose and say, right, imagine this is a new company. Imagine we've just been parachuted in as the CXOs of this failing memory company, what would you do? And that gave them the kind of the free head space to say, we just need to... There's a massive sunk cost and massive retooling and whatever else. It's still the right thing to do and became the most successful CPU company in the world. Brilliant stories. A few thoughts walked through my head. One, so Maya Iqod went to the same school as one of my friends and they grew up on the same island in Dorset, a place called Portland. So there you go. So there you go, which is what just made me smile when you heard that, made me think of my old friend Andy. Also, have you ever seen the BBC documentary, the spaceship that fell to earth, the shuttle that fell to earth? Have you seen this? It's about the Columbia disaster. And I was really thinking about, Jeff, what you were saying because... in the documentary, they interview people. And obviously with Columbia is a tragic story, but when it took off, it lost some, lost a plate, basically some shielding, which meant that when it came back into earth, it wasn't going to survive. And all the analysts on the ground, you could see this, who were charged with understanding just what's the likelihood of X and Y happening and what are the different scenarios. They said, we need them to look out the window. If they look out the window, they can tell us what's missing. We might be able to come up with something. And the bosses were like, no. We can't tell them, they can't look out the window and have a look at it. And they're like, but we were literally running simulations and coming up with hypotheses and we could actually, we might be able to save this if they just looked out the window. Nope, nope. And then when they're interviewing the, the born particular analyst, they're like, why didn't you just talk to the big boss? Why didn't you go? I said, that isn't how NASA worked. Yeah, it has to get a chain of command. And yeah, I, I tried to speak out and then I was reprimanded and I've got a mortgage. I've got kids. I couldn't lose my job. Yeah. there's, yeah, and that was, that was people's lives. And so what I wonder is like, it's, I can't disagree with, with everything you were both saying around what these big organizations can do, but it's really hard because of the humans involved and some of the hierarchies there and they exist. And so I'm wondering, is it given your collective experience, like what are some of the most impactful interventions you can make in those contexts to actually begin to kind of turn things around? You know, it's, I feel like I've been saying this for a thousand years. The easiest, yeah, you know, it's interesting. Like the most powerful thing that you can do to start to change the mindset is put these decision makers, these sort of infallible, high ranking decision makers in front of customers, just to have them observe customers, watch a video, do a conversation, meet some folks, talk to them. It's incredibly powerful to see what people actually do with the products that you deemed absolutely necessary. And sometimes it's nothing, right? But to get that actual feedback and there's no, you know, because it's one thing if a middle manager says, hey boss, this was a bad idea. But it's another if the people that you're actually selling to repeatedly saying, I don't use this, I can't figure it out, I don't know what this is for, why would I pay for this, right? All of these types of questions. There's absolutely nothing more powerful than that. years ago, I worked at a company called the ladders. The ladders was a job board and made it connected people who were looking for jobs that paid more than $100 ,000 with employers looking to hire them, basically kind of an executive search version of a job board. And what they found out was that the richer the job description, in other words, the more the more words there were in a job description, the more likely it was to get applications, people applying for that particular position. And that's a dating site, basically. You've got to connect these folks together, right? And so one thing that the boss decided to do, the boss, CEO, founder type of individual, he would routinely come down from his office to our production floor and say, with these epiphanous shower moments and be like, I know what we have to do today. Everybody turn left. Right? And so one day he's like, look, we got to add more, we need more robust job descriptions. We have to put a character, a minimum character count on the job description. Okay. We implemented the minimum character count and then we went looking to see what was happening and the change wasn't having the impact on behavior that we were looking for. And so we had to figure out why and we went and we talked to some folks and it turns out that for a lot, not the majority, but for a lot of our jobs, especially because they were senior positions, the positions were niche enough and specific enough to where you could get the point across fairly quickly. You didn't need to write seven paragraphs of text to describe the position. It was fairly niche. And what people were doing, and this is incredible, we had a rich text editor on the website. What people were literally doing was they would put in the required information about the job. but then they'd still have some characters they'd have to fill in because they could, the submit button wouldn't turn on until the minimum character count was hit. They would type in white text on a white background, just nonsense, to hit the character count so that they could submit the job, the job request, right? And there wasn't one person or two or three, there were dozens of people doing this. And simply talking to these folks and filming these short 90 -second video clips and then just... putting them up on a screen in front of the CEO, it's like, look, we can't continue to work this way. You're just making us build stuff for no reason. Let's at least figure out what's driving some of this before we start throwing features up there. And to me, that's how you get folks to start to pay attention. It's the only way is to say, look, the customers say X. Everything else is out the window. The customers say X. I'll tell you another really quick and really sad story to illustrate this point. I did work years ago with one of these financial, with a bank. Let's just call it a bank in the United States. And I was working with the Android app team. And the Android app team was, they were building the app and the CEO, he was super unhappy, that's not CEO, but whoever was running that business unit was super unhappy with it. And he kept coming back. He's like, well, I saw this on an app that my kids were using. So I want you to add this to the mobile banking app. And I saw this on another app that I'm using. I want you to add this to the mobile banking app. And no matter what they did, no matter how much they pushed back or showed him research or whatever it is, it didn't work. It didn't work. And the only thing that this executive actually paid attention to was reviews in the app store. And so what the team did, and this is kind of brilliant and sad at the same time, is they went and they put fake reviews in the app store that were based on real data that they'd collected doing research and talking to customers, knowing full well that the boss would read it. and then be like, oh, people don't want this. I have to change my mind. So whatever it takes to get customer opinion in front of leaders, to me, that starts to shift the mindset. Thank you, Jeff. And Dan, what's your most impactful intervention? What can you think of? So I think, I mean, this is something I do very deliberately quite a lot, is a lot of this is about identity. So it's how you define yourself. And if you define yourself as the person in charge of all these people, and actually you could be running a much leaner organization, but you like the idea of having a huge fiefdom, a huge kingdom, then you're not really gonna be open to that very much. So, or again, owning this huge product with all these features. And we're talking actually on the LinkedIn's recently that I didn't know this, the calculator on, I think it's on Windows, the calculator was buggy and it was buggy for decades, like properly decades. And no one ever bothered fixing the calculator on Windows, this buggy calculator, because it was never a priority. and then you go back in history and it turns out that the reason that Windows had a calculator is because it's an operating system it had to have a calculator so it was just parity right it was just no one would take an operating system seriously that didn't have a calculator so they just wrote the simplest crappiest calculator they could have as I could check the calculator books done so two things one is understanding motivation right what what's in it for them why are they doing this? And another part I found very effective is if you help someone realign their identity, if you like, their definition of good, their definition of success. So, you know, in an organization, the classic one, the one that I come to again and again and again is utilization versus outcomes, right? You know, just, you know, outcomes over outputs. So... you know, I've, I an awful, a depressingly large proportion of senior execs in large organizations. They, you know, we're hiring these expensive people. We want to keep them busy. Right. I want to look at, you know, keystrokes. I want to look at, you know, activity. I want to see that if Ben is spending any time, toilet breaks, let's do those in your own time, right? Let's think about how to keep my people as busy as I can, because that maximizes my, my return on investment. I want to sweat my assets. And, just the red pill moment, if you like, of when you explain flow and you explain throughput and you explain the time to value. And in order to optimize these things, you need to look at the same organization through a different lens. Don't look at how busy the workers are, look at how the work items are moving through the organization and where they're getting stuck and why they're getting stuck and what we can change in the organization to unstick them. And you see that, and it is an epiphany, it is a sudden realization moment. In Buddhist school it's Satori. It's like a moment of like, whoa. And I remember this with one exec at a big bank, because Jeff and I attend to work in big banks. And this was a three, pardon? Capital B, capital B. yeah, yeah, this was probably one of the most capital B's you can get. And they had in there what they call securities operations. And securities is anything non -physical in a bank that trades. So this is, you know, stock shares, options, futures, bonds, all the stuff, all the contracts, anything that's basically not, you know, pork bellies or orange juice or whatever is called securities. And securities operations is all of the unsexy stuff that happens when you're done trading. So it's taking all of the trades and all the counterparties and making sure it adds up to zero. And it never adds up to zero, right? And netting. So if I've done 300 trades with Jeff and he's done 300 trades with you, we can figure out that actually I just need to write you a check, Ben, and we're all square. So that kind of work and tax, right? It's really dull things, but necessary things. That work was, they had 3000 people doing that in this huge bank. And the exec that hired me into there, he said, the reason I wanted to work with him, he said this lovely thing when I first met him, he said, I'm looking after a 3000 person operation in this bank. And I'm usually the next thing they say is next year is going to be 5000. He didn't. He said, Dan, I'm embarrassed about that. He said, this is not a 3000 person problem. It's probably a 300 person problem. But we made it a 3000 person problem. I'm trying to figure out how to you know, what do we do? And they'd had all the big methodologists and the big frameworks and blah. I'm usually people's last attempt. Last time we tried everyone else, we'll try that Daniel guy. And I showed him his organization. I showed him where stuff was getting blocked. And within a year, we doubled throughput, like doubled the amount of business change that was happening in a year, halved lead times. Anything that came into the department got done in half the time. in less than a year. Same people, same tech, it wasn't a complete rewrite of all the technology stack. You name any technology in the last 40 years and the answer is yes. They are very, very complicated and very, very legacy estate. And still in the context of that, we doubled throughput half lead time. The following year, because now folks were getting the hang of it, we did it again. So now you had four times the throughput. Anything was taking a quarter of the time it did two years ago. And it was just by changing how they looked at work and how they thought about work. And the great thing when you do this is you get this sort of win, win, win. Cause guess what? People aren't a hundred percent utilized. They're going home on time. They're seeing their kids. They're getting a good night's sleep. They come bouncing into the office because they know that the work they do is going to have impact really soon instead of sitting there for two years, not being released. And, and all of this started with a reframing with the senior folks saying, this is what your organization actually does. And this is what success should look like. And when they have that kind of that really is like an aha moment, then they're like, okay, well, how do we get there? You know, I'm not an idiot. I'm happy to spend money on this. You know, I've been trying to do this other thing and I'm very, very good at this for a long time and clearly it isn't working. So now let's try the other thing and see if we can make that work. And when they do it, it suddenly starts working. And again, the great thing is they're not doing the stuff. I wasn't doing the stuff. You had these 400 engineers, 450, I think, engineers in a 3000 person division doing all the computering things and they were doing all the stuff. You know, we said to them, right, we need to focus on lead time throughput working process. And they were like, what are those things even mean? Great, good question. Let's start there. Right. And so it was a bunch of education. But by and large, each team figured stuff out for themselves. they're smart people close to their own work and they're adults and we treat them like adults. And that's kind of been my template for the last decade or so is you go in and you say let's take a look at your organization, let's take a look at how work works, right, let's take a look at what success actually means and let's start reframing some of that. And then what I love is there's an inflection point where instead of trying to push on the organization to change, you're trying to manage the demand, like manage the floodgates of people saying, hey, that's looking really successful over in Ben's department. What are they doing? Can we get some of that over here? And that's a really exciting time. I want to riff on something you said really quickly, just as I picked up on it, you said, they always bring you in last, right? That's the role I play as well. It's super interesting, right? Because look, we are individual practitioners. Sometimes we work together as a team. It's two, three, four people. It's not 50 or 500 or 1 ,000 people that are coming in to change this. This idea that nobody ever got fired for hiring IBM, and these days it's, you know, fill in McKinsey or BCG or Deloitte or whatever, is super interesting because that mentality persists. The only people who can help us are McKinsey or whatever it is. And then it never works. It never actually makes things better. All the PowerPoint decks and whatever doesn't actually make things better. And then we come in and have to clean that mess up. And you know? And that's a big mess because we're small practitioners, you know? And I think it's interesting to talk about that. Why aren't we in first, right? Or second for that matter. And I think I know the answer, but it's interesting to hear you say it because it's exactly the position. We tried this product management and discovery thing. Yeah. Yeah. and can you know the call is coming from inside the house. Right, right. Exactly. It's really, it's, it's look, I'm glad they're calling, but it's frustrating to have to come in and put out fires. Like I'd love to come in and be like, this is what we can do. And what's fascinating, just a quick story related to this. You know, I was working with, with a big, a big telco in Germany, right? B, capital B, capital T in Germany. And I got to present to the C suite, which is great. I'm speaking to the C suite and then after a big presentation about managing the outcomes and customer centricity. I have a meeting with the number three guy at the company and we're talking about building cross -functional teams that they have. This company has the entirety of the IT department. I already said IT departments. I already know what's coming, right? It's basic. It's insourced, but it's a, it's a separate entity that sits somewhere else. And it's, it's basically treated as a third party vendor. Um, and they said, but what do we need to do to make this stuff that you just talked about a reality? And I said, you got to build cross-functional teams, product design, engineering, working together on the same things at the same time. Uh, yeah, exactly. Exactly. It's anarchy, right? And, uh, and so, and it's the number three guy and his two lieutenants and me in this meeting and his two lieutenants look at him, look at him and they go, impossible. It's never going to happen. And he looks at them and he goes, you know, if not, if not us, the three of us, you know, I'm the number three guy in the company, right? If not us, then who? Who's gonna be able to make this change? And it's interesting to think that, right? Like it was a great epiphany on his part and it's not bringing in McKinsey that's gonna make this change. And it's not in bringing us in that's actually going to make this change. Ultimately, right? It's folks like that deciding that this is what they want to do and then finding the best people to help guide them along the path, which ideally is us. But it's so interesting that there's this mentality that nothing can be different. And the only way that we could potentially make it different is to bring in these high powered, high cost consulting companies that end up just making a mess of things. It's frustrating. Just venting a little bit. it's a vent away. I mean, I wonder how much of it is to do with things like ego or not wanting to be shown as, I don't know, responsible or accountable for something that you can't do. I think it takes a lot for someone to turn around and say like, I can't do this, but let me find someone I can work with who can help, help us achieve this rather than saying, I'm just going to spend my money and let that, let that thing over there sort it out. I mean, a la, a la safe to an extent. I think that sometimes I look at safe and I just feel this is a nice, like organizations need some kind of operating model, implicit or explicit, but it's something that tries to tie strategy and ops to kind of strategy to execution and ops. And there's an operator, there's something there, sometimes it's explicit, sometimes it's implicit, it just evolves and grows, but there's something there. And I think they may particularly, I think in my time at Deutsche Bank, I only spent three or four years there as a director. And, you know, when people looked at safe, they say, well, that just means I can just basically take that operating model effectively and magically everything will work. I didn't have to think if it goes wrong, I can blame that. But then we were very clear that when we started making our own operating model based upon other various principles and ideas, but not safe, we said, let's not use the name of whatever we use because the moment things get a bit bumpy and they will get bumpy, people point the finger at the thing we've chosen and say, that's broken, that will never work. And that probably isn't the case. The problem is actually it's... is we're learning how to operate in this new environment rather than being the point the finger out thing. And we'll take responsibility for that. And I think there is an element here of maybe, yeah, people want to outsource the responsibility and be able to point the finger at something other than themselves. And it takes a certain type of leader to have the humility and the courage to say, if not us, then who? Yeah, exactly. yeah, that just struck a whole load of thoughts with me. I mean, I think something you said there, Ben, I wanna pick up on is this idea of this operating model and it failing. And what I've found, and again, this is more, it's kind of emerged over the years of doing this, is I'll try things. I'll try things like modeling the value streams in the organization. I'll try things like getting the various people and often quite political operators in the same room as each other. And what I've realized is I'm not expecting it to succeed. I'm expecting it to break in an unexpected way. So in other words, the way in which it breaks is signal. If these people refuse to even come in the room, that's signal. If they come in the room, but they're clearly talking across each other, that signal. If they come in the room, they all get on brilliantly and they wish they'd done this two years ago, that signal. So you don't know what's going to happen. And this is why, you know, rigid frameworks that have, you know, cutesy roles and structures and blah and training, not naming any names, but you know, certification Ponzi schemes I tend to be a little bit cool on because, you know, Jerry Weinberg used to call it solutioneering. where you have this model and you go, right, okay, so the problem you have is that you don't have safe, you don't have less, you don't have scrub and scale. And then so you go, right, you've got this problem, you now implement safe, now you've got two problems, right? And because no one ever said, what's the goal? What's the need you're trying to meet as an organization? Faster to market, less cost, improve quality, whatever the thing is, right? Our customers are leaving us in droves because Apple just opened a bank. You know, what are we trying to respond to? And let's start there. Let's start with the goal and work backwards. And that's kind of the thing I'm baking at the moment. I did want to share with you, so Ellie Goldratch, The Gold, this lovely book from 1984. And you know, still very relevant today. It's a business novel about this guy, Alex, who runs a factory. And they're going to close the factory down in like 30 days, because it's just all going horribly wrong. And so he's, you know, and he's going to lose his job and his marriage is on the rocks. It's all going wrong for Alex. And then he meets an old school teacher and the school teacher starts basically asking him a bunch of Socratic questions that lead to a lot of enlightenment and things. And it turns out that everything is okay. For me, life -changing book, you know, you really do kind of what I love with Socratic questions. So Socratic question is a question that leads you to some kind of discovery, some kind of enlightenment. is you're reading the book and you get the answer just before Alex does. You're reading and you turn the page and you go, yeah. Or sometimes you don't. Sometimes you turn the page and you go, wait, what? And then you've just had that moment. So it's very effective. But that's not what I wanna mention. The thing I wanna mention is at the end of more recent versions is an extended interview with Ellie Goldratt. And that interview is worth the entrance fee alone. Forget the book, just read the interview. And there's this wonderful bit in it where he asks exactly this question. He says like, you know, so Mr. Goldrout, you know, clearly the thing you're talking about, you know, Mr. Gotthelf, clearly the thing you're doing is product management. It works, right? How long does it take typically, you know, a typical engagement? And he answers, he says, well, a typical engagement is between five and 15 years. And they're like, what? How come? He says, oh, it's very simple. He says, I am offering a paradigm shift. A paradigm shift is not now available in blue. We're going to move the button to the right. Your paradigm is the way you see the world. A paradigm shift is breaking that model and seeing the world differently. The shift from activity -based measurements to flow -based measurements is a paradigm shift. The shift from our product has features to our product meets customer needs is a paradigm shift. and you cannot hold both those thoughts in your head at the same time. One of them has to break. And it turns out that as human beings, the one thing we hate is having our paradigm shifted, right? Because, you know, it's our sanity, it's how we make sense of the world. And he says, so basically you need three things to shift a paradigm. The first thing you need is to have run out of options. You've tried everything else, you're desperate. The second thing you need is an existential crisis. Right? If we do not do this thing, we go out of business. The third thing you need is information that this new thing exists. He says, I'm good for number three. So what I do is I make friends with organizations and then I wait and I wait for one and two. And eventually the phone rings and they say, Hey, Mr. Goldrat, you know, we're having an existential crisis. Mr. Gotthalf, we're having an existential crisis. We've tried everyone else. You're the last name on the list. Can you help us? and he says the more enlightened organizations they will force that thing. They will force an existential crisis. We have to do this thing. They will force no other options by saying we're gonna try Jeff's thing. And when you get that number three exec in a room saying if not us who, right, that is you just grin, right? That is the once in a decade meeting you were in where you're like oh my goodness you just saved me two years. You just saved me two years of... nudging and nudging and nudging on your organization until someone finally says what you just said. And it is honestly it is delightful and very rare when that happens. Yeah. Yeah. I don't know anything good came out of that conversation. At least the question was asked. a great book, I don't know if any of you guys have read this book here. Design for How People Learn by Julie Dirksen. Julie's a marvel. She's one of the most amazing people I've ever met. I've heard this book and her new book as well about behavioral science and learning is fantastic. But in this book she talks about gaps and the gaps that we need to fill in basically to get change at an individual level or even an organizational level. And my three, my favorite ones are skills, knowledge and motivation. And I think part of the issue is in large organizations, when that crisis isn't there, when the motivation isn't there, people think that we can change the shape, our paradigm by education. And we just go and we teach people and things will happen. They're not realizing actually that if people need to be proficient in the thing, and it takes more than just being told what it is, it takes practice. And so they hire coaches in and they try and get a bit of practice. But the biggest gap, it isn't the knowledge and it isn't the skills, it's the motivation. And so whenever I think of engaging with clients or whenever I think of training is particularly, I kind of say, yeah, I'm there to fill some knowledge gaps. And I think Dan, this is probably what you get with the stuff that you're doing is that you motivate people. Yeah, you give them some information and then they've got something they can go away and try and put into practice. But it's how do we motivate people to then want to go ahead and make that change? And I think the challenge, I guess, that people are experiencing if we go back to the top. question that we had is that we have these large organizations which maybe have many, many products within it. And then we may have these kind of vertical products, we can get each one aligned and doing something which is deemed as better in their opinion. But then at the whole organization level, how do we create motivation for the organization to change the paradigm rather than just slices through it? So two very quick responses to that, because I want to hear from Jeff as well. Two very quick responses to that. One is the fairly recent observation that you act your way to anywhere thinking. The way you get the paradigm shift is you don't come in and go, hey, everyone, we're going to shift our paradigm. Say, right, I just want you to try this thing. And we did this at John Lewis a few years ago. Their online team was 90 people. responsible for, so John Lewis Partnership, it's a partnership, it's a lovely organization, so they're all partners, they're all employee owners. And that was challenged a few years ago, and they said, right, you've been running for a hundred and something years, surely you should be like a shareholder, blah, and they managed to defeat it, and they said, no, we're gonna carry on being a partnership. Really interesting organization, culturally just very nice, right? Everyone there, I mean, some of the just most genuinely lovely people I've worked with. And... They have an online function and the online function is it's the website, it's the mobile apps, it's everything that you would do. Certainly pre -pandemic, this is like late teens, late 20 teens, I think something like 40 % of their revenue was coming through the website. Now this is an organization with 60 ,000 partners, I think it is, across like Waitrose and John Lewis, all the stores. Something like 3 ,000 of those in the head office, 1 ,000 of those in technology, 90 people, 90 people propping up the entire web estate. And my gig, if you like, was how do we get them all pointing in the same direction? They'd scaled really well, but they were now like, you know, there was a fragmentation going on. And we did some great work there about getting them pointed in the same way, which is really exciting. I've got no idea how I ended up in this trouser leg, so I might need to pull. pause and reset. We were talking about that broad organisational purpose, that motivation. We can motivate the pieces of an organisation, but how do you motivate the whole? So hopefully you can edit and drop back into here. So yeah, so we had, I think it was a dozen teams at that point, and they were all operating fairly independently, and Daniel comes in, and of course, a dozen teams are now going, oh no, this guy's gonna come and tell us to do Scrum or Kanban or something, or he's gonna come and tell us how to work. And what I did is I said to them, look, go nuts, do what you like. work how you want to work. Like oh you hear all these people go ah. I said I need three numbers from you every two weeks. I need to know throughput. How much work has come into your team that you've shipped? I need to know lead time. How old is each thing you ship? When you ship a thing did it come in 14 months ago? Did it come in 14 days ago? And the third number I need is how much stuff are you working on right now? Just with your work in process. So I need those three numbers. Do what you like as long as every two weeks on a two week cadence, all of you can give me those numbers. And some of the teams couldn't. And so we helped them. And so we showed them how to. And within a fairly short period of time, we had all of these teams working on a cadence. We now had a program view of what was going on, which meant that we could start to think about alignment. The next stage then was guess what? OKRs, right? Objectives and key results. how do we give all of them a shared sense of direction? Because if you give people a shared sense of direction and a lot of autonomy, motivation kind of takes care of itself, right? An awful lot of people come into work and they don't know the why. They know the what, right? They've got a manager or someone telling them the what, they don't know the why. And it's really hard to motivate yourself when you don't know the why. So the big part really is, can we get people with a shared sense of purpose, shared sense of direction? And where you have these 14 different products or whatever it was, and 14 different people saying, well, 14 sets of OKRs, those aren't OKRs. Those are near -term objectives from a bunch of 14 tactical products. OKRs is what objective as a company, if we were going to say, what do we want to be different in three months, six months, nine months from now? What headline thing do we want our customers saying about us that's different? You know, what would, that's exciting. Wow, you've become loads more reliable. Wow, your products have become a lot more consistent with each other. They look like you just, you know, bought a load of products and your current offering is a bunch of products in a trench coat, right? What's happened in the last, it's really obvious that now I feel like I'm using a suite of products from the same vendor. reliability man it all used to be buggy as hell but I'll tell you what it hasn't crashed in ages and I just want you to know I appreciate that I don't know what the thing is right Jeff doesn't know what the thing is he's really really good at asking what the thing is right and and worrying at it and worrying at it and worrying at it and teasing at it and teasing it until they find it because often they don't know what the thing is they haven't articulated it and once you can tell when they hit the thing because when someone mentions the thing everyone else in the room goes oh yeah It's not like a, oh wow, it's like, yeah, I guess that's probably the thing. And as soon as you get a bunch of people around the table going, yeah, that's probably the thing, write it down, because that's the thing. And what we do, and again, Jeff and I, I think our work is very complimentary. A lot of people see OKRs in terms of business goals, business outcomes. And I see them as broader than that. They are the success outcomes. So you might have an objective about the product, about the market, about customers. You might also have objectives about the operating model. We set an explicit goal at the big bank, half lead time, double throughput, with no loss of quality. We're not allowed to do it by cutting corners. Brilliant, hairy, audacious goal. And what I loved is the managing director, senior guy at a bank. senior person at a bank is a managing director which is hilarious because they're not actually managing directors it's just a rank. But he said to me afterwards he made this announcement to his whole division and everyone's like he said I don't care what the results are. He said some of my teams are going to find it trivially easy to halve their lead time and double their throughput they own their entire stack some of these teams are going to find it impossible because all of their work is basically coordinating other people's work. He says I don't care what the results are. What I care about is that now 450 engineers are all asking themselves what the heck is lead time and what the heck is throughput. Because that means we're all facing the same way. And that's when I was like, right, you're going to win. You're going to win at this. Nice. Jeff, I know we are getting towards the end of our lot of time together, but what can you add to that? Look, the thing, the organizations that Danny and I work with are massive. They're always big. And, you know, I think you have to take wins as they come and use those wins to drive more wins. I know that sounds a little cliche, but that's like, that's the way it works. I think, I think if you, even if we came in and looked at the engagement that Danny and I did together for several years, um, with one of the biggest companies in India. we had access to the top. We did. And still it was incredibly difficult to turn that organization to do anything significant in a short amount of time. The way that this works in my experience at least, the way that you get these organizations to change is you prove the model in the same way that we run experiments to test product, we run experiments to test. process and ways of working, right? So instead of saying, hey, on Monday, we're all using safe. Disaster, right? Or whatever, replace safe with whatever. It doesn't matter, OKR, Scrum, whatever. It doesn't matter. We're going to say, look, we're going to take, what do we have? We have 1 ,500 folks in product development. All right, we're going to take 15 folks. And you're going to give them to me for a quarter uninterrupted, focused on an initiative that is. strategically important, but not critical. In other words, people are gonna pay attention to it, but if it goes sideways, no one's getting fired, right? That kind of thing. And we're gonna give those folks a set of OKRs together. We're gonna put together a set of OKRs and they're gonna work towards, and we're gonna set them loose. They're gonna figure out how to build a way of working that is outcome -focused, customer -centric, has continuous learning and improvement built into it, self-sufficient. empowered, all of the things that we've talked about forever. And we are going to measure not only their progress towards their OKRs, but we're going to measure their work, their productivity, their camaraderie, their efficiency, et cetera. And we're going to make this obvious to the organization. It's going to be transparent. It's going to be continuously shared out so that at the end of this, Experiment it's a time box, right? Let's just say it's a quarter ideally, right 12 weeks at the end of this time box If we've been successful It's not just a big reveal. Ta -da We're awesome now, right? No, you've seen you've seen the transformations the good parts the bad parts the hard parts the pivots Etc and now that we've come to the to the end of this particular experiment We've got the evidence that says this is better and we've learned a bit about how to do better here So now let's take two more teams. Now we've got three teams. Let me go from three to five, from five to 10, from 10 to 25, whatever. But that's it. You de -risk the change by proving the model and then using evidence to drive further investment in the change. That's it. And it's not rocket science, and it's still rare. There's still this like, let's just give it to everybody all at once, and we know what happens then. So that's what I've seen work. I'd love to maybe meet up, I don't know, and talk about as a person or even do another episode at some point. Because it's just that inclination to try and do it all at once or to try and get that big payoff, you know, rather than going slowly. And I know that I've experienced situations where I know why that happens. But I don't know if that differs from what you've all experienced, but it's definitely a problem. There is little desire to go slow and learn and experiment. And to Jeff's point, I mean, my big American bank story, when this chap stood on a chair in front of 400 people and said, you know, Harvard, Lee, time double throughput, was a good year into the engagement. You know, I had been working with him with some of his teams and I tend to go a little bit bigger than Jeff. I'll be like a program team, maybe 50 people. But if you think that those things are probably correlated, because around a 15 person product team is probably a 50 person program team, so it's a similar sort of size. So big enough that if we are measurably successful in a quarter, it's because of what we did. I like the, for me, it needs to be critical enough work that as Jeff says, you've got their attention. If it doesn't matter, no one cares. No one cares how you got there, no one cares if you're great at it. It needs to be, probably not people being fired, but certainly people being embarrassed. I've got your attention, you've just given me something that is really important to you, that it's an act of trust. You trust that we're gonna do this thing in a way that you wouldn't have done before. And again, it goes back to Ellie Goldratt's paradigm shift thing, is the reason you've asked me to do this is probably because you tried all the other things. You know, we're now going to try Jeff's crazy sense and respond thing because because all that other stuff that we got from, you know, Accenture or whatever isn't working for us. So, you know, I and it is an important thing. I do need it to get to market. There is an urgency about it. Right, Jeff, please do something in the next quarter. He's like, right. Well, obviously, you see what I can do. So so that the I do absolutely agree with starting big enough that you're going to make a splash, but small enough that you're not trying to turn the whole ship. Hmm. and prove it and prove it and prove it again. And I think to Jeff's comment about, you know, proving the model, there's something, a chap called Chris Matz, who's a lovely kind of product business analyst guy, I go back a long way with, he talks about breaking the model. So, you know, introduce a constraint that the current system simply could not meet, right? And that we could, I know at Deutsche, there was the brilliant Paul Shepherd, the constraint was idea to production safely in a day. Can I get a small change, but an actual customer, you know, business facing change through all of the systems, all the governance, all the regulatory, which is the word safely, can I get an idea safely to production in a day? And from a standing start, it was some, I mean, I'm probably not allowed to say, but it was certainly a significant number of weeks to take a small change to production. And that was where he started and by the time he finished, by an entire kind of what they call a continuous compliance platform, you could indeed take a small but significant change to production safely in a day, and actually in half a day. You could start in the morning and have it out by lunchtime. So he exceeded his own goal. But he did this by breaking the system. We cannot do it in a day. Why not? Why not? And keep on asking why not and worrying at that and worrying at that and fixing that thing. Just next constraint, next constraint, next constraint until the answer's all we can. We can't get a product out in a quarter. Well, why not? Let's get Jeff on it until we can. And suddenly, two or three quarters in, we're taking, and again, it's this wonderful reinforcing loop. The business folks, the commercial folks are no longer trying to put huge amounts of stuff on you because they know that when they ask you something, you will turn it around inside a quarter. They've never had that before. Hmm. turn it around in a quarter in a way that can be measured, right? They can measure the impact of this thing. And so now they, guess what? They start to get an appetite for trying lots of smaller things much more frequently. And now you're not doing it every quarter, you're doing it every month, you're doing it every couple of weeks. And you create this reinforcing line of virtuous cycle of lots of small experiments going through, direct customer feedback, direct interaction, try the next thing. And it's what went... When it takes root, it's wonderful, but it is just that initial paradigm shift that initial can we get this thing off the off the mark? When you say there, what it reminds me of is a quote from Peter Senge from a long time ago, which is saying that if the answers to our problems are obvious, we'd already be doing them. So we have to accept that the answers to the problems are maybe some of that from your perspective is that they're non-obvious and you haven't been able to find non -obvious things in the current ways you've been doing things. So we need to find a different, less obvious way of you doing things in order to kind of hit upon the things that are really going to break or put stress on the system so that it fractures. And you can begin to say, well, that's where the... That's maybe where we need to focus. And very importantly, it's not that the not obvious thing might not necessarily be hard. It's just different. It must be really complicated because we haven't figured it out yet. No, it's just different. It's really easy. It's different. Yeah, through that current lens, you just won't sit. So it's give you a different way of perceiving it. Awesome. Look, thank you so much for your time. I've kept you for a few minutes longer than we planned. So a huge thank you to you both for spending this time going through so much and looking through my notes that I've got here. I mean, we started off the idea of operating a product business at scale in a way that those who compete with much smaller organizations. And we spoke about the shape of an organization. We spoke about learning the importance of it. We spoke about identity change for an organization and for the leaders within it. We talked about putting the decision makers in front of customers. And Geoff, you had that wonderful story about minimum character count, which was just wonderful. There's so much more. So yeah, I'm hugely appreciative for you giving up this, yeah, your valuable time to have this conversation with me for the benefit of our listeners. I guess if people want to... learn more about what you're up to at the moment. What's the best for you both? What's the best mechanisms? Where should they be going? Is your website, is it linked in? Like where can they find the most relevant information for you both? I'm super easily findable Jeff got health.com and on LinkedIn, please connect on LinkedIn and Okr -book .com will tell you everything you need to know about the new okr book coming out in a month. great to get that into the show notes for you. Done. Likewise, DanNorth .net, as I said, I will be launching a new thing fairly soon, weeks rather than months. I'll be very public about that. Mostly in terms of interaction, I'm on LinkedIn a lot these days. It's become a less toxic version of I'm no longer on the Twitters at all. I'm on Mastodon as Tastapod, but mostly in terms of kind of grown up interactions and things tends to be LinkedIn. Great. Well, we'll make sure all the links are in the show notes. And yeah, thanks again for your time. I massively appreciate it. And thank you everyone for listening. We'll be back again next week with who I don't quite know at the moment, but please do make sure you subscribe to us on your podcast platform of choice. And we'll be here for you again soon. Thank you very much, Daniel. Thank you, Jeff. Thank you.