episode 20: justin watts episode transcription

Episode 20: Justin Watts Episode Transcription

© 2021 Tasktop Technologies Incorporated. 1

Mik Kersten: Hello and welcome to the Mik + One podcast, where I sit down with industry leaders to discuss the Project to Product movement. I'm Mik Kersten, Founder and CEO of Tasktop and bestselling author of Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework®. Today I'm thrilled to be joined by Justin Watts, Director of Agile Change at Lloyds Banking Group, one of the UK's big four banks. Justin holds an MSc in Lean Enterprise from Cardiff University, an MSc in Business Research from Buckingham University, where he's an honorary research fellow and is currently studying for a PhD. Mik Kersten: Justin started out in manufacturing then moved to Lloyd's front side operations where he was Head of Systems Thinking. He's now applying those same principles to Lloyd's digital transformation and has some critical insights on how we need to change the thinking of our leadership and in fact, of the entire organization. I encourage you to listen to Justin making a fascinating case on how we need to move from old school ways of thinking about economies of scale to understanding and optimizing for the economics of flow. I'm thrilled to have him share his learnings with us. With that, let's just get started. Mik Kersten: Welcome, everyone. I'm here with Justin Watts, who's the Director of Agile Transformation and the Methods and Tooling Leads at Lloyds Group. I got to meet Justin through interactions around the masterclass that he was running for the Lloyds Transformation Leadership Group, which actually included one of Lloyds' board members. I've been amazed at how Justin's approach to changing this organization, Justin, I think the organization's more than a few years old, around 250 I think. I'm just really excited for you to share your experiences, share your learnings as you moved from the manufacturing side of the world to applying these concepts of flow to Lloyds Group and to helping the group transform. So welcome. Justin Watts: Thanks for having me. Yeah, great. It's been a bit of a journey, actually. I think I'd describe it as being on one of the most intense learning journeys over probably the last 12 years in different parts of industry, service, manufacturing, now predominantly in software, but I think I started in the right place. I think that's part of the secret. Like you said, Lloyds is probably a typical corporate organization, kind of quintessentially British as well, in terms of some of the culture that goes with it. Justin Watts: But been around for a long time, like you said, over 250 years. But I didn't start in banking, I'm as far away from a banker as you can get probably, both in terms of geographically being nowhere near London and growing up in South Wales and having a background of mainly most of my family's being coal miners, nothing to do with banking. But probably grew up in a world where manufacturing and steel and iron as part of the heritage really, where they came from. I think we chatted before, but I probably didn't have my first job until I was 26. Mik Kersten: Wait, what did you do before you were 26? Justin Watts: I went to university and my passion was sports and sports science. I played rugby at a pretty decent level. And I did a bit of messing around after university and ended up going to Australia to play rugby for 12 months. Came back and was not desperately looking for work, but mom and dad were not going to fund



me anymore, so I needed to get a bit of work. So I ended up working as a quality technician in a manufacturing company. The company basically turned pulp paper packaging into the Amazon boxes you get today. So part of a big old supply chain that went from forestry through to recycling. Justin Watts: And my job there as quality technician, I got to interact with a typical Japanese company who demanded very high quality. It was LG at the time making TV monitors, and that's when I first stumbled across the quality movement. They called it Six Sigma at the time and that's what I think I was learning but I was learning things that had been around for a very long time. And I got to understand some of the characters that were important like Juran and Deming and people like that. Justin Watts: I was at that point uncovering stuff that I didn't really know how fundamentally important they were, but I was enjoying it and tended to probably then went more down the route of trying to understand this thing that people were talking about, Lean at the time. I was 26 so it was quite a few years back now, maybe 20 years. That's surprising to myself to even say that. But Lean was the big thing then and it is still around now, but it was right in its heyday then and everyone was trying to do Lean transformation in manufacturing, so I went into the masters in Lean, in what's called Lean Enterprise Research Centre in Cardiff University. Justin Watts: And their reputation was worldwide in terms of their research, and what they teach and everything else. So I was really, really lucky that I managed to get myself funded to do that. At the same time I was taken from the manufacturing operation and asked to be part of a Lean transformation across Europe. At that time, I was learning from some of these people who were really good in their field and then doing transformation. I was learning theory and putting it into practice. And we were working with McKinsey at the time, and I probably spent most of my time arguing with the consultants about what I was learning, and what they were teaching me, and what they were telling me to do on the ground. So that was a massive experience again, [crosstalk 00:05:35]. Mik Kersten: I hope you're not repeating that experience, but I have a feeling that you are. Justin Watts: It's come back albeit a few times, yeah. This whole thing around learning and working with consultancies. But I think then I was really inspired to try and move from manufacturing, because I'd learned quite a bit around the theory and applying this thing that I was learning into a service environment, service industry, which was when I joined Lloyds Banking Group. But I joined to look at how we could improve in the frontline operations. And that's when I came across the work of, I think we mentioned it before, a guy called John Seddon, the Vanguard Methods, and how do you use systems principles and systems thinking principles to think about how you would redesign operations basically to respond more quickly in a way that actually did what mattered to customers. Justin Watts: And it was a key thing for me. And even though I'd been studying Lean with Cardiff, I learned more about what I thought I was learning when I started to understand John's stuff in a service environment about what TPS was all about. Not Lean, not what the consultants had turned it into, but actually the core fundamental things I was learning about Ohno's method around how TPS actually worked and applying the principles to actually service operations, and to undoubtedly to work from a custom perspective, and



that's when I started to understand that the things I was being taught were actually being commoditized by consultancies and sold, and they really lost the thread on what this was all about. What problem, where did Lean come from, what problem are they trying to solve? Justin Watts: Ohno was the inventor of it, Taiichi Ohno, so I just went and actually learning from John was well, that's when I need to go have a look at this stuff. Not Lean as being publicized everywhere by all these different [inaudible 00:07:24], go back to the source. And I started getting back into this weird thing where every time I was looking at something, I would need to go back to the source. And it really made me more inquisitive and intuitive about the source of things. And then, I think as Lloyds was starting to get closer to a digital transformation, some of the work we were doing in operations was getting some attention, and long story short, the transformation division and digital was then, we joined forces on okay, so what are we really learning about how you redesign frontline operations, and what does that mean then for how that flow should flow through then into software production or the digital side of it. Justin Watts: And I think that's when I moved from my job that I was doing in terms of applying systems principles to frontline operations to taking more of a role in what I'm doing now, this thing called Agile, this thing that other consultancies were selling the big organizations in terms of, you need to do this Agile thing. So again, whether they go back to the source. And the thing that John said and always taught me really early on was that whenever you're looking at something, what problem were they trying to solve and do we have the same problem? So when I first took on the role I went and I researched, because I'm a researcher as well, and I got an academic background, some people call it nerdy, but I quite enjoy reading. But I went to the source, I went and did the research on the Agile manifesto and picked up all sorts of papers and just really got into it. Justin Watts: And essentially when I did my research and I tried to answer the question what problem are they trying to solve, we don't have to go through it now but essentially the problems were the waterfall method, sequential method, not being fast enough, not being able to respond to the requirements. Did we have the same problem in Lloyds? Yes absolutely. And actually then the link to TPS was Ohno was trying to solve the same problem, he was trying to respond to the demand. He had a cost problem, he couldn't afford to produce like Ford, he couldn't afford to produce like mass production, he just couldn't afford it, he didn't have the natural resources to do it. So he came up with the concept of flow in manufacturing. And that's when I really started to think about okay, if we were really going to go after an Agile strategy, what is this all about? Because I just felt that the Agile movement was going down exactly the same route as the Lean movement, where it had been again commoditized and sold by big consultancies, and really lost the thread, really lost the source of the problem to be sold. And that's where we just sat back and said, "Well let's simplify our Agile strategy and let's base it all on flow." Mik Kersten: Justin, lets pause there for a second, because I think you hit on some really key things. So you were head of Systems Thinking on frontline operations, and I think this is a success pattern that I’ve seen before, where traditional businesses have actually been able to transform much more quickly when they've done that kind of systems Lean flow oriented transformation in another part of their business, be that their call centers, their frontline operations, their customer services. And I've seen this in the world's largest insurance companies, as an example, where they've applied that systems thinking to a portion of their



operations. And at a business level it becomes much easier for them to understand the benefits of it within IT. Mik Kersten: And then of course we've seen it be misapplied, which you were touching on as well. So you were just saying it was going back to... In terms of back as head of Systems Thinking on the frontline operations, rather than leaning on some crutches that were being provided by various consultancies and so on, you were concerned that those were missing some of the core essence, and I think you just nailed it. Toyota could not afford to compete with Ford without applying these things. So you're saying it was similar within the frontline operations, and you actually did manage to drive forward those transformations, not leaning on [inaudible 00:11:19] crutches, but actually going back to first principles. Justin Watts: Yeah absolutely. First principles and heavily influenced by again got to give the credit to John's work and what he taught be about the actual cracks of the Toyota production system was the ability to respond to demand. He was able to produce cars at the rate of demand required by the customer. And that opened up a world of understanding for me around things like requisite variety, all the standardization of processes from a customer perspective, because the thing that customers want when they come to us for a service is for us to do what matters to them, not for us to read in the rule book. Justin Watts: And lots of mistakes with Lean was taking the principle of standardization and apply it in service, and it creates havoc, it creates this thing called failure demand, where people just cannot get their thing that matters to them done because we've over-standardized the process, we read in the rule book kind of thing. And actually it doesn't work, it creates more cost. And if you actually think about how would we design a service that only did the things that matter to customers, then guess what? It's far cheaper, your costs just fall out of the system and you're only doing the things that matter to customers. So it's really counterintuitive for lots of organizations that if we do what customers want, it's going to cost us a lot of money. Well no actually it does cost less. If you do the thing that really matters to customers, it costs less. Justin Watts: Now that's a very transactional way of looking at it, but the other thing that we looked at, say for example you are a customer who really wants to take a mortgage out with us. The thing that's really important in a mortgage application is predictability and speed and flow. It's underpinned by flow. If you come to us with, this is the house I want to buy, I'm interested. The thing that really matters to most of our customers is being able to give you an answer as soon as possible. And that's where we started to see well actually, the concept of flow and removing waste in the system to get the answer back to the customer was absolutely critical for us in terms of how we transform the operation based on what mattered to customers. Justin Watts: So that was our first insight into if we can't do the thing there and then, which is very difficult, and our mission should be why can't we give a customer mortgage on the first time they contact us? But sometimes that's not able to do that. If we can't do that, when's the next time we can actually give them the mortgage? We have to think about compressing the time it takes to do everything because better service costs less. And that's what I had drummed into me by John all the time, better service costs less. And we learn so much about how we take those principles then from the customer faceing operation in two ways, number one was if we're really studying what matters to customers, surely we should be basing our software solutions on those things that we're learning.



Justin Watts: And actually, what we're learning about time and compression of time is equally as important when we're delivering software to solve the problem as well. So I think what we've been able to is, well we're not there yet, but stitching the demand from a customer perspective through to the actual solution that we produce and code is something that we're really now starting to understand that we knit those things together based on the same principles. Mik Kersten: Absolutely. And by the way, we'll put a link to John's work in the additional materials section. But I think this is the different kind of thinking that you've been able to apply, first on the frontline, but now let's talk about what you're doing in terms of the software and IT side. But yeah, better service costs less, and actually re-engineering around the customer rather than around internal processes or internal silos leads you to that result. Justin Watts: Absolutely. Mik Kersten: Okay, so you got to learn that as Head of Systems Thinking, that worked. And then just tell us a bit about how you ended up deciding to take on what may well have been a much bigger challenge now to doing this on the actual core digital IT and software side at Lloyd. Justin Watts: Yeah, I just think it was the way the world was moving. Everyone was moving towards, and it was probably about four years ago that I started to lean into the role maybe, and then probably about two years officially doing it. But the world was going down the route of digital transformation, everything's digital transformation, I was a little bit curious around well, some of the early signs were that we were just going to base our transformation on, I got to be very blunt, but gadgets, widgets, technology. And I'm like, it's not going to work, it's just not going to work. Number one, I did the research around some of the figures around the amount of IT and code that gets created that never gets used, that's a massive problem for me. If it's over 50%, then there's something wrong, we're doing the wrong thing. Justin Watts: And again, I was heavily influenced by John who then put me in touch, not in touch, because lots of these people are not with us anymore, but they work, like many people were inspired with them. Russell Eckhoff, he always said things around doing the wrong thing righter. I could see our organization was starting to do the wrong thing righter, we were starting to put all our eggs in a basket around digital, and everything was just digital, digital, digital transformation. I'm like, that's not the problem. A lot of the problem is within the way the organization is structured, is put together, the way that we specialize and functionalize everything, the way that we measure the wrong things, the way that we still use outdated views of motivation in terms of setting targets, and all those kinds of things. Justin Watts: I knew from some of the things I learned about Deming's work and Russell Eckhoff that all of the things that we were trying to design the organization around, the normal way that we organize organizations if you like, was still going to be there no matter how digitized or transformed we became. So essentially the transformation was far deeper than we were talking about. And then that's what I thought... I think it's when I'm going to have more influence over the change is if I can start to be part of that world, be part of



the digital transformation world, and try to help it to learn from the history that we've got, not just in Lloyds, but the history around how organizations tend to fail. Justin Watts: Because nothing to do with digital or technology, but the way that they're put together and the assumptions people carry around with them and the things that we think work, like target driven behavior, and we don't do it anymore, but performance related pay. And all that kind of stuff is just outdated, and you're not going to transform any organization if you've still got all those things in place. You can do as much Cloud conversion as you want, as much technology focus, as much digitalization as you want. But if you don't transform the organization's thinking, then over time it's going to be the same as what you've always got. So that was my inspiration really for wanting to move in what I'd seen in operations to this big thing we were going to do as a bank is transformation, because for me it was far more than digital. Mik Kersten: Okay excellent. And I really think want to now jump into some of the principles in practice that you've applied, but then I think we can unpack some of these things. Because as you've told me, as you've told your leadership, a lot of what you learned at the Lean Enterprise Centre is that there's physics to flow that you can't ignore, that you actually will apply it to change the thinking. And I think the way that you just painted the picture of why these things go sideways and so many organizations are investing so much in doing the wrong things right. It's really at the core of the problem of [crosstalk 00:18:41]. Justin Watts: Absolutely. As Eckhoff said, it's better to do the right thing wrong and learn. And you're right, let's go back to what I talked about earlier. Like I'm not an Agilist, I'm not, that's just not me, that's not what I've grown up on. But I've grown up on a manual flow. It underpinned everything I've done since I've started looking at transformation. And what you said is really interesting, when I was doing my masters and when I was doing this transformation across Europe, I stumbled across the factory physics framework. The book is mind blowing, and I'm not that good at maths, but I've got a pretty sound understanding. But it's a framework that really shows the physics behind flow, and I think it's because what I've learned as well is that being a business researcher, there's different ways to look at the problems, objective and subjective and so on and so forth. Justin Watts: But I think that I was always an objective researcher, and that's normally how it helps me is to see things that are a bit more objective and built more on physics and mathematical. And I know there's much more to in terms of the psychology to change, now people actually work in a system. But for me, you can't really argue with the physics of flow and the relationship between through bookwork and progress cycle time, those kinds of things. But what I really learned, one of the things that really stood out to me, and I think to try and articulate, it was I stumbled across queuing theory. Justin Watts: And when I started to look at this, based on what I just said around the counterintuitive thinking organization, if you've got an organization which is absolutely obsessed with cost management, and utilization and keeping everybody busy, and you look at queuing theory, those two things don't go together. And what I mean by that is, queuing theory quite clearly shows that if you load a system to anywhere greater than 80%, and dependent on variability, you're going to start to get problems with type and flow. So if you've got an organization which thinks about maximizing utilization and efficiency as a way that they've always thought and the way they've always measured, and you take the physics that



underpins queuing theory, the two things don't go together. Because essentially if you want good flow, you've got to have some protective capacity. Justin Watts: And that is a critical thing that we see in our organization. And what you find is how that manifests itself and some of the typical Agile principles is we don't limit WIP. We just push it in and push it in, and keep pushing it in, and keep hoping that we're going to get more work out, and counterintuitively, it starts to slow down. So, from a senior leadership position, if you can't start to understand the assumptions that we run with in terms of how the organization works, and this is a classic example around efficiency and resource utilization. And you can’t tackle those things and essentially they're just going to keep pushing work into a system, which slows it down, reduces time to market, and actually reduces productivity. And those counterintuitive things are really difficult to see if you haven't got the right measures. Justin Watts: And this is where I think a lot of companies go wrong with the cookie cutter kind of Spotify models that they put in, is that they don't ever challenge the assumptions that have been in the old organization and they just carry them through. They just carry them through to the new world. So people are trying to do Agile transformations with teams loaded at 100% utilization. It's just not going to work, you're not going to get any improvements in time to market with teams who are fully loaded all the time because what happens is, and this is clear because we see it all the time, is when there's too much work in progress, you get context switching, and then you get basically people putting work down, picking work up, multi-tasking and actually productivity goes down. Justin Watts: So it's very, very counterintuitive. But what I'm trying to say is, you have to challenge the thinking and the assumptions that we've built the old thing on before we actually think about how we transform the new thing. And to your point earlier, the way that we tried to do that in our transformation is move away from do this, do this, do this, a method to actually the principles. And I think that's why you wanted me to chat a little bit more about in terms of okay, so why did we chose those principles and how does it relate to what we just said? Mik Kersten: Yeah, and just hold there for a second Justin, because I think to me just hit the most essential and important point, which is understanding, and we don't have to call it queuing theory for every executive understanding, the actual dynamics of flow. And one of those most core principles is that when you load things to 100%... And I'll actually go a little bit deeper. One of my core reasons for creating the Flow Framework as it is just to expose these dynamics to leadership, so they can actually change their thinking and understand this doesn't work, this truly goes against the laws of flow. Those laws have been around for several decades now, they've been very well documented by people for product development, like Don Reinertsen and others. Mik Kersten: So, you've been able to apply them across your entire career, yet for me the most disconcerting finding of looking at the last two years, it's been two years since Project to Product was out there, and the Flow Framework was out there. The last two years of applying the Flow Framework is that WIP and overloaded value streams are the number one problem that we see across every enterprise organization, even though it is one of the most obvious laws of flow. And in a fascinating light, it's one of the easiest to remedy, where you actually need to understand it as a business level obviously, do the right thing in



terms of managing WIP instead of letting it manage you, and you actually get more of the results that you're after in terms of velocity and capacity and so on. Justin Watts: Absolutely, counterintuitive, right? Because who's going to build and protect the capacity, because that costs a lot of money apparently, but it doesn't really. Mik Kersten” Yeah, exactly. And I think that's the key thing, and so what I would love, just go through some of these and let's dig in, because what I love about what you've done about creating Lloyd's transformation principles and practices is that they capture this in the way that's meant to be, it's just much more tangible and meaningful to business leaders. So aligning work, improving relentlessly, learning rapidly what matters, optimizing the flow of work, making work visible, and then driving out fear to do that. Mik Kersten: So I think I got all of those right and some more, if you could just take us through some of what's behind this and how we're basically trying to make sure that these dynamics, what you talk of as the laws around flow, what you've actually seen put in action, that you've seen the dysfunctions of not understanding them, if you could just unpack some of these seven principles for us, or six principles I should say, I think you're working on a seventh. Justin Watts: Yeah, I'll start with optimizing the flow of it, because there's a thread, you're right in terms of the thing that underpins our strategy is flow. And for me it's like, why did we go there? Because we were implementing an Agile transformation, I went back to the source, and when I did my research it was very simple. And simplification of the strategy to flow is what's going to give us our constancy of purpose. Because it's not around stand-ups and ceremonies, they've all enabled us to flow at the end of the day. So flow is what we've based it on, we started with the principle of flow as the center of everything we were doing. And the way we think about these principles and practices is a leading measure, an absolute core leading measure for better outcomes in terms of better throughput, better cycle time, less WIP, better value delivery from a customer perspective. Justin Watts: So, these principles are a leading measure or leading way to actually produce better outcomes. Another mistake that I've learned not to make because I've made it myself is focusing on the lagging measures, focusing on value creation, focusing on time to market. [inaudible 00:26:38], we need them, but actually they're as a result of doing things differently. You get better flow by working differently, you get a better flow by putting in better practices. So, the principles and practices are a way of saying well, these are a set of leading things which will lead to better outcomes. For example, the one I use a lot is I think it's in my bio, but I'm in my 40s now, but I still like to keep myself fit and I like to do triathlon and I've got one of these personalities which means I have to do things to the extreme. Justin Watts: So I ended up doing Iron Man Triathlons, and one of the things that's really key when you're naturally a bigger chap who played rugby all this life and you want to do Iron Man Triathlons, weight is critically important. So I set about a program of trying to lose some weight while I was training. And it occurred to me, my lagging measure was the weight on the scales, and just by trying to look at the scales and wish I was lighter wasn’t going to do anything. So the leading measures were things like my calorie intake, whether I'd hit my training program, have I done my stretching, whatever. But there was a set of leading



measures that if I knew that I'd done those things differently, like ate differently, stuck to my program. I'd get on the scales and the lagging measure would all the sudden go, oh yeah you're a bit lighter, well done. Justin Watts: But just by staying at the scales wishing to get lighter, nothing was going to happen. And it's the same thing with what we're doing in Lloyds, that we think that keeping our eye on these principles as our leading indicators for better outcomes in terms of flow and valid delivery are what makes sense. So the flow one was where we started, and then we started to think about what are all the things that actually help the delivery more quickly of the right things to customers? So classic thing that we took from our operations learnings was, how do you learn rapidly what matters? And we've kept the language really consistent as well. And the things that we learned well about how to redesign a process flow was to really understand what matters to customers, and then base your design around that, and the better service costs less. Justin Watts: So the practices that sit underneath our learning rapidly what matters are, make sure you do your designing research upfront and learn from what really matters. We got pools and data lakes all over the place, what's it actually telling us? What's the data telling us? And we use the language around MVP a lot, but one of the things we really want to be able to do is learn from experimentation. If you can't get things to market in any kind of shape or form quickly through flow, then you can't learn from experimentation either. You'll just end up going back down waterfall. So three practices which underpin learn rapidly what matters [inaudible 00:29:13] there. So you need to learn rapidly what matters to be able to produce the right thing and to start reducing the industry classic problem of a lot of code that gets created never sees the light of day. Justin Watts: Part of flow, making flow work is actually knowing where the work is. So our principle about making work visible is completely aligned with improving flow. If you can't see it, very difficult to manage it. And not only we talked about visualization of work, but we mean measurement here as well. So all the things that we talked to you about in terms of the right measures are part of making things visible. If you can't see it, it's very difficult to take the right action on it. Aligning work is, and there's no particular order to this, the thing that we find really cool about this is the system. They all interact with each other and they all play off each other. And I'll come onto that a little bit more, but what does that actually tell us at the moment? The most powerful one of these principles is drive up fear. Justin Watts: But anyway, aligned work. It's closely connected with learn rapidly what matters, because lots of organizations start with OKRs and clarifying work items, backlog prioritization, and then think that's it. But if you're learning rapidly what matters, then you've got the quick feedback loop in terms of actually that might change. So you're okay, I might change based on what you're learning from the experimentation, they all work together. And then, the key one around improve relentlessly funny enough was it's just basically taking the other principles, because we measure against these principles, and we don't measure against you must do weigh the shortest job first for prioritizing work items. It just highlights a series of outcomes that would look great when we get it. Justin Watts: And improve relentlessly is just simply saying, what are you learning from understanding all these other principles and how are you using the data from understanding the principles to keep driving your



improvement against the things that we think are our leading measures? So to improve relentlessly is taking all the data we get from our cadence of using the principles to see how well we're working to keep moving us forward. And then the drive out fear principle I actually got to give credit to a guy called Alex Papworth, who worked with us for a while. And we'd introduced him a little bit to Deming's work. And this is straight from Deming's work, it's 14 management principles, and there's so much that we can learn from Deming's work, even today. Justin Watts: It was the 80s when his work got popularized, but he was a genius, he was ahead of his time. And actually when you look at his work, then it's still groundbreaking today if you really get into the depths of what he was talking about then. It's as applicable today or even more applicable actually based on lots of things that are going on in the world today. So drive out fear came directly out of Deming's work. And some of the practices that sit underneath drive out fear for us are the team is able to demonstrate a clear purpose, what is the actual team there for? In customer terms, what's the purpose of the thing that they're actually part of? And a big piece around trust and humility, leaders making decisions in the work is a key practice in terms of that. Justin Watts: And what that means is generally what you find in an organization is most of the decisions are made miles away from the work with a [inaudible 00:32:22], which is completely wrong. And another practice around protecting each other. But a little bit more about the leaders make decision in the work, key practice for us connected with making work visible and aligning work is, if you've got the right measures that are visual, the leaders who are closest to the work and make far better judgment calls based on the data, about how they improve how the work works. Now one of the key things that we learned from our systems days in the operation was, and this is one thing that really does grate on me quite substantially, is when I see a lot of the Agile community talking about things like psychological safety and engagement and empowerment and all that kind of thing. Justin Watts: And what I've learned from the theory and in practice is, all those things are free when you change the system. When you get psychological safety, you get much more engagement and motivated colleagues when you change the system. When you change the measures, when you get rid of targets, when you get rid of some traditional ways of thinking about managing work and re-designing flow, all those things around engagement and happy people come for free because you've changed the system and removed lots of the things which create bad workplaces and the need for somebody to come up with a psychological safety program created by a bad system. When you change it, then things just work out for free. Justin Watts: So with those principles and practices, I’ve completely intertwined in a system, and we find that what we are actually seeing really well is when those things shift as a leading measure, when we get better at working this way, then we see the improvements in flow and value raise. Mik Kersten: Yeah Justin, that's been an absolutely amazing part of the experience for me is how much again, I think there's all this focus on culture, on safety, those are important things. But when they're not [inaudible 00:34:16] system through the wrong... I mean you've nailed all the points, the wrong targets, the wrong indicators, the wrong performance management approaches. It's just fascinating that none of those



activities actually produce much better work environments. But what we've seen in terms of focusing on some of the metrics that you've mentioned, so end to end cycle time, so flow time. Mik Kersten: The whole time through a value stream, it doesn't measure one silo, it's not no longer development and operations or something upstream or a government process that people are blaming, everyone's just focused on improving this one metric, which customer-centric, how quickly customers get value, how quickly they get features or quality improvement. And once everyone's focused on that one metric, it's just amazing what happens. You need some psychological safety and you need to drive up some fear for people to make that visible. Once they make it visible, all the sudden they're not being blamed, the system is being blamed, and an artificial bottleneck that's there is being blamed. Underinvestment in the architecture, which [crosstalk 00:35:13] done. Mik Kersten: It [crosstalk 00:35:14] from the people to the system, once again you make these things visible. And I think the way that you said it I think is just such a good way of articulating, to me it's always about what you said is, it's about leading indicators. And this is why I structured the Flow Framework the way I did, on the left is the flow metrics which are the leading indicators, on the right you've got the business results. If you're only looking at the business results, you just won’t get there, the feedback loop is too slow. With flow, your feedback loop is a sprint. There can be a week or two. Mik Kersten: And so the question to me is, and I think this is what you're doing so effectively right now which so many are struggling with is making those leading indicators accessible and understandable to leaders, because of course our leaders have been on the finance side, on the business side, everyone's been very much focused and trained on the financial metrics, be it revenue or conversions or pipeline or cost. But the way you're approaching it is actually making these leading indicators through these principles understandable and important to leadership, because that's when they can effect change and actually support their teams to improve and go faster. Yeah, can you say just a bit more about that and the missteps you've seen in terms of over-focus on really the lagging indicators? Justin Watts: Yeah, the over-focus on traditional lagging indicators when you're trying to produce software, it's things like due dates, so we talked about peoplefocusing on due dates as a lagging measure. It's like yeah, fine, great, we've hit the due date, but what was our flow efficiency? Less than 1%, how much is that costing us then? I don't know. It's massive amount of capacity being wasted in a system, you can't see it because you don't measure it, because we measure due dates and we [inaudible 00:36:53] the hell out of everything. When we're green everyone's happy, but we could be sitting on more than 50% waste in the flow. But you just can't see it, so it's kind of like... Justin Watts: I think to your point around the master class series that we put together was, an attempt to take these principles and work with senior leaders so that they get some of the counterintuitive things that we talked about. Like when we do the optimize the flow of work master class, which is where we've started, we unpack things like flow efficiency in there, to show that if you reduce the amount of waste work in a system end to end, and you decrease the flow time, there's an economic impact to that because essentially the waste work is wasted capacity, which you're paying for. So it's a key thing I think from a transformation perspective is to really get senior people or people who are involved in finance, for example, or cost of change, or cost of delivery, to understand that when you actually improve flow, the



economic benefits, the economies of flow far outweigh, they're completely much better than the economies of scale and the way we've measured unit cost in an organization for years. Justin Watts: And that's one again, I owe a lot to John in terms of the way I've been taught around the difference between the economies of scale and the economies of flow. But in an organization which has built itself on the economies of scale measuring unit cost, it's just been done for so many years that the actual ability to see the waste in the system has just been disguised by the measures that we've been using for years. So it's there, but we just can't see it because we've relied so heavily on the wrong measures produced as [inaudible 00:38:35] and we take great comfort when we see a green. Mik Kersten: Yeah. So it's in the data, because we're staring at a ton of this data now, and seeing what effect that due dates have on extending flow time indefinitely and flow efficiency just tanking, it's just fascinating. And they're exacerbated by scope changes that then actually increase the level of WIP, and it's incredible to see just how endemic across the industry these kinds of bad practices are. Which is why again I think you're absolutely onto something in the way you've approached it with transformation leadership [inaudible 00:39:07] through this master class vehicle, and of just pointing out the flaws and misunderstanding, that some key laws of physics that are as important as gravity, that this VIP is basically as significant as gravity is in physics. Mik Kersten: And if you paint it the right way I think, here's the important thing to me is that you've painted it the right way, and I'm honored to be part of these sessions and watch some of this. But actually painting it as these really important meeting indicators for executives is critical. So one of the missteps I think you and I, I've been seeing this a ton lately, which is shift to Cloud, which everyone realizes is important, and they're very important economics, the Cloud. Mik Kersten: But if you don't actually understand the economics of flow and you move to Cloud, I've seen this over and over and over, which is there's a Cloud deployment and enough of a significant investment, great technologies invested in, and nothing is moving significantly faster, because the economies of flow were ignored and Cloud was simply seen as a way of optimizing longterm cost economics rather than doing the thing that Adrian Cockcroft, who I think is again one of the clearest thinkers and communicators on this, said is that the one important metric for CEOs, which is just in the end flow time. Mik Kersten: How long it's taking to deliver value, one of the key economics of flow, which then has you of course unpack all the things slowing it down, be that the fact that you've just lifted and shifted an application, or that you've actually done the right things from a software point of view, but none of your processes changed, none of the way that you're measuring people changed. So you're not going to get any of the benefits of that massive Cloud investment you're making. Justin Watts: Or you wouldn't even know. Mik Kersten: Or you won't know, that's right. Exactly, you don't know how much benefit you are getting. So yeah, this has been a fascinating thing. In terms of these things that fundamentally have good principles behind



them, Cloud the way they're being dis-employed. You touched on the Spotify model, when my teams first started adopting some of the notions of the Spotify model, that seemed good, but they were focused on flow, not on some cookie cutter thing that came from a very nice whitepaper. But again, we're seeing these things completely misapplied right now without the right kind of physics underpinning them. Justin Watts: Yeah, absolutely. I just reflected on a little note I wrote here in terms of one of the things for say for example, senior leaders looking at software teams, go back to manufacturing and queuing theory and what we talked about, utilization. As a factory manager looking at a physical unit, and I know you've done a lot of work with BMW in your book, the case study. And as a factory manager you would look at the system and you would know that how much demand was coming in from a customer and how much capacity you had, and they're fundamentals. If one outstretched the other, i.e. demand is greater than capacity, you're in trouble. You cannot have good flow in that environment because you'll end up basically [inaudible 00:41:55] scheduling, you'll end up making more stock than you require, it'll just go to pots from day one if you've got more work to do than you can handle. Justin Watts: When you think then about a level of aggregation, whether you're looking at a portfolio, IT portfolio, or a software development team, those principles, that principle about utilization, whatever level of aggregation you're looking at, they hold true. So if you've got a team with more work than it can do, you'll never achieve good speed to market. If you're looking at portfolio work with more work in it than you've got capacity, you're [inaudible 00:42:31] from day one, you'll get contact switching, you'll get the business shouting, "Where's my thing?" You'll get change in priorities, you'll get multitasking, and you get slowing down the productivity and you'll get into a viscous cycle. Justin Watts: So even at that basic level of aggregation of how much work's coming in, how much work can I do, these are really counterintuitive things in service organizations when you get further back in terms of where software IT's done, a little bit more in focus at the front end because you've got real customers calling. But taking those principles into software delivery are counterintuitive number one, but actually if we don't get those things right, we'll never achieve better flow. So that's I think a good way of thinking about the level of aggregation with these things, they work at whichever level, you look at whatever system. Mik Kersten: Yeah, exactly, exactly. And so, I think it's amazing to see what you've put in place that front, because I think it needs to be visible at those higher levels. A lot of the technical teams already understand some of these dynamics. And like I said, these are not, with your principles and practices, these are dynamics, you can't just take one and apply it. There's an interdependency between these things. Justin Watts: They're all aligned, they all work together. That's the thing we are learning about these principles and practices now that they are so intertangled with each other. For your point earlier on drive out fear, how would you actually get to a position where you start the drive out fear? Well what we found is that if you take a team and you work really hard on improving flow by really understanding the systemic constraints, not the people aspect, then you start to show that the constraints on delivery are systemic, which in turn then through the right measures, start to show the real problems in the system, which are not people related. Justin Watts:



And then you start to drive out fear because you're using different metrics, you're producing different results, and then you start to get to a position where, this is actually really cool, we're really [inaudible 00:44:31], we're doing some fantastic stuff, can we do more, can we do more, can we do more? But that doesn't always work that way because sometimes you need a really brave leader who might be working in a system where we haven't driven out fear, there is quite the fear of [inaudible 00:44:46] environment. It is delivery date focused, it is very much driven on old measures, and it's very difficult to break the cycle. And you do see a lot of leaders who are completely busy doing their best in systems which got flow efficiency of less than 1%. Justin Watts: But because we haven't got the right measures we can't see it, and we can never make any time to get better. So it's definitely, we're not going to get into it today, but what we've learned as well is about how would you intervene in those systems to actually make them better? And there's definitely a piece where we take our value stream leaders offline for a bit so they actually study what's going on in their work. End to end, what we find is we've got some transformational kind of results, and the only reason we've got those transformational results is we've taken the senior leaders to go and study the flow themselves. Mik Kersten: Yeah, and that's a key thing, because this has been interesting learning for me with some of what you've been doing [inaudible 00:45:45]. And you mentioned early on is that what concerned you early in software is it looked like 50% of systems weren't being used there. And the [inaudible 00:45:54] had 70%. And I remember reading those things early on like yeah, this is completely consistent with my anecdotal experiences, which is the just the sheer amount of waste in the code basis in the systems is astronomical. 1% flow efficiency is egregious, imagine manufacturer saying 1% flow efficiency. Mik Kersten: So the really amazing thing about that is that the systems are actually easy to improve. So one of my favorite things I've seen, and I was always borderline whether to keep the happiness metric in the Flow Framework or not. And I'm just so happy I kept it, because it gets back to this drive out fear. When you start seeing flow efficiency go from one to 2% just by getting rid of some of the most obvious bottleneck or simply just by doing what you've been saying to do. Just reduce WIP, just manage WIP properly, you see employee engagement scores go up so quickly that no amount of productivity could actually do. Justin Watts: Absolutely, absolutely, yeah, yeah, yeah. I totally agree. Your results are consistent with ours, and it's not just software delivery systems. But every time we've gone in and improved how the work works from a customer perspective, you get happier people every time. Mik Kersten: Yeah. Justin Watts: And happier employees every time, without doing anything around a psychological safety campaign or, and I'm saying it with a tongue in cheek, but we tend to go after those things completely because somebody said that we should do an engagement program and it'll sort the problems out. Well it's not, it's because the system doesn't work, that's the problem. Mik Kersten: Yeah, no you're frustrated when you're stuck on other people working through it [crosstalk 00:47:32].



Justin Watts: Absolutely. There's a couple of things, again I'll always go back to Deming, but his 95/5 or 94/6 rule around, he estimated that 94% of the variation in the system was common cause, i.e. the design of the thing. And only 4% of it was special cause, which a lot of people have associated to people. So Deming's theory was always that systems will perform perfectly with how they've been designed, they will. And better performance is in the way that we've designed our system or how we start to redesign the system based on lots of laws of flow and the principles and practices that we're talking about. Justin Watts: And that's what I think we're benefiting from is that I think we are actually benefiting from the fact that we've got a lot of different thinkers in our team, in my team, we've got a lovely blend of people who've got some brilliant Agile experience and are technically very good, and they've come from an Agilist background. And we've also got quite a few of the people who've come from a manufacturing background, and we've got people who've come from a systems thinking background. And it's allowed us to be critical friends of each other as well, and it's allowed us to really challenge lots of the things that are out there I feel like in terms of like I said, the cookie cutter models, and now you do transformation and Agile and digital and service design, so on and so forth. Justin Watts: And we've been able to really knit a lot of our experience together to come up with a way of, based on our core strategy of flow, of how do you make it better, how do you improve it? What are the things that are currently wrong? So yeah, I think we've learned a lot in a very rapid time frame of how to do it. But I think one of the key things of how we've been able to do that is by keeping our strategy really simple and centered on flow. Mik Kersten: Yeah. We're almost at time, there's something that you're connecting a few dots for me here is this notion that you said early on, that Toyota could not afford to produce like Ford. I think we're in the situation right now where a lot of companies who are transforming, traditional businesses, simply cannot afford to produce like Amazon, cannot afford to produce like Google. This is the point that we're in. And it's interesting what you said, I just want to make sure that I've got this right is there's this over focus on economies of scale within leadership of organizations who want to step up their digital game, because they know tech giants will come after finance at some point, will go after healthcare, will go after other industries. They need to grow into their stock prices. Mik Kersten: Without that focus on the economies of flow, and I think that the way that you say it makes it clear to me that that's what's taking things sideways. If you don't understand the economics of flow, you'll never get the economics of scale right. And of course what the tech giants have done is actually both, they've got the economics of flow that they've managed to scale, which means that they measure and manage scale in a completely different way than other [crosstalk 00:50:25] that they're used to. They've got this completely aligned product and business value stream and technology and organization architecture, which is actually how you scale the economics of flow. Not by continuing with these separations and these metrics that cause silos to form and handoffs to form. So did I get that right or anything else that you wanted to add to that? Justin Watts: Yeah, if you think about it, if you've got an organization that's built its legacy on a financial system that says the more you produce, the lower the unit cost will be, which is what the economies of scale is built on, then you'll find that the organization has been specializing and functionalized the hell out of basically,



because we think it's cheaper to do it that way. And if you drag those principles that mass production is cheaper across the software production, what you'll find is we'll be measuring individual productivity of coders, we'll be keeping people busy all the time, we'll be maximizing resources and utilization. Justin Watts: And all those things make you slower and drive cost up. And one of the things that again John taught me again is that every time you try and manage cost, your costs will go up, every time. And what Ohno learned was, it wasn't the cost of the unit that counted, it was the cost of the manufacture on the whole. So it's the whole system cost which is really important. And if you think about what we talked about from a flow efficiency perspective, flow efficiency would be hidden completely if you're using unit cost based on economy of scale accounting measures. You can't see it, it's not there. And when you move and change your measures to things like flow efficiency you go, oh my word, the cost of delivering this piece of code or software is phenomenally higher than what we thought end to end, but our unit cost looks really good. Mik Kersten: Cannot think of a better way of articulating that. Every time you manage the cost, you drive cost up. Justin Watts: Yeah. Mik Kersten: Justin, this is amazing. Any other pearls of wisdom you want to drop on us before we wrap up? Justin Watts: Again, we haven't gotten it completely right. There's lots of learning still to do. But I just think that we are... I was inspired by your work as well, I must say that. When the worlds met really around the problem we were trying to solve, I think that's the key for us. Like you said, we're not there yet. But simplification of our strategy back to flow and what that means for the thinking changes required. Justin Watts: Like I said, if organizations have been built on the economies of scale, the measures, the structural way that we've put it together in terms of the functionalization, the specialization, if you don't tackle those things in your transformation, then to your point, lo and behold you can do as much Cloud stuff as you want, but you'll never ever get the benefits that you thought you were going to get because you just haven't changed the thinking or the fabric of the organization along with it. And I think that's why our transformation will work at some stage, because I think we're trying to do it right because we've identified all of those things that are wrong with our organizations generally put together measured. Mik Kersten: Exactly. Okay Justin thank you so much, I hope that people can internalize especially this, is that the core to seeing this is by focusing on economies of flow rather than economy of scale and the other way of doing things. Justin, thank you so much. We'll put a link to John's work there and I hope that people take some inspiration from this on how to get things off on the right footing in terms of their effort. So thanks again. A huge thank you to Justin for joining me on this episode. For more, follow me and my journey on LinkedIn, Twitter, or using the hashtags MikPlusOne or ProjectToProduct. You can reach out to Justin on LinkedIn. I have a new episode every two weeks, so hit subscribe to join us again. You can also search



for Project to Product to get the book and remember that all author proceeds go to supporting women and minorities in technology. Thanks, stay safe, and until next time.

episode 20: justin watts episode transcription

Documents