Podcast Ep #103: Bottlenecks in Law Firms: Fixing Flow Without Heroics [Agile Lawyering Part 3]

Once you make your law practices work visible, ideally on a Kanban board, it's almost always a huge relief. But then something uncomfortable starts to happen because you can finally see how much of your work is just stuck. And for a lot of people, that moment leads to a common conclusion. I know what the bottleneck is, it's me. I'm the bottleneck. And sometimes that's true, but most of the time, that statement is actually preventing you from understanding something much more useful and ultimately less personal about how work is actually flowing through your legal delivery systems.
​​​​​​​
In today's episode, I want to help you understand why work gets stuck, why bottlenecks are not a personal failure, and what you and your team can do to get that work moving again without heroics, without blame, and without chasing the latest magical thinking promise of speed or automation or AI.

You're listening to The Agile Attorney Podcast, powered by GreenLine. I'm John Grant, and it is my mission to help legal professionals of all kinds build practices that are profitable, sustainable, and scalable for themselves and the communities they serve. Ready to become a more Agile Attorney? Let's go.

A quick note. The concepts I'm discussing today should be useful to you no matter what kind of law practice you're part of or what tools you use. If you'd like, stay tuned at the very end where I will briefly discuss how my software tool GreenLine helps support and reinforce the Agile practices from today's episode.

All right, welcome back everyone and welcome to this third session of my Agile Attorney 101 series. Last week in episode 102, we focused on making work visible using a Kanban board, and I talked about those first two reactions that almost always happen when you do that.
First, there's the relief. Oh, finally, this makes sense now. This explains why I've been feeling so stretched, and I can finally see where all my work is inside of my system. But then pretty quickly comes that second reaction, which is basically, holy crap, that is a lot of unfinished work.

And today, I want to reframe that holy crap moment not as discouraging but as empowering. It's not a sign that you're doing something wrong. It's a sign that the system is finally telling you the truth. Now, again, that first view of work on your Kanban board is so powerful, but it's just the starting point because the point of a workflow system isn't just to see where work is, it's to get the work to flow. It's right there in the term we use, workflow.

So today, I'm going to focus on two things. Number one, how to find the most important place where work is getting stuck because it may be slow in a lot of places, but one of them is going to be more important than the others. Then number two, what actually works to get that work moving again inside of your system.

Fair warning, I'm going to cover a few important topics today, but they tie together well. So by the end, you should have a pretty clear way of interpreting what you're seeing when the work gets stuck, why it's so frustrating to you, and also what you can do about it.

Also, this is the first of at least two episodes on improving flow, and today is mostly about solving for that stuck work. Next week, we're going to talk about fixing work that flows backwards, the stuff that seemed done but had to swim back upstream to fix problems that got missed.

But let's start here. Why do we find it so frustrating when work gets stuck? And I think this is worth unpacking for a minute because the main reason we don't like work getting stuck is simple. Unfinished work represents unfulfilled promises. We humans generally like keeping our promises, and promises made but not fulfilled represent what I've been calling delivery debt.

So assuming you've got a Kanban system, basically every card on your board, every open matter represents at least one promise that has been made by your law practice but not yet kept. And really, it's a bundle of promises to clients, to colleagues, to courts, and to yourself.

Now, some amount of delivery debt is normal. Legal work takes time. The goal isn't to get it down to zero, it's to make sure that you have a manageable amount of delivery debt in your system that you can carry without too much strain. And I'll say that not all stuck work is equally problematic. Sometimes work hits what I call a natural resting place. You're waiting on a judge or an appraiser, maybe some statutory response period. That kind of waiting isn't ideal, but at least it's expected.

But the real cost accrues when work is waiting for no reason. And that's a term I love from Larry Port and Dave Maxfield's book, "The Lean Law Firm." And waiting for no reason is when you can't deliver on one promise because you're spending your finite attention on something else. If I'm going to keep with this financial analogy, it's a little bit like owing more money to creditors than you actually have in the bank. And you have to decide who gets paid now and who has to wait for that additional capital to come in.

And in that financial context, very few attorneys I know of would intentionally run their finances that way. It is hugely uncomfortable. And yet, we do it all the time with delivery debt and our attention capital. And that's a problem because just like with financial debt, delivery debt has a carrying cost. Every open matter in your system requires tracking and follow-ups. It takes context switching, reminders, status updates. The more delivery debt you're carrying, the harder it becomes to deliver on any single promise well.

And this ties back to the concept I introduced last week, thinking of your law practice as a promise-keeping machine. And when delivery debt is manageable, the promises move pretty steadily from made to kept. But when it accumulates faster than you can deliver, then the machine starts to grind.

The friction increases, your attention fragments, and instead of delivering on big promises, you're stuck making these little tiny increments of progress that never quite move the needle. It's a little bit like making those interest-only payments on your financial debt, right? They might help, but they're not really solving the big picture problem of the overall debt.

But just like when you get all of your financial debt out onto a spreadsheet and look at it in one place, when you make your work product visible or your in-progress work visible, it triggers a strong reaction. It makes those unfulfilled commitments obvious. But also like that spreadsheet, it gives you an opportunity to diagnose what's actually causing the stuck work in the first place and what to do to start to resolve it.

Now, when work gets stuck, we usually think that it's hit a bottleneck. And more specifically, I want to say that there is really only one single bottleneck in your law practice that is limiting how smoothly the practice can deliver on its matter level promises, right? The big picture stuff. And there really is. There's only one at a time, and learning how to find that one bottleneck is critical.
But before I get to that, I want to hit on two other concepts that I think we need some clarity around because without them, it's easy to misidentify and even mishandle what's going on at the bottleneck.

And the first one I want to reiterate, and I've talked about this before, that when we're talking about flow, it's easy to get fixated on flow as speed. We think that the speed at which work moves through our system is the thing we're going for. And all things being equal, speed can be great, but as I said last week, and I will definitely say again, building for speed creates risk if you haven't first built the right guardrails for your system.

So instead of going straight for speed, I strongly encourage you to build those guardrails first, and I'll even name them. On one side of the track, you want to be optimizing for consistency, the ability to deliver your work to a reasonable and reliable standard of quality.

And on the other side, I want you to think about predictability. We want to be able to reliably anticipate not only how long it will take us to build that quality product, but also how long it will take us to deliver it, taking into account our ability to get the raw materials, assemble those raw materials into a finished product, and then also how much other work is in queue or in flight in our systems at the same time that are going to impact our ability to deliver on this one.

For me, the ultimate goal with flow is getting you to that ability to make credible commitments, and you need both guardrails to do that. Consistency without predictability is going to create anxiety, right? You don't know when something is coming, even if you know it's going to be good. Predictability without consistency creates mistrust, right? You might be able to get something, but you never know how good it's going to be.

The other thing I want to do is clear up a misconception, albeit a natural one, that most people have about how to increase the flow of work through their systems. Because when we think about increasing flow, our human tendency is to turn to tools and techniques that reduce the amount of working time it takes to get a particular set of things done, to do the work on that product.

And we think that if we can speed up the working time, then we can speed up the entire process. And that instinct isn't wrong per se, but as you'll see in a minute, it doesn't help nearly as much as you might assume.

I often ask my clients to run a thought experiment, right? If your clients could see what's actually happening on their case at any moment, if they could log into a GoPro or a Ring camera, what would they actually see? And almost certainly their matter would just be sitting there waiting for something to happen. And frankly, the amount of waiting time in most law practices is kind of staggering.

Now, in the Agile world, we have a metric for this called flow efficiency. And flow efficiency is the ratio of a project or a widget's working time as compared to its total elapse time or delivery time. So here's how it works. If you've got a widget factory and it takes one full day of work, eight hours, to actually manufacture that widget, but it takes 10 days total to deliver it, that's a 10% flow efficiency.

So if the owner of that widget factory wants to deliver their product faster, they want to get more flow, they have two options. Option one, if they speed up the working time, say by 25%, that would save two hours over those 10 days. Now, that's not nothing, but two hours in 10 days is not going to be all that impactful from the customer's perspective.

But if they take option two, and they try to reduce the waiting time by 25%, and that's the time that the widget is sitting between workstations kind of waiting for its turn, that saves two and a quarter days off of the total time. And that's something the customer will definitely notice.

So while it's natural to want to focus on saving minutes or seconds off of working time through automations or outsourcing, like TextExpander is this thing that everybody loves, it's not going to move the needle that much. You're going to see way better results by reducing or eliminating waiting time, and especially that waiting for no reason time.

And just as a quick aside, in my decade plus of doing this work with legal teams, before we start doing process improvement work, the typical flow efficiency of a law practice is usually less than 1%. So that means for every one hour of work on a matter, it is usually sitting around for 99 hours or more. And this is working hours, not just 24-hour days, where it's just sitting around waiting for something to happen.

So with that context, let's go back to bottlenecks and talk about how you can better navigate them. I'm going to do a very quick recap of bottleneck theory. If you want to go deeper, I've done some full episodes on this, and I will put links to those episodes in the show notes. But at a high level, bottleneck theory is basically the workflow world's version of every chain has a weakest link. There might be lots of links that look rusty or problematic, but only one of them is going to break under pressure.

In the workflow world, I like to envision workflow stages as a series of connected pipes with different diameters, and one pipe is inevitably going to be the smallest, the place where work moves the most slowly through that part of your system. And the thing to know is that's the limiter, right? The pipe that is the smallest is the rate at which work is flowing through your system overall. It doesn't matter how good things are upstream or downstream of that narrow pipe. The narrow pipe controls the rate for your entire practice.

Now, one of the things I love about a Kanban board is that it shows you how work tends to pile up either at or just in front of a bottleneck. And so that makes your likely candidates for where your worst bottleneck is kind of obvious. In that widget factory, we wouldn't need the extra tool, right? If the paint station is your bottleneck, then you're going to see unpainted widgets stacking up in front of that station. The Kanban board basically has that same effect but for knowledge work.

So if you're looking for that place in your workflow that is the narrowest pipe, the worst bottleneck, the first place to look is the part of your Kanban board that has the most cards stacked up. There's a pretty good chance, albeit not a foolproof one, that the stage with the most cards is your workflow bottleneck.

Now, I've worked with a lot of law practices, and more often than not, I see that bottleneck happen in one of two types of workflow phases. One of them is client homework and the other is internal sort of quality assurance, internal review.

That client homework bottleneck is one that forms when you need stuff that only your client can give. Maybe that's raw materials or some other information that you need in order to do a piece of work on their matter, or it's their approval on some piece of work you've already done so that you can finalize it and move forward. And I've also done a whole episode on bottlenecks in the client homework process, and so I will put a link to that in the show notes as well.

Now, with that quality assurance or internal review bottleneck, it's a little bit trickier because that's a bottleneck that is most likely to form when your practice is already overloaded with too much work with that delivery debt. And it usually means that someone on that team, although it could be an external resource, but usually it's when someone has finished their particular part in the overall workflow and now the work is waiting on someone else, and that's often you to look it over and make sure it's of sufficient quality to move it forward into the next stage of work.

Now, I'm not saying 100% that quality review is your practice's bottleneck. I've seen it elsewhere. It could be at drafting, it could be at defining or refining the overall strategy. But for the rest of this episode, I'm going to assume that you have a quality assurance bottleneck because that's the one I see so often. And also because I think the way to manage a quality assurance bottleneck translates well to other types of bottlenecks in your practice as well.

Now, one quick caveat. Sometimes the column on your board with the most cards represents expected waiting and not a true bottleneck. Discovery in litigation is a classic example. It just takes time, and a lot of that time is mandated by the rules of procedure. So if work is getting stuck in the discovery stage or similar phases in a transactional workflow, it might be your bottleneck, but it might not be. We'd have to dig a little deeper.

One other high-level thing about bottlenecks is that I really try hard to define a bottleneck as a stage or a phase of your workflow where work is getting stuck. It's an operations thing. And that makes logical sense, but I want to acknowledge that when I start to explain this to people, one of the things I hear most often from law practice leaders or really any legal professional is, "You know what, that's all fine, but I know where the bottleneck is. It's me. I'm the bottleneck." And that might be true in a way, but I want to unpack that a little more.

And I'm not saying it isn't true, right? When people say I'm the bottleneck, what they're usually observing is accurate. A lot of work is waiting on them. It might be their review, their approval, their judgment, their experience, and ultimately kind of their law license.

But I want to draw this important distinction, which is that there's a difference between a process bottleneck and a resource constraint. The process bottleneck is what I've been talking about this whole time, right? It's the place in your workflow where work consistently slows down or piles up. It's a stage or a phase of the workflow itself.

The resource constraint happens when you don't have the available people or tools or other things necessary to do the work at that stage. That's where the waiting for no reason work tends to pile up. Technically, there's a reason, but the reason is this capacity problem.

So when you look at your work on a Kanban board and say, "I'm the bottleneck," what's almost certainly happening is that you are the resource that is presumed necessary at multiple process stages along the way. And because you can't be in two places at once, you can't do review work for someone else when your head's down drafting something of your own, you have to make a choice.

And when you're the common denominator in multiple stuck places, the system is trying to tell you something about how you're making those choices, about how your finite capacity is getting used or to put it another way, it's trying to tell you something about the choices you're making when you prioritize what work you do.

And I'll give you a few examples, right? Maybe you're not spending enough time on the highest value-add work that only you can do. Maybe that's reviewing other's work to move it forward because you're busy doing intakes or billing or your own drafting like I said.

Maybe you've got too much critical knowledge or some of the judgment trapped in your head so the work has no choice but to wait for you to come available to do it. Or maybe your quality review standards are implicit instead of explicit, so that your team members, your people don't know what good enough to pass review looks like from your perspective until you personally weigh in. And that's actually a big problem.

I sometimes half-joke with my clients, and that's inexcusable because obviously mind reading was a mandatory skill in your job descriptions, right? But I make that joke because I want to reiterate that these problems usually aren't personal failures, they're usually system design problems. And that's a good thing because improving systems is far easier than changing people.

But there's one other problem. There's this other thing that sort of creeps in a lot of law practices to hide these bigger system flaws. And that's that lawyers tend to respond to system problems with personal heroics. They wind up working longer hours, working weekends, multitasking harder, or turning to AI or other technology magic promises.

And those heroics can get you through particularly challenging times on occasion, but they do nothing to fix the underlying system. And in fact, they usually embed the flaws even deeper. What's worse, they can breed resentment when one person on the team, and often that's you, feels like they're being forced to engage in heroics because someone else wasn't pulling their weight, at least from their perspective.

But I want to reiterate this point. Personal heroics are not a sustainable solution to a system design problem. We've got to do the work. And personal heroics don't work any better for that work of process improvement.

And even just listening to this, I bet you're having ideas about how you can fix some of your team's workflow problems. And I like that you're having ideas, but I want you to avoid the urge to just jump in and do it yourself because you're going to get far better outcomes if you treat process improvement as a team sport, which means that diagnosing and resolving these system bottlenecks has to be a shared activity.

It may feel inefficient in the short term, right? You have to exert a little bit more effort upfront to coordinate your team to have those conversations, and you're probably thinking in your head, I can just do this. I know what needs to happen.

And I'm telling you, in the long term, you will pay the price. You will get far better outcomes over the mid to long term if everybody is involved in the design and the ideation around the solutions because then you don't have to train people on what they should do. They're engaged with the problem and they're bought into it from the get-go.

And the approach you take with your team matters. I can't help but paraphrase Ted Lasso here. Your process improvement efforts will work much better if you focus yourself and your team on being curious and not judgmental. So instead of saying, this bottleneck is killing us and we need to fix it, we want to try something like, what would need to be true for us to consistently get work through this stage in say three days or less? Right? Throw a goal out there.

But rather than phrasing it in the negative as an issue to be addressed and instead sort of presenting it as a problem to be solved is going to invite a lot more brainstorming and creativity. And it also will help daylight the assumptions that you and your team are almost certainly making about what needs to happen and who needs to do it.

As you're trying to do that problem solving, let me give you three high-level ideas that might help you come to better solutions. So once you and your team have identified a bottleneck and once you're approaching it together with curiosity instead of judgment, the next natural question is this: what can we actually do about it?

So I'm going to offer three sort of high-level system-oriented responses that I've seen work across a lot of different legal contexts. And I'm framing these as levers, not steps or rules. You don't have to pull all of them at once and you don't have to pull them in any particular order. In practice, I think the most effective teams usually end up using some combination of all three.

Lever one is to focus your limited capacity where it pays down delivery debt the fastest. So when a particular person is a constrained resource, there's a natural tendency to want to turn to delegating or outsourcing to keep other things moving while the person who's the bottleneck does that bottleneck work. And that's not wrong per se, but as most of you have probably experienced, it never works quite as well in practice as you think it will in theory.

One of those risks is what I call boomerang delegation, and that's when you delegate something early in your workflow and it flies off into the blue sky. And then as soon as you're heads down working on something else, it loops back around and smacks you in the side of the head. And that happens through all kinds of challenges with the delegation process itself.

Maybe the person lacked the context or skills to do the work or maybe you didn't delegate the decision authority along with the task. Whatever the cause, you haven't actually reduced your demand on yourself as a constrained resource, you've just delayed it and you've added a switching cost. You've also made it less predictable because you don't know when it's going to come back around and smack you.

And I want to say the place where I'm seeing this happen more and more often is when people start delegating parts of their work to AI. AI is a boomerang delegation machine. The other problem with delegation is that even if you're doing it well, it can actually hurt your overall workflow if you're delegating things in the wrong place. And it's almost always a mistake to try to speed up work in part of your system that is upstream of the bottleneck because when you do that, you're just pushing more work faster towards that same constrained resource.

And this is tricky because that work that's upstream feels necessary and delegating it might feel productive. You get lots of activity, but from a flow perspective, it will make things worse because more work queues up, the waiting time increases, the delivery debt actually grows because there's more and more pressure on that bottleneck.

So if you are going to delegate, I really encourage you to delegate things that are downstream of the bottleneck whenever possible. For stuff that's upstream of the bottleneck, you're actually better off not doing it while you work on the bottleneck, not getting someone else to do it because you need to preserve the overall flow. You want to limit the rate of arrival of work at the bottleneck as a way to get the work at the bottleneck to flow more smoothly.

So my recommendation when your time is limited, your capacity is tight, the thing you should be thinking about isn't what can I delegate, but where can I just go spend my own limited attention right now? It's okay if other things are waiting on you if they're waiting at some place that isn't the bottleneck.

Now, this isn't 100% true, but a really useful rule of thumb is that you should always prioritize work that is closest to done in the overall workflow. That's work that is already pretty close to being able to get closed and with a little bit of focused attention, you can actually get it across that finish line. And when I talk about this with my clients, I often say in a Kanban board, you should feel like the done column is magnetized. It's a strong magnet and the cards are also magnetized so that the closer it gets to done, the closer it feels that done column's pull.

And that's important because when you get something done, you're not just moving a card on the board, you're paying off a piece of that delivery debt. And once the debt is paid, all of the carrying costs that come with it, the follow-ups, the tracking, et cetera, disappear along with that debt.

You won't always be able to work this way, right? Deadlines are real and sometimes upstream work truly has to take precedence. But the more consistently you bias your constrained capacity towards finishing work instead of starting or accelerating new work, the smoother your overall workflow is going to become.

And I think when you start to look at your practice this way, delegation and automation will still have a role, but it's a supporting role. And they work better when they're aligned with your ability to deliver work at all phases, but especially those downstream high-leverage phases. You don't want to be using delegation and automation to push even more work into an already overloaded system.

The second lever is to build more capacity at the bottleneck through empowerment. And this helps you reduce how dependent the system is on any one single person in the first place. And I see this a lot in legal practices where bottlenecks persist not because the work is inherently hard, but because the organization has sort of implicitly decided that this is just how we do things, that certain stages of work belong to one person and one person only. And that's often more habit than necessity. I'm not saying it can't be necessity, but it doesn't always have to be.

And I'm going to hit on this a lot more next week, but building more capacity means defining clear quality standards for that stage of work, and then either working with people to build those standards or training and empowering people on your team to meet those standards. And maybe they won't do it with the same speed as your most experienced person or you, but if they can do it well enough to keep work moving and reduce waiting time, that's enough.

And I've seen firms dramatically reduce their overall turnaround time by simply broadening who is allowed and trusted to do certain types of review work. In one case, a firm I worked with reduced their average waiting time on document review from close to two weeks down to just a couple of days. And that's largely just by changing a shared belief about whose job it was to do that review work. And that wasn't technology magic, that's just load balancing.

The third lever is to make the work that arrives at the bottleneck easier to process. We want to improve upstream quality and consistency of the work that's arriving at the bottleneck. And this too has to do with creating clear and explicit quality standards. And really often the constrained resources aren't necessarily slow because they're inefficient, they're slow because the work they're receiving is really variable. It's got inconsistent formats, it's got unstated assumptions, sometimes missing information, right? Overall, it just has uneven quality.

And when that happens, every review becomes this bespoke problem-solving exercise. So improving upstream quality doesn't mean everything has to be perfect. In fact, the most important thing is improving consistency, which I would also phrase as reducing variability. And that starts with making expectations clearer and daylighting those unstated assumptions.

Because if you can standardize what “ready for review” actually looks like, you're going to give people something concrete to aim for when they're doing the work before it even reaches the bottleneck.

And like I've said, explicit quality standards really matter here and that is something we're going to go way deeper on in the next episode. It's also one of the most effective ways to prevent work from flowing backwards. So if it fails quality assurance and you have to send it back, that's a problem as well.

So like I said, these three levers are complementary. You can focus constrained capacity, you can load balance, and you can improve upstream quality at the same time. The best results come when teams are treating these as sort of shared design challenges and not individual performance fixes.

It's also important that bottlenecks aren't something that you strive to eliminate. In fact, as you start to reduce one bottleneck, the bottleneck in your overall practice will move. That is one of the natures of these systems.

And part of what I'm getting at here is I don't want to teach you just how to fix one bottleneck. I want to improve your and your team's capability to identify bottlenecks and then respond to them systematically. And doing that is what's going to help keep work flowing more smoothly and not get stuck in that “waiting for no reason” state inside of your practice.

So that was a lot. So let me give you a quick recap of what I've covered today. We started with that holy crap moment after making work visible and seeing how much unfinished work is sitting around in your system. And it's funny because while I was working on this episode, we actually got a user review that came in for our software product that captured it perfectly. And under the pros of this review, they talked about better understanding their workflows. But the one con was, quote, "how I felt after realizing how overcommitted we are," end quote.

Now, this was a net positive because it ultimately forced action, which is a good thing, but that holy crap moment is real. And then framed that holy crap moment as your response to seeing delivery debt, right? These promises made but not yet kept and kind of explain why so much of it feels draining. The big thing, and in fact, one of the things I really hope you take away from this episode is that the best way to improve the flow of work through your system is not by trying to speed up your working time, but by trying to eliminate waiting time.

In most practices, certainly in the early stages of process improvement, you're going to get way more bang for your buck eliminating waiting time than you are trying to speed up the actual work. And of course, the most important, really the only important place to reduce that waiting time is at that phase of your workflow that is the one single bottleneck where work is stacking up the most.

A quick note on how GreenLine supports some of the ideas that I've talked about today. One of the most useful ways we help teams deal with bottlenecks is by making stuck work easier to see and interpret. Not just something that is stuck, but why it's stuck and whether that's a problem that actually needs attention right now.

One tool we use for this is something called service level expectations or SLEs. And an SLE is a simple way of saying, when work enters this stage of our workflow, we generally expect it to move through in about this much time.

Then if a piece of work exceeds that expectation, the system flags it, not to assign blame, but to create a signal that it might need some attention. And one of the things that's especially helpful is that over time, as you use the system, GreenLine gives you data about how long work is actually taking at each stage. And that makes it way easier to adjust your expectations so they're grounded in reality instead of wishful thinking.

Now, another tool that our teams tend to rely pretty heavily on is this concept of blockers. And a blocker is this visual signal that lets you mark when work is stuck with a reason. For example, if you're waiting on a client to get back an intake questionnaire, you can apply a client homework blocker. If you're waiting on a court or an opposing party or opposing counsel, those can each have their own blockers, and each blocker can have a different color, a different icon. So you can really understand the situation at a glance.

And the practical effect of that is really important because it allows you to distinguish when work is stuck for a reason and when it's stuck for no reason. And that way, for stuff that is stuck for a reason, you and your team can safely ignore it for a while and focus your attention elsewhere. It also is set up so that if something stays blocked longer than expected, GreenLine can surface that too. So it doesn't quietly disappear into the background or fall through the cracks.

And really, the goal of all this is to free up your limited attention so you can focus on the work that is waiting for no reason, the work you can actually move forward instead of burning energy tracking everything in your head.

Now, we've got other tools that support bottleneck management as well, but I'm going to leave it there for today. If you want to get the whole run down of our features, head on over to greenline.legal and look for that Book a Demo button and we'd be happy to show you how things work.

All right, that's it for today. If you have any thoughts or questions about bottlenecks or any other topic you'd like to hear me discuss, please don't hesitate to reach out to me at john.grant@greenline.legal.

And if you found this episode useful, I'd really encourage you to share it with a friend or a colleague, especially anyone you know who's feeling the strain of too much work in their system, sort of getting stuck at a bottleneck, but they may need a little help getting it moving again.

To keep up with this Agile Attorney 101 series, be sure to follow this podcast in Apple or Spotify, on YouTube, whatever your favorite podcast player is. And it would help me even more if you go into one of those tools and leave me a rating or review.

As always, this podcast gets production support from the fantastic team at Digital Freedom Productions, and our theme music is “Hello” by Lunareh. Thanks for listening, and I will catch you again next week.