Podcast Ep #16: Aligning Your Firm's People and Systems with Tim Lennon

As he grew in the methodology, however, and as his work roles changed from being a little more zoomed in on the details of individual technology projects. To zooming out to see more of the company wide and even society facing impacts of technology changes in banking and finance. He started taking more of a broader sort of a systems thinking approach to his work. And that’s when he started to embrace the Kanban method of organizational improvement. That’s what you’re going to hear us talk about today.

You’re going to hear Tim talk about his experiences using and teaching the core practices of the Kanban method, things like making work visible, limiting work in progress, managing flow and others. And you’ll hear him talk about how those practices work together to create balanced systems that are better primed to create better customer outcomes while also creating internal balance for members of the delivery teams.

You’ve heard me talk a lot about the individual practices and concepts from the Kanban method. But I think listening to Tim is going to help you really tie some of those concepts together so that you’ll want to adopt them or adopt more of them in your own law practice. Ready to become a more agile attorney? Let’s go.

Welcome to The Agile Attorney podcast powered by Agile Attorney Consulting. I’m John Grant and I’ve spent the last decade helping lawyers and legal teams harness the tools of modern entrepreneurship to build practices that are profitable, scalable, and sustainable for themselves and their communities. Each episode I offer principles, practices, and other ideas to help legal professionals of all kinds be more agile in your legal practice.

I am so excited for this episode to introduce my now friend, but former teacher and sort of a mentor in my journey around agile and Kanban methods, Tim Lennon. Tim, thanks for coming on my show.

Tim: Thank you for having me. So I guess a little bit about myself. As you mentioned, I’m a trainer and a consultant and coach. I work with individuals and organizations on helping them make work flow better through the organization. How the different parts of the organization can share information better and become more efficient through it. So I train classes and I work directly with clients to help them enable flow in their organization.

John: And the tools you use to help them enable flow are sort of loosely under this umbrella of agile and lean and these other things that I’ve talked about in varying degrees on this podcast already. How did you begin this journey into these methodologies?

Tim: I joined my first scrum team in 2001, back when scrum was still kind of squishy, we were still figuring it out. And fast forward to 2010, and by this point, scrum’s pretty baked and we’re seeing places where it’s not always a good fit. And there’s this weird Kanban stuff on the internet people were talking about. Several gentlemen now, David J. Anderson published a book, Mike Burrows, as well, about Kanban. And how it has been adapted from manufacturing for knowledge work and we call it the Kanban method.

So it’s basically a set of techniques and approaches on introducing basically managed evolution inside of an organization to help it become more efficient.

John: Yeah, that’s great. And for those of you that have been listening to this podcast so far. I’m talking about a lot of concepts including the Kanban board, which is obviously pretty clearly tied to the Kanban method even though I haven’t been saying, “And now you’re going to learn phase two of the Kanban method.” So things like work in progress limits, things like managing bottlenecks. This is all stuff that is part of this methodology that I had done a lot of work and study on independently.

But then when I first met Tim, was I actually signed up for an accreditation class for some certification in the Kanban method. And it was great because I thought I knew a lot and I obviously had done a lot of work. But Tim helped me take it to just a whole nother level of understanding not just what the tools were, but why they work. So again, thank you, Tim for that.

Tim: My gosh, thank you.

John: Yeah, enjoy our conversations beyond that. So you teach a lot of Kanban classes, classes to people about the Kanban method, to folks that are pretty new to it. And I think you’ve got an interesting mix of people that come from the scrum methodology, which is a different form of agile practice. And you’re teaching them about the Kanban methodology, which as you said is sort of this interesting hybrid between agile and lean.

But you’re also teaching people that don’t have a background in scrum that are learning some of these things for the first time. What are some of the things as you’re teaching these folks that you can tell that they’re having the aha moment and you can tell, okay, they’re really starting to understand the concepts?

Tim: There’s a variety of points. But what’s interesting is the one that most people I see come to the aha moment is that the purpose of what we’re really teaching beyond just improvement is also about balance. It’s about balancing the needs of the work that needs to be done with the needs of the people who are doing the work. And gradually and incrementally improving over time instead of trying to force feed change into an organization, maybe before we know exactly what we need to change.

And it’s that aha moment of this is really about communicating with the different parts of the organization to know what we’re doing so that we can be in alignment. And so we can know that whenever this part of the organization asks another part to do it, it knows what to expect because we’re in communication. So that’s a big one, it’s the balance part of it.

John: And I think that triggers for me is also sort of the methods focused on making sure things are working at a human level for the individuals involved, for the groups of individuals that we often call teams, but they can be in different ways. And then certainly for the customers of these processes and the businesses at large. These are all human needs, human relationships, human dynamics that we can’t solve for using the tools of machinery.

Tim: Yeah. And it’s actually another aha moment that people have is, in talking about the people inside the process. We have a tendency to think of them as being two very different things. What we envision in particularly the method is that people are part of the system in the same way that a football player is part of the football game. The same is true with us.

And so when we start talking about things in particular around balancing and trying to make sure that we’re putting the appropriate amount of demand on something that can support it, it’s not just about the people. Because quite honestly you can hire the most skilled individual performer ever and if you put them in a system of work that doesn’t allow them to execute efficiently, they will fail.

So that’s why the Kanban method is very much that we are participants in the system, we’re part of it. And we’re not some separate entity that we’re going to regulate how much work people do, but we’re going to regulate the system independently. It doesn’t work like that. We’re all part of it. And part of the success is recognizing that we’re all part of the bigger part of the organization.

John: And that if the organization isn’t working at an organizational sort of systemic level then it almost doesn’t matter what’s going on at individual.

Tim: Yeah, that is true. I mean I’ve actually worked for organizations where they struggled strategically to kind of figure out what is the big theme. And we had lots of pockets of really high performing successful teams but the organization still kind of meandered, was still trying to figure it out. So you can be really efficient, but still not kind of get your legs where it gives you the efficiency you want because you haven’t figured out what you’re actually trying to solve.

John: One of the other things that what you’re just talking about reminds me of, and this is where it links back to the lean methodology. If there’s one thing that a lot of people know about lean, it’s this idea of using it to eliminate waste or to reduce waste. But I think what they miss without diving a little deeper is that there are sort of three high level categories of waste inside of the lean concepts and one of them is overburden.

And that overburdened resources, overburdened workers. So that superstar in your example, if you’re loading too much work onto that person, that’s actually a fragility. That’s a potential breaking point and ultimately could be a form of waste in that overall system.

Tim: Absolutely. And it sounds weird to think of it this way, but it’s literally creating a pressure point inside a system that literally has effects on the entire system. So if you think about it even from a team perspective, if you have one person who has more than everybody else, there’s a variety of different side-effects of that.

So absolutely it’s a huge waste because not only is that person overburdened and probably not working as efficiently as they could be. What’s going on with the rest of the team? Are they in the same boat, or are they underfed and they have less to do for some reason? So yeah, it’s very much a balance play.

John: So one of the other three is unevenness, which we would talk about in the Kanban method as lack of predictability.

Tim: And one of my favorite topics, variability. And variability is our kind of the bogeyman in the system that we’re always kind of on the hunt for.

John: Totally. And I can’t remember if I learned this from you or where it came from, but I brought it up in one of my workshops not too long ago. Everyone thinks that what they need to be doing is delivering faster, but what their customers really want is predictability. People will accept delay if that delay is planned for and understood or negotiated even better.

When you go to the dentist for a teeth cleaning you understand that their capacity to do teeth cleanings is limited by the number of seats and the number of hygienists and all these things. And it’s going to be maybe a few weeks or a few months before you can get that teeth cleaning. At the same time that dentist office is probably reserving a certain amount of capacity for people that crack a tooth or have an abscess or need a root canal or any of these things. And so the waiting for those services is a lot shorter because of the way that office is managing capacity.

Tim: In the Kanban world we would call that capacity allocation where we say, “Alright, this is how much capacity we have to do this type of work. Maybe we need to make sure that there’s always room for an emergency.” Because sometimes we have something that an emergency requires our attention. So what we’ll do is we’ll say, “Alright, so our policy is no matter what we’ve said the cap is for the number of things we’re working on, we will allow one emergency at a time.”

So we’re forcing and does it cause problems? Sure it does, but the emergency is actually the important thing at that point. Which kind of takes you back to triage and figuring out what’s really an emergency and what’s not an emergency and what is deferential and what has a date etc.

John: Yeah. I’ve started to talk with folks about learning how to distinguish between things that are giving off urgency signals as opposed to things that are truly urgent. Because I feel like we’re in this world of attention hacking where marketers and communicators and even everyday people have learned how to command attention through giving urgency signals.

And if you haven’t tuned your filter well enough, your brain will want to respond to that because that’s sort of what we’re wired for. And you have to really, it’s that whole Eisenhower quadrant thing of being able to distinguish between urgent and important.

Tim: That’s right. And the funny thing is it’s the escalation thing, it’s to let me speak to your supervisor. We don’t even want to be bothered. We want to instantly escalate and it’s got to be okay. And we kind of have to have that same reaction. Is it important? Sure. Is it important enough to grandstand and say, “Oh no, you can’t talk to my supervisor?” No. So we can make those same concessions too. It’s all about figuring out, like to your point, what’s urgent and what’s important to probably people?

And that’s one of the challenges. We don’t do a great job of figuring out and teasing out important versus urgent. And so what happens is we tend to start working on a lot of important things and then urgencies come up but now we have a problem. We’ve got all the stuff that we haven’t finished yet and all the urgent work is coming at us that really actually demands our attention right now. So all of a sudden we go from five things in front of us to 10 or 12 or depending on what the volume is, it could be worse, which is how we wind up with too much work and everything slows down.

John: Yeah. And by the time this one releases, it will have been a few episodes ago, but I talked about Kingsman’s formula, which is a version of Little’s Law that basically is this compounding nature. The more work you throw in the process, it doesn’t just build 1 + 1 + 1. The sort of demand and your capacity and your ability to have that workflow is exponential. The delays get exponentially longer the more work you have going at once.

Tim: That’s right. That’s correct. And as a consequence, it can only go one way and that’s to spread out across time. That’s the only place it can squeeze. That’s really what we’re squeezing.

John: Yeah, or something drops. And I think that’s the big fear. I mean you and I have talked about this before. One of the number one things I hear when lawyers reach out to me is, “I’m worried that something’s going to fall through the cracks.” And so they recognize this form of overwhelm, of overburden. They know their plate’s spinning and they’re juggling or whatever metaphor you want to use and they’re really hoping that they haven’t missed something.

Tim: I have to tie it back a little bit to, you were mentioning some of the practices where you’re talking about limiting WIP and bottleneck theory. Well, in the Kanban method we’ve got the general practices and literally the very first one is visualization. Visualize the work because we will feel overburdened. When we see it, it’s an entirely different reaction. It’s easy to keep your head down and just kind of grind through it. Oh my gosh, I’m working 14 hours, until you see it all in one place.

And then what was interesting about it, we talk about visualization because it has an emotional effect on us. And we’ve got a huge amount of circuitry in our heads that are devoted to our sight, so the amount of impact is pretty huge. And on top of that, the ability to align what we see with other people.

So you’ve mentioned Kanban boards and that’s the point. So that we can actually have a conversation about the state of things and all agree that yes, this is what we see and this is the state of things. And now what are we going to do about it? And the whole visualization aspect is to trigger us to ask that question about what do we do about it.

John: I love that and I see it time and again. I mean I hear all the time, once I’ve sort of helped people build that version one Kanban board is, now that I’ve seen my work this way I can’t unsee it. It tends to be a really sticky thing. But the other thing that I like is, in communicating about work. By having the work exist sort of visually in a more tangible way, you and the people on your teams and even your customers can have conversations about the work in a depersonalized way. It’s not accusatory, it’s not, how come you haven’t done the work? It’s, how come this has stalled?

Tim: That’s right. Why isn’t the work done yet, not, why haven’t you finished it yet? And that’s really what we’re trying to get at too, because we want to manage the work ultimately. The work and the system are the things that we need to be working and putting pressure on and moving levers, etc., not the people.

John: And in a [crosstalk] way, not a passive aggressive way.

Tim: Absolutely. Absolutely. We’re not talking around the issue. We’re still, I mean, Tim is still assigned to that work item that’s not complete yet. I still have to explain why, but we’re not coming after Tim. We’re trying to find out what’s going on with the work and it seems like a subtle distinction, but in live you can kind of feel the difference.

John: It really does make a difference and it ties back to the thing you mentioned at the very top of the show, which is people are part of the system. When we use the board and we’re talking about the work and it’s again one of the sort of catchphrases of the Kanban method is manage the work, not the workers. And I like that a lot. It’s a challenge in a lot of environments, including law firm environments because we’re used to a lot of management.

We’re used to a lot of experts at the top, superior bosses at the top that are sort of dictating the sorts of efforts that need to be made by the people on their team. As opposed to talking more about the outcomes that they want to see based on the flow of work through their system.

Tim: Right. And so it’s more of a you do this versus this is what I would like accomplished. And what people don’t think about very often is when you tell somebody, “We need you to do this.” You’re going to probably get what you asked for, which may or may not be accurate or good or right or what you need.

John: Or what’s actually needed, yeah.

Tim: Right. But if you give someone the goal of, I’m trying to get to this and even better, imagine now it’s going through a team of people or maybe at least two or three. Diversity of thought, three different heads put to it, come back to you with something you could not have thought of in a million years by yourself. And that’s the power of it of just kind of turning loose and giving people outcome oriented instruction, “This is what I want to see. How you get there, I don’t think I care, just this is what I want to see.”

John: Yeah. You’ve probably experienced this too, but a lot of the things that I use in my coaching and consulting practice every day are things that one of my earlier clients came up with on their own at some point. They wouldn’t have come up with it but for the conversations we were having. It wasn’t my idea. They came up with it and oh my God, it’s brilliant. I want to use that. Let’s keep that going.

Tim: I have built my entire career on ripping up other things that I’ve seen people do.

John: And it’s one of the great things about being in the role that you and I are in, which is that we get to see a lot more things than the typical practitioner. So for me, law firms and for you the clients that you work with. And so I always hesitate to call them best practices, but I can say this is something that’s worked for somebody else and so it’s worth giving it a try.

Tim: Absolutely. Yeah. And it’s funny because I actually do get asked a lot about best practices. And I tell them, I say, “Well, I have a list of practices that you could try but you ultimately are going to have to be the one to decide what’s the best practice, because this is just a toolbox.” Really everything we’re talking about is a toolbox and because every organization is different. And this is also quite honestly one of the challenges with Kanban, every solution looks different because different organizations need different types of flows. So it’s not a copy and paste ever.

We might start off with a little bit of a copy and paste just to have a jump start, but beyond that it kind of takes on its own life. And so Kanban is never identical, but it’s still the tool. So what’s the best practice? The successful one, that’s the best practice.

John: Yeah. And let’s dive into maybe one of the others, so we’ve talked about making more visible. We’ve talked about limiting work in progress. One of the other sort of tenets of the method, practices of the method is evolve experimentally. And so I’m wondering if maybe instead of me explaining that, can you maybe talk for a minute about what we mean in the Kanban method by evolve experimentally?

Tim: Yeah, at its core the Kanban method in general is an evolutionary change framework. And we don’t always see it that way because most people are focused on the workflows and moving work and getting it from point A to point B, etc. But the sixth general practice is improving collaboratively and evolving experimentally and it means exactly that.

It means that as a kind of the cap on our practice before we kind of reiterate, it’s as a group as a collective, let’s talk about what’s been working, what’s not working, let’s commit to improving something. Now, there’s a lot of, you mentioned scrum, there’s others that all have retrospectives. And they all do this. They sit down, they talk about, “Hey, what worked, what didn’t work? What should we stop doing? What should we start doing, etc.”

Put all their little stickies on the board. Figure out one thing that they want to fix. “This is it.” And then the very next week, they start doing that and it feels great. They feel like it solved the problem, but three or four weeks something else is weird happening. And so it happens, it keeps happening and then they retro. Well, here’s the problem. All these little changes that they’re putting on, they’re actually bandages and we’re not even sure we’re putting the bandages in the right place because we haven’t experimented yet.

So in that sixth general practice, we talk about evolving experimentally. So we’re not going to throw darts at it. We’re not going to roll the dice. We need to have an actual intellectual conversation about here are all the opportunities that we can go after to help improve things. Or we can talk about it in terms of the problems that are creating the most noise, however we need to do it. And then of these, which is the easiest to eliminate? Okay, that sounds great. We pick one, but we don’t just go do it.

First we have an actual experiment. We create a hypothesis. We say, “Alright, we think this will happen when we try this.” We construct an experiment to prove it out. We collect the data from it and we make a decision. And if the data yielded from the experiment says, “Hey, probably a good change, give it a shot.” Then we say, “Okay, that’s what we’re going to do.”

And if the experiment says, “No, no dice.” Well, actually we still celebrate because what it means is the experiment did its job and prevented us from doing something dumb or harmful. So that’s kind of the big evolve part, it’s experimenting before we adapt or make a change to our system because every time we do, whether it’s a good change or a bad change, there is a brief, hopefully, reduction in productivity as the system is affected by the change.

So let’s make it count and not compound one problem perhaps with another problem and not know it again probably for another month or so, as it kind of finds its way to the surface. And that’s the whole nature of it.

John: Yeah. So there’s two things in there that jump out at me or to highlight. One is, you talked about having a hypothesis and then actually running it. But you also need to know what’s your measure, what is the thing that you’re going to compare or at least have an idea, an inkling that something’s working.

And then the other one and this is something I see a lot and I’m sure that you see a lot is this idea that when you’re running an experiment you have to be careful about what other changes are happening at once. Because if you’re not in something of a controlled environment, then you’re not going to be able to get meaningful feedback from that experiment. If you’re pulling 14 levers at once, you don’t know which one did the thing that you were trying to do. And any number of them could have been working against you.

Tim: And it’s kind of the drawback if there is one of Kanban because people are in a hurry. And we want changes introduced all the time. As soon as we find a problem we want it solved, but we actually wind up creating more problems for ourselves, just like the one you’re describing. Because what we’re doing is we’re putting a bandage on top of a bandage on top of a bandage. But we don’t actually know where the problem is to know where to put the band-aids and we’re waiting and hoping that things will get better, but they’re probably actually going to not help. Let’s say that.

John: Yeah, it’s a term I heard a lot at a particular part of my work life. And in fact, I think it was even part of the values of this company I was working at, at the time that we have a bias towards action. And I think that’s an interesting one because, yeah, we want to be moving, but action is not progress, they’re not always the same thing.

Tim: Correct, action is not always good.

John: Exactly. So we’ve hit now and I was going to hit you up for one of the other core practices of the Kanban method. Give me one other one that you find to be particularly impactful in the work that you do either training or especially consulting.

Tim: Yeah, it’s funny, I have to say that there’s kind of two. And I say that because I’ve got one kind of from the coach perspective that I think is the super impactful one. But then there’s the one that is a matter of practicality that when people start doing it, it’s kind of semi life changing. It’s actually the one right after limiting WIP and that’s managing flow. And the funny thing about the practice is, a lot of people don’t see them as one through six, but they are actually serial.

And so you have to do things in order to get the results you want to achieve. And that’s also where there’s some patience required. But yeah, that third one, managing the flow because that’s what we’re focusing on is the flow of work through our system. It’s the workflow. So once we have started limiting our work in progress all of our numbers stop being weird because at that point they’re not erratic anymore. We’re not randomly accumulating large volumes of things and then suddenly running out of work to do.

Things have started to stabilize because we’ve purposefully slowed them down a little bit. And at that point, that’s when we can actually start doing some legitimate measuring. And actually understanding how long it takes, either on average or as a distribution and likelihood to do x or to fulfill this type of request. And that becomes incredibly powerful because now there’s a number for us to react to. And again, even if we knew it was going to be awful before we did the math, it’s never as awful until we actually see it. And then we see it, we’re like, “Oh, no wonder our customers hate us.”

But that’s the power, because that pain is a massive motivator to improve things. We actually now have a target. And that’s why I think that managing the flow actually for a lot of folks especially in the beginning, as they’re just starting off, either as a team or as an organization, that’s the big unlock. Because it’s the first time that they can really correlate a number to their experience. And that gives them something semi concrete to try and change as a goal.

John: I love that. And I’m going to back up for a moment and just talk about or ask you to talk about when we talk about measuring flow. I mean, I think where my mind goes is lead time or cycle time, which are kind of similar ideas. In terms of what I see most commonly in the legal industry is that people are measuring effort in the form of measuring the number of hours that they are investing into delivering a piece of work.

But they’re not always measuring lead time or cycle time, which is how long from when the client or the customer, but the client in this case asks you to help me resolve this legal matter all the way through to the point where you can say, “Yes, this legal matter is done. You don’t have to worry about this thing.” Regardless of what the outcome was, it’s finished. Is that what you mean when we’re talking about measuring flow?

Tim: Yeah, especially flow because what we’re really talking about are measuring these actual things that we do, the work. And so when we talk about lead time, you’ve mentioned a few. There’s a lot of different flavors because it really depends on what you’re trying to measure. But the big universal one is customer lead time. And that’s measuring how long things take from the point the customer asked for it to the point the customer delivers it or the customer receives it rather.

And in your example, when you’re billing hours, what does 100 hours mean? Does 100 hours mean three months or does 100 hours mean, I don’t know, two weeks? What does 100 hours actually mean? Because while that number around the number of hours is absolutely important for billing, this is how we make our bread and butter, it doesn’t communicate anything about customer experience.

And at the end of the day, customer experience is actually what keeps customers coming back to us. But here’s the thing, if we’re only looking at the numbers from a revenue’s standpoint and we’re leaving all that other information off the table. We don’t actually literally get ready, here we go. Know how well the work is actually flowing to the customer. How is fulfillment going? Because this is ultimately a fulfillment game, this is a services game.

And as service providers, when a customer asks us for something, we evaluate what they’ve asked us for. We decide if we can do it. We decide if we should do it. When we finally accept it, we commit to do it. And then once we’ve completed it, especially, I think in the legal industry, now it’s time to recoup said funds for doing the work. Let’s get paid. It works a little different in information technology and in retail, but nevertheless it’s the same big basic chunks of, I need to get paid to do the work. I need to find out what the work is and now okay, fine, I’ll do the work and here’s the work. Those are the big two pieces of it.

John: Right. And you and I have talked before about how legal is a little different, especially hourly billing legal because you can receive value for partially finished work in ways that a lot of other industries can’t. But the thing that I have come to realize is that just because you’ve had that exchange of value for partially finished work, doesn’t mean that you’ve delivered the product or the final thing. So from a lawyer’s perspective, you’re still in debt in a way to that client.

And I’ve been calling it delivery debt because the thing that you promised at the beginning of the engagement isn’t, I’m going to work 100 hours on your thing and then however far I get, I’m going to leave you. You’re sort of making this implicit promise that I’m going to get you all the way to the end of this, and you’re going to have to pay me along the way. But I’m committing to finish this matter with you unless you stop paying me. Which is the other part of it.

Tim: Right. Yeah, absolutely. But when we talk about commitment and Kanban systems in particular, yeah, it’s the same thing as delivery day because that’s what we’ve done. We’ve made one of two types of commitments. Either we’ve committed to perform and deliver the work or we’ve committed to do one of those two things. Because we have so many situations where we have maybe one service provider depends on another service provider to put it in somebody’s hand for example like UPS. I might build something, but I need their service to give it to you.

John: Right. And again in legal, that could be expert witnesses, that could be other people that are involved in the process that we might have influence, but we don’t have control and we’re dependent on their [inaudible]. I was going to ask you because I know you’re working on this whitepaper about upstream Kanban. And I think what I may do is ask you to come back and talk about that in another show.

But the thing that I would love to sort of leave my listeners with, coming back to this notion of lead time and customer lead time. And I’ll sort of share my experience and then ask you to improve or say it in a way that’s maybe better than I will. In terms of that total lead time, it’s made up of two chunks of time loosely divided into working time and waiting time.

And my experience for most of the clients that I work with is that the vast majority of a lead time calculation meaning if you begin an engagement on February 1st and you close that engagement on September 1st. Probably 80 or 90% of the elapsed time is actually going to be waiting time where no one’s actually working on it. It’s just sitting around waiting for a resource or waiting for something to happen.

So I would love maybe your reflection on this idea that if you want to improve flow. And again my experience is people intuitively think that the way that I improve flow is to come up with ways that are going to accelerate my working time. But maybe the most significant way to increase flow is to find out ways to reduce or eliminate the waiting time.

Tim: Yeah, that’s exactly right. The delays, the delays are killers and that is death by 1,000 pinpricks. When work sits for a couple of days and it has to travel through five/six people before it actually gets to delivery. And it’s sat in between, that’s the scenario you’re describing right now. We actually measure that with what we call flow efficiency which is exactly that. It’s the amount of time spent actually working on something versus the amount of time it was in the service or in the system rather.

And that tells us for every hour how many hours that it’s been waiting and it’s not unusual to see and actually it it’s not even an industry thing. It’s an awareness thing. When we don’t think about flow, when we envision it we don’t think about things being as efficient or inefficient that way. But when we first see our flow efficiencies measured, they’re terrible. They’re always worse than we thought they were going to be. We literally can’t see or experience all the delays that happen.

So when you talk about these two chunks, how do we get fewer delays? A lot of organizations try and do that through the improvement initiatives where we’re going to increase our efficiency by 5%, which sounds great. But kind of the problem is we already have pretty, fairly efficient systems.

John: Yeah, we’re reasonably good at our jobs.

Tim: Yeah, we’re okay and now we’re diminishing returns and we’re not going to get very far. And actually the real problem most of the time is we just have too much in front of us. And because we have too much in front of us, we’re in a constant state of pivoting. Now, when we start looking at delays, how do we find those things, we can look through our systems and see, okay, where are the pause points?

But then the next question becomes, why? Why are things delayed? Why do they sit in that queue for three or four days before somebody picks them up? And as it so happens, most of the time, it’s because that person has too much on their plate. And the stuff in front of the things that are waiting is actually delayed also because they’re having to work across three, four, five, six different things all at once and can’t get any one thing really done. Which is something I think most of us feel, but we don’t often see it and that’s exactly what we’re talking about from an efficiency standpoint.

John: And that’s where, again getting back to making it visible, the Kanban board at least helps give us some feedback on what’s happening. As opposed to just that [inaudible] feeling that I’m on the hamster wheel or that there’s a ton of bricks on my chest or whatever the stress reactions that people have when they’re feeling that overwhelm, that overburden.

Tim: Most of the time systems that aren’t, or I should say organizations that aren’t really paying attention to a lot of this data that’s being generated over the course of just doing business. It’s kind of like driving down a freeway in a large vehicle with no speedometer. And some people are passing you, some people aren’t. So are we okay or not? Are we going to be in trouble? We have no idea because we’re not paying attention to the thing.

John: Yeah. Well, that totally resonates. I see that a lot. Well, I’m going to put in a plug for Tim because even though Tim helped me become accredited to be able to teach through Kanban University, it’s something that I actually don’t have the capacity to do right now. And Tim is actively teaching these classes. And so if anyone is interested in taking some Kanban classes and really starting to learn both what the methodology actually is and some of the philosophies behind it, how do they find you?

Tim: Easy, domorekanban.com or I’m also on LinkedIn, I think I might be the only Tim Lennon, I’m certainly the only organizational coach.

John: And you can always reach out to me and I will put you in touch with Tim.

Tim: Absolutely.

John: I think I’ve got my email address in my outro, and it’s certainly on my website. So I would love to get more legal professionals learning these tools and learning these methods. I think they are transformative for the people and the teams that start to adopt them.

Tim: Absolutely. I think Kanban’s got kind of a semi bad rap of only being for technology. But really at the end of the day it’s for any kind of work and that’s kind of the beauty of it.

John: Yeah. Not to lengthen this out, but one of the things that I think you and I have really connected on is that you’ve done this with a lot of non-technology teams.

Tim: Yes.

John: So we’re able to do a lot of comparing notes and stories and figure out the things that work well, which is again, I totally appreciate being able to bounce around ideas with you.

Tim: John, thank you so much and thanks for tuning in.

Thanks for listening to The Agile Attorney podcast. I’m your host, John Grant. If you found today’s episode interesting or useful, please share it with someone who you think would benefit from a more agile approach to their legal practice. If you have any questions, feedback or maybe a topic you’d like to hear me cover, you can reach me at john.grant@agileattorney.com.

To help other attorneys and legal professionals discover this podcast, it helps a lot if you could rate or review me on Apple Podcasts or Spotify. And of course, be sure to subscribe in your favorite podcast app. This podcast gets production support from the fantastic team at Digital Freedom Productions and our theme song is the instrumental version of Hello by Lunareh. That’s it for today’s episode. Thank you for listening and see you next time.