I am Chris Gallivan. I work for PlanView as a flow advisor. I've been looking for flow for the past three years along with my clients, and I've learned a ton. And today I want to share with you some of the learnings we've had along with our clients as we look for flow in large organizations. Before we, we talk about, where to find flow, where people are looking for flow. I think we should define flow because I don't think we all have the same definition. It's not even obvious to me sometimes. So since it's 2024, I figured we would ask you at GPT. The first time I asked you at GPT what flow is, it came back with the answer that was the industry definition of flow in terms of a state of being. So this is that idea that a person could be in flow Where they're performing their best, where they can do no wrong. Anyone who's ever been an athlete or a musician hopefully has felt this at some point in time. You have good days and you have bad days. Sometimes you have this really good day where you can do no wrong. That is what we mean by flow in the first definition. However, when I work with my clients, generally a different definition of flow. What I generally mean is this idea that we could bring valuable software to users faster. And how do we do that? And that's the second definition on the right. So which one is it? Is it the first definition or is it the second definition? From my perspective, the answer is it's both. If you think about it. You can't actually be in flow as an individual and not produce something of value. If you can do no wrong, that means that your instincts are right, you're thinking very clearly, you're thinking about your customer. That's, I think that's always going to produce faster value for your customer. And on the other hand, if you, in order to get your organization truly bringing value sooner to customers across the board, you have to enable flow for your people. If your people don't feel it, they're not going to do it. So you need both. I think the answer is both. So now that we've defined it why do people want flow? What is it about flow that, that is attractive to people? Why is everyone talking about this for the past few years? There's a lot of reasons why pretty obvious, but the reason that I think we're really interested in it is that I think as humans we're fixated on time. From the moment we're born we're always chasing time. We never have enough time. We always want to do more with the time we have. So I think there's something about us that, that's always looking for flow. And that's why I think it, it's something that resonates with so many people. The thing about time that's interesting is a lot of times we try to think of time as counting time. So we count the amount of time we spent on something and we want to shrink that time. But when you really look at time, not all time has equal value. So in this example, the first picture is a picture I love, that's my youngest daughter and I was making pizza with her and I was so caught up in the moment that I didn't realize the way that she was experiencing that moment and the picture kind of captures it. It was priceless and it was about 10 minutes of my life. The second picture is a picture of my pizza oven that my wife and I built together and it took three summers, so it took a significant larger amount of time. They both mean a lot to me. But I think you would understand clearly the first one means more. So just because something takes more time doesn't mean that it means more. Not all time has equal value. There's a book called Saving Time by Jenny O'Dell. And in it Jenny says, Time has felt the most expansive and I have felt the most alive when I was in an encounter with something or someone that was surprising. Something that I didn't necessarily expect. And this is similar to the last slide. This is basically this idea that time has a quality to it. There's good time, there's bad time. And what makes something a good time? Often it's something that happened that you didn't expect. Something surprising. Something where you learn something. It turns out that you feel the most energized when you create your best work in the shortest amount of time. So that's the idea behind Flow and why I think Flow is exciting. A lot of our thoughts today are influenced by things that happened before us. So if we're going to talk about where people look for Flow, And where do they find flow? I thought we would take it back to the industrial age. Cause I think some of the way we think today came from the industrial age. So back in 1909, Frederick Taylor, most of you have probably heard of Frederick. He published the principles of scientific management, and these are four of his principles that he published at that time, discover the most efficient way to perform tasks that makes sense. Everyone wants to be efficient. I'm sure they still want to be efficient today. Clearly defied responsibilities. Not quite sure what he meant by that, but on the surface, it seems to make sense. Pay according to performance. I think we all work in companies where we're paid according to our performance, we would all want to be paid according to our performance. I think rigid hierarchy and strict surveillance of employees. That one kind of stands out. I don't think many people. Would want to work somewhere where there was a rigid hierarchy and strict surveillance of their work. If you read a little bit more about Taylor, my take on Taylor is he's the guy who invented the manager role. The actual role of managers. I think it came from Taylor and he also invented, it seems, the consultant role. I think that also comes from Taylor's thinking and also racy charts. And I'm sure there's many other things that came from Taylor. My take on him is that he had a tremendous influence on the way people work over the past hundred years or more. I want to drill in a little bit to one of his principles and it's this idea of dividing the work from the responsibility. This is a quote from Taylor, which I found shocking. In most cases, one type of man is needed to plan ahead and an entirely different type to execute the work. The fact that he uses the word man is a little bit offensive to many people. But even the concept is a little offensive because it suggests that only certain type of people are fit for planning and the rest are fit for working. And I think, now that I think about it, my career, I've been working now for over 30 years. A lot of the thoughts of the people that I've come across, I think, have been influenced by some of these ways of thinking, and I challenge these ways of thinking. Out of Taylor's work, a simplistic view of an organization has emerged, and it still remains in many parts of the world. This idea that we have this tower, and in the tower sit the management, and then in the rest of the company sit the workers. In this sort of two step company. I challenge this concept. So that's that's the industrial age, but I think it would make sense that we also spin forward to the digital age and evaluate, how do we think about flow in the digital age? You can see that many of our thoughts have been influenced by the past. If I think if you're like me, so we're a hundred years past Taylor, actually more than a hundred years. And I've asked some managers that are clients of mine, why do you think work is delayed? So you want to improve flow. Why do you think flow is getting held up? And here's some of the answers that came back to me. Inefficient processes, so we have processes that aren't as good as they could be. We have unproductive people. That's interesting. I think they mean unproductive workers when they say that. We have people not following the process. Okay, so that's a case where the process isn't bad, but people aren't following it. And then we have this one, which is one of my favorites. People taking on too much whip. Suggesting that people actually are doing it to themselves, and they just need to lay off taking on too much work. I think you can see from these four, four, these are the four primary answers I got when I asked this question to managers. These are almost directly attributable to Taylor's scientific management principles. It's amazing how closely they match. If you're looking for these things, if it's not evident, I don't think this is where you're going to find flow. So there's this thing called the spotlight, the streetlight effect, or the spotlight effect and the picture shows it here, and I think a lot of managers and many of us fall into this trap. The picture shows a police officer asking someone who's on the ground, did you lose your keys? And it's under this big streetlight. And the person says, yeah, I lost them over there, but the light's better here. So the way I take this, it's the idea that we measure what's easy to measure. We don't always measure what we need to measure or what we should measure. We measure what's easy to measure. And as a result we often wind up getting false signals. We measure the wrong thing. So if you take that idea and you think about the last 30 years and where we've tried to shine the light and make improvements we had the agile revolution started over 30 years ago. And then we had the DevOps revolution. Maybe that started 10 years ago or so. And basically what that did is it shined a light on a piece of the value stream. An important piece, but a piece. As a result, we have lots of ways of measuring this piece of the value stream. We've made a lot of improvements to this area. But the natural question is, what about the rest of the process? When you look at where time actually goes, if you were thinking like a customer, You make a request, and then it comes in 120 days, 100 Plus 20 plus 50 under 90 days later. You get your request fulfilled. So yeah, good job IT You sped up the last 70, but what about the first hundred and twenty? What's going on there? In order for us to really go after that and understand it We need to put a streetlight there and we need to start measuring there and try to understand What can we do to speed up that part of the process after all that is the longest? Amount of time that's elapsed in this example. So just like I asked the managers, why do they think work is delayed? I asked the same question to the workers. Sometimes these are developers and Skrull masters. Why do you think work gets delayed? And the top answers are on the board. These are some of the answers that came back from those folks were working on the wrong things. So we're not even working on the important things. We've got too many disparate demands coming at us from different parts of the organization. in. We've got scope creep, so we ask, they ask for one thing, we implement it, then they ask for something else, and it's slightly different, and then we have too many number ones. I think you can see, if I ask a role in that two, two role simplistic view of an organization, where's the problem? The problem's never in the person I'm asking. The problem's always someone else's problem. Someone else is doing a bad job. I came from both sides of this in my career. And in my, certainly from the worker side or the development side, my response to their answers here is poor babies. I think that's an immature thing to do, point to leadership. See, the thing is essentially what IT or what the workers are saying is I can't keep up and it needs you to dial back the demand so that I can keep up. And while there might be some truth in that, I think there is actually some truth in that. I've never met one business person that I could say that to. And they said, sure, I'll dial back to work. Actually I might've met one, but in general, that's not a good approach. If we need to dial back to work, we got to figure out a better way, a better message to send. I think in general, those of us who have been involved in the Agile and DevOps revolution, we've allowed ourselves to become task focused over the past. 15, 20 years instead of value focused, I think agile started off focused on value, focused on customers and what our customers need and how can we make customers lives better, but somewhere along the line, we became much more focused on the work itself and the tasks that we're doing instead of the value that we bring to the world. And when we go far enough in this state, we eventually become comfortably numb in red. This is a quote from Domenico de Grandis. It's basically that type of person, and I know you've met people like this, I've met people like this, I've even been like this, I think, at points in my life, where someone comes to me with some new change that's going to make things better, and my response is pessimism, apathy. I've tried all these things before, none of them work, this will never work, is the response that you get from this type of person. And a lot of these people are people that we work with every day. The question I always have for someone like that is, Are you sure you tried the right things? I know you tried some things, but were they the right things? Often times when I ask that question, I find that there was something a little bit wrong with what they tried. So now that we've talked a little bit about, How do we think the way we think about flow? And how did we get here? Let's just examine quickly some places that I find people looking for flow. So some corporations focus extensively on features. They move from one feature to the next, and they have a huge backlog full of features. And when you try to talk to them about the other types of work and the other things that it takes to have a healthy product, they just brush it off, and they want to talk more about features. If it isn't obvious, This is not where you find flow. This is not how you find flow. So you have a company that's obsessed with new features, but when you really look at the work, 90 percent of the work they're doing, And the more you build features, the 90 percent goes up to 95%. It actually keeps getting worse and worse and worse. The question arises, what are the hidden costs of adding more features? So to illustrate this, I want to do a quick demonstration of something we call the debt spiral. So there's companies like this, as we know, that push out feature work. As their primary mode of operation over and over year after year. As you do that, debt and risk and toil pile up in your software. It's just a fact. You write code intending it to do something and something else happens in the background. Toil as well as quality going down because defects are piling up. We've known this for over 50 years and we still haven't solved it. You can do this for a while and you can keep your head above water, but eventually get to the point. Where there's so much defect work and there's so much debt and risk built up into your system that it's very hard to build any new features and your feature work slows to a crawl. This actually happened to Nokia and they actually went out of business. This is actually what killed Nokia. How do you get out of this? How do you actually get out of this debt spiral and pull out? What you have to do is you have to put your feature work on hold for a while. And this is a difficult move to make. Because most people that, that feed the feature work into the system at top down companies, they get incented and promoted based on pushing out feature work. So when you're asking them to pause feature work, there's a personal reason why they don't want to do it. But those companies that are forward leaning and strategic, they do find ways to do this, including our company at PlanView. When you do this and focus on debt work for a period of time, You can make a big difference. And when I say a period, I don't mean like a week or a month. Sometimes this could be six months or a year of focus. I have one client that it seemed to focus on debt work and modernization for two or three years. And it was their strategic area of focus for two or three years. That was their strategy. The idea is if you do that for the long enough time, you can actually get to the point where your defects go down almost to zero and your debt, your risk and your toil go down. And Which, of course, gets you the results you were after in the beginning, which is your quality goes up and your feature work goes up and everyone's happy. This sounds too simple. Many people haven't done it. Those that have are doing quite well with it. A lot of other people tend to look for flow in developer productivity dashboards. The word productivity has been all over the market for the last several years. And I hate to say it, but I don't think this is where you find flow either. As I said before, 90 percent of software costs are maintenance. So if 90 percent of software costs are maintenance, and 70 percent of your coding effort is understanding the code, most of the time we're spending is just trying to understand what to do. So if we really want to make a difference, if we really want to make people productive, wouldn't we just make the code easier to understand, which could be a tech debt initiative? Makes sense to me. Another thing about productivity, and this is going back to the very beginning, humans feel the most energized when they feel some sense of agency over the work they're doing. They'll run through a wall for you if they have a say in the work they do. If 90 percent of the work at your company is dictated by the management, how much do those people feel they have a say? So if you really want a productive workforce, give them a say over the work they do. Stop telling them what to do. Give them some say. Let them come up with the way they're going to solve these problems. And what problems are they going to solve? If you're really after productivity and you refuse to give them a say as we all know, 70 percent of what we build our users probably won't even use. So my prediction is 70 percent of your software won't be used by your users. But of course, that's not the kind of predictability you're probably after. Another place I see people looking for flow is in scrum dashboards. 30 years later, we're still trying to get scrum perfected. Still not a good place to look for flow. I find a lot of companies that are really trying to adopt rigid scrum, and they pride themselves on delivering stories to an artificial cadence. But when I ask their customer how long does it take you to get value, I find a lot of dissatisfaction. One of the customers actually said our delivery of value looks the same as it did 20 years ago. And from my experience, that's really not that far off. I wouldn't go through all these different, detours if I didn't think there was a better way. And I'm happy to say that I think there is a better way. But it's quite a bit different where most people think they need to look for flow. I actually think flow and the way companies should be organized looks more like this picture than the original picture with the two separate circles. Demand generation and demand fulfillment Demand. Can't be separated. Strategy and execution, they need to work together. There is an overlap between the two. And the more that you figure that overlap out, the better off you're going to be. If you don't figure it out, flow eventually gets lost in the seams between the people. While this is a simple way of looking at it, it's far more complex than this, obviously. So if you look at a typical software development process that takes ideas and takes them to impact with customers, you'll see that there's a lot of different people and stakeholders and groups involved from sales, marketing, business owners, product managers, product owners, designers, front end engineers, backend engineers, different teams. We even have engagement managers managing the developers and product owners giving the developers work. So this is. These are a lot of different people involved in this. We have release engineers. We have support engineers. Everywhere you see a bubble on this chart, you have a seam. There are seams everywhere. And if you don't manage the seams, that's where flow goes to die. So the real reasons The reason why flow is impacted, the reasons that actually cost us the most money are the things that happen on the seams. These are things we can't figure out by ourselves. The first one is we haven't figured out how to schedule our work in a way that delivers value the fastest to the customers. Engineering can't schedule work on their own. Product can't schedule work on their own. This is something we have to do together. And we don't do things together very well. We have poor handoffs from product to engineering. We make bad choices, both on the technology side, as well as the product side. We have unplanned work that comes up. That unplanned work comes from both sides. And we're not very good at figuring that out. And we have quality issues. Quality is everyone's problem. It's not just engineering's problem. So we need to figure out how to, how do we work together to solve these things. A long time ago, 2001, a paper was written called Nobody Ever Gets Credit for Fixing Problems That Never Happened. In the paper, the authors described two loops. The first one on the left is called the Working Harder Loop, and the one on the right is called the Working Smarter Loop. Every company has a gap with their competitors. Every company wants to close that gap. The problem is, gaps never stay closed, because everything that comes together eventually falls apart. This is the second law of thermodynamics. It's just the way the world is. So you're constantly trying to close gaps with your competitors. The working harder loop closes the gap by working harder. Trying to get people to work weekends, and work extra hours and do the right thing, you know. That can work, and it does work. The problem is, it doesn't work for long. The second side is the working smarter loop. So instead of trying to close your gaps with your competitors by working harder, You're trying to close it by investing in new capabilities, by improving your processes, by doing debt work, and improving your software. The problem is, when you work smarter, there is a longer time to feedback. Much longer time to feedback. You can see the loop is a little bit longer. And you have to be patient. If you're not patient, and you can't wait for that feedback, you short circuit the loop and you go back to the working harder loop. There's a lot to this paper. It's available on the internet, but I think they knew in 2001 why continuous improvement isn't sticking in companies. It's pretty much outlined here. It's mainly because humans don't do well when feedback is distant in time and space. We need to find ways to encourage people to be more patient. Now, it's easy to say it's hard to do. I understand. I used to be a musician. I played in a band for a number of years that was going to be my career. And then I got a real job working in it and the rest was history. Miles Davis, Chopin, others spoke about this concept of the space between the notes. So everyone wants to divide things up. You do your part, I do my part. The racy says I do this, you do this. The problem with that is that there's real things of value that happen between us, or at least that could happen between us. Musicians know this. If you look at a jazz band, you take a jazz band in first grade and you watch how they're playing their instruments. Each person is focused so much on their instrument. They want to do their part. That's the only thing they're focused on. They're not listening to how can I interact with the person next to me and make something better. If you go to a club and you find a really good jazz band, let's say in Detroit where I'm from, they're doing the opposite. Those guys are more listening to each other and interacting with each other, and they're not trying to stay in their own lane. They're trying to create something that's never existed before. That sounds a lot like software to me. That sounds a lot like what we're really trying to do. The surprises. Remember from the beginning of the talk, that's where the real value is. So my advice is resist the urge to break everything down into pieces and lose your focus on the whole. It's okay to break things down, but you still got to find a way to keep the focus on the whole because that's where the real value is. That's where the real surprises are. Focus on the customer. I've got a few tips to leave you with here at the end. I just have a rolling list of tips. These are some things that I'll provide you with. I think value measurement and measurement of work is really important. And if you look at the way we measure value, it's changed a lot over the years. So back in the waterfall days, we had these big bulky projects and we had these statements of work and we knew what we were delivering to customers. We were pretty clear eyed on that. Everyone on the project knew what it was cause it was big and it was bulky. And then we swung the pendulum way over to the left and we started measuring stories with Dora and other measurement approaches. And people lost sight of what it is we're trying to bring to the customer. We're so focused on our cadences and our iterations. I think the pendulum needs to swing back a little bit to the middle. Like a happy medium, where we have features that we deliver to customers. We know why we're delivering them to customers. And that's really where our focus of measurement is. This idiom can be thought of in a lot of different ways, measure twice, cut once. Most of the time we spend doing software development is thinking about what to do, and a small amount of time is actually doing it. The same is true of design of software. Make sure you put your best people on the thinking. Don't have someone else doing the thinking and someone else doing the development. Put your best engineers on the thinking. That's where you're going to get the most benefit out of design work. Identify and track dependencies. We've never been good at this. www. microsoft. com www. microsoft. com We still need to do it. It's going to be required for us to improve our flow. Focus less on prioritization, more on sequencing. If you've started something, try to finish it before you start something new. We call this fastest value first. Pay attention to unplanned work. Find ways to signal it. Once you have signaled it, find ways to remove it. This is one of the biggest drains on flow that we see with our clients. Understand your variability. Average numbers, like average flow time, Averages of any sort can be misleading. Look behind the variability to see the lanes in your traffic and try to understand what's really happening. And last but not least, you make choices every day. Are you going to work your people harder? Are you going to point your finger at them? Or are you going to work smarter? If you're going to work smarter, you need to encourage people to be patient and wait, because the benefits of investment in the right thing are worth the time. Thank you very much for listening to me today. Have a great conference.