Ep #10: Make Policies Explicit

In today’s episode, I’m going to discuss the importance of establishing simple but clear policies in your law practice. And those policies are going to be the key to improving the quality and consistency of your work product and your workflow. I’ll give you two different ways to think about policies that can help you accomplish the same thing, although ultimately I think one of them is more powerful than the other. 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.

Today I’m going to dive a little deeper on two of the six core practices of the Kanban method. And remember, the Kanban method is a bigger thing than just using a Kanban board. The first of the six practices is related to the Kanban board and that is to make work visible, which I sometimes expand for my clients into make the work and the workflow visible. And I gave the basic overview for that process in episode four and I won’t revisit it here.

The next practice from the Kanban method that I want to focus on today is make policies explicit, which is another way of saying drag your assumptions out into the open where you and your team can contend with them. So what do I mean by a policy? Policies are the little rules and practices that when followed, help make sure that you and your team are actually hewing to your values, and that you’re consistently taking the steps necessary to create the value for your customer that you’ve promised to them, either explicitly or implicitly.

Which is to say that a policy is a form of quality standard, and if you haven’t listened to my last episode, episode nine on quality standards, then you’ll probably want to go back and do that at some point. I sometimes say to my clients that a policy is something of a scaffolding that protects us from our own lesser instincts, especially from the instincts of some form of future you.

What I mean by that is if you can articulate a policy when you’re reasonably well rested and clear eyed about a thing, whatever it happens to be. And if you write that policy down and formally adopt it and communicate it with your team, ideally get your help and input in crafting the policy to make sure it’s both good and workable. Then you can be confident that you have a policy in place for that time when you’re anxious or worried or otherwise working through the lens of a stress reaction, which, because you’re a human being, is something that is going to happen.

And what you want is for that policy to protect yourself and your practice and your client from that stressed out future you who might be inclined to cut a corner or make some other choice that you might later regret. Back when I was practicing law, my partner Eric and I had a nothing out the door without another set of eyeballs policy. And it wasn’t much more detailed than that, but it had this really interesting effect on how we worked.

At first, the lesser instinct we were protecting ourselves against was some flavor of I’m in a hurry or I’m already behind and I really need to get this out the door and I just want to send it. In other words, I don’t want to deal with somebody else questioning my legal arguments or worse, my word or grammar choices. But of course, we trusted and respected each other and we knew that a quality review from the other person was going to make the work product better, was going to make the client result better.

Eventually that simple policy had a deeper impact, because I knew that if it was our policy to have Eric review my work before it went out the door, I couldn’t wait to write my first draft until right before it was due. I needed to give Eric enough lead time to actually read and provide meaningful feedback on the thing, and then I needed time to digest and incorporate that feedback back into the document, which meant that this relatively simple two sets of eyeballs policy wound up defining a lot about our workflows.

It also led to some related policies, or at least some conversations about those policies. We dragged some assumptions out into the open. And sometimes they were kind of little things. For example, I am a big em dash user in my writing. And Eric is more fond of semicolons and commas. And we pretty quickly realized that there is practically no added value that could come from one of us questioning or even commenting on the other’s style choices around sentence structure. Intelligent people can differ.

And so we negotiated a truce where I wouldn’t touch the semicolons, he wouldn’t touch my em dashes and it worked great. Fortunately, we both used an Oxford comma or else our practice and our friendship would have been destroyed. I’m kidding, mostly. But I bring up that anecdote to illustrate the power of making a policy explicit. It was a rule that we both agreed to follow. We had it written down. And eventually it was one that we used with the other people in our practice as it grew. And that rule made us all better at the work.

And keep in mind this was never a detailed thing for us. We didn’t turn it into a standard operating procedure with a list of instructions. It never became some multi paragraph thing, although sometimes a good policy does need a little more flesh on the bone than our pithy two sets of eyeballs rule. What was important is that it was clear, it was achievable. And we held to it really consistently.

So going back to these developing themes that I keep repeating on this podcast around an honest reckoning with capacity and how that should lead to a brutal assessment of priorities. And how that feeling of overwhelm or what Cal Newport calls, anxious overload, if you listened to the last episode. Is really the result of letting too much work into your system relative to your capacity to deliver that work.

And the big challenge is if you’re already overwhelmed, how can you find the time or the brain space to make the changes to your system that will help you relieve that overwhelm and get work flowing again? And I already did a whole episode on close the closable and that was episode five if you want to go back and review it. But let me reframe that statement, that close the closable in the form of a policy.

And actually I’ll give you a couple of different possible policies and they aren’t mutually exclusive. As I mentioned in episode five, one of the most common places where I see a build-up of unfinished work is right at the end of the workflow where the legal work is pretty much finished. But you haven’t done the administrative work to wrap up the matter, close out the file and get it off your plate. Again, those matters have a carrying cost that is taking up more of your firm’s finite capacity than you probably recognize.

So one form of a policy to combat that tendency, to let mostly done matters pile up at the end is what’s known as a service level expectation or sometimes a service level agreement. This is something like an internal deadline. And I’m going to do a whole episode on deadlines. What I’ll say now is, I really like to reserve the word ‘deadline’ for the true deadlines. By which I mean drop dead dates that have actual meaningful consequences if you miss them. Think statute of limitations, court filing deadlines, tax deadline.

For internal deadlines, I like the term Service Level Expectation better and in the agile world we often shorten it to SLE. So a Service Level Expectation or SLE around closing out files might be something like, it is our policy to close out files within seven days of finishing the legal work, full stop. Now, we might flesh that out a little bit to define what we mean by close out files, probably include things like return all client documents, send a final bill, send a disengagement letter. And actually close the matter in our law practice management system.

But the key to that policy is the seven day SLE. Again, it’s not a true deadline. There’s nothing catastrophic that happens if you close the file in eight days or even 14 days. But it’s a scaffolding that protects ourselves from our lesser instinct to let those mostly done cases linger for far too long. And to me, that’s a policy that makes a lot of sense. It’s effectively saying, “Hey, we’re going to sweep the shop floor at the end of every shift. We’re going to make sure that things are clean and organized so that we have the space to do the next client’s work.”

And that SLE policy is a really quick and easy one to implement. But there’s another way to craft a similar policy that can accomplish the same thing but in a different way. And this is related to the theory of constraints or bottleneck theory that I talked about back in episode three and that Dave Maxfield and I touched on briefly in episode eight. And there is a whole concept from theory of constraints known as drum buffer rope, which is a funny name, and I’m not going to explain the whole thing but the buffer and the rope both come into play.

So the other way to approach this policy is to define a maximum caseload for the practice overall. And this could be for the practice as a whole, or you could do it on an individual basis and have those numbers roll up to a total. And I actually mentioned a version of this in my conversation with Dave and I have several clients who have implemented this kind of policy. But the one I talked about was Laura, a family law attorney here in the Pacific Northwest, who has given me permission to discuss her story.

So if you recall, Laura was feeling overwhelmed by the total amount of work in her practice. So we decided to see if she could, right size her caseload, really more closely match the capacity that she had. And we started by counting her total active cases, which came to a little under 50. And we then took into account that about 10 of those cases were what Laura was referring to as a red file case, matters with complex issues or complex people that took more time and effort than the norm.

And we decided to count those red file cases as two, which gave us a weighted case count in, I think, the high 60s. So, Laura and I worked out an experiment to run around capping her total caseload. And basically we asked the question, “What are all the things that would need to be true in order to get the weighted case count down to 40?” And it was a big jump. It was like a 35 to 40% reduction in her total caseload.

And on top of that, Laura also said that she wanted no more than five of those in progress matters to be the red file cases. Now, it’s been a few months since Laura started that experiment. And I have to say I am so proud of the progress she’s made. And last we talked, her weighted case count was down in the low 40s and she still had six or seven of those red file cases, which is understandable because they’re the tougher ones to wrap up.

But the effect of this change has been pretty much exactly what we were hoping for. Laura is feeling so much better about her practice, and she commented the other day, how much less stress she’s been carrying and how much more productive she feels. She said she’s still getting used to this idea that she could actually get through her entire to-do list for a day in that day. And sometimes even have time to work ahead on some of those sticky cases or not because she also can spend more time with her kids if that’s what she decides to do.

And the coolest thing and the thing that probably feels counterintuitive and even scary to a lot of you is that her firm is making exactly the same amount of money with 40 some cases as it was with nearly 70. Because most of Laura’s matters are hourly, and because there’s still more than enough work to occupy her and her team’s capacity. She hasn’t lost anything by capping her caseload, except for losing the stress of always feeling like she should be working more.

And she’s gained the sense of calm and flow in her practice. And there’s still hard work to do, but it’s not an overwhelming amount of work and that makes all the difference. So here’s where the buffer and the rope come in. Laura’s policy is to keep her total weighted case count under 40 matters. And to accomplish that over the last few months, she’s had to pump the brakes on starting new work. She wasn’t necessarily saying no to the new work, but she was saying not now or not yet.

And effectively what she’s doing is telling prospective clients that her firm is at capacity and doesn’t anticipate taking on any new matters for probably a couple of months. Now, when they heard that, some percentage of those prospective clients called the next attorney on their list. And again I can hear some of you saying, “Oh my gosh, I don’t want that to happen. I don’t want to lose this work.” And I’m telling you again, it doesn’t matter.

It means that Laura has probably missed out on the opportunity to handle those specific legal matters forever. But I want to reiterate, this did no harm whatsoever to Laura’s bottom line because she’s still making the same amount of money at 40 as she was at 70. Not only that, a decent percentage of those prospective clients have said, “You know what? I am willing to wait for a couple of months if it means I get to work with you.” And so Laura put them in queue.

And once she knows she has the capacity to start taking on new work again, then her assistant will start scheduling intake calls with those people. And that queue is the buffer. It’s a manageable backlog of potential work that Laura hasn’t yet made a commitment to. But she has the option to do work on when she actually has the capacity. And it’s an option for both Laura and the potential client and that’s okay because people haven’t stopped calling to try to get Laura to take their case. And her buffer is reasonably full.

Now, how will Laura know when she has capacity to take on new work? That’s where the rope comes in. And the metaphor is a reference to this idea that you should tie a rope from the case closed process to the valve or the door that lets new work in, your intake part of your system. For so long as the system is at or above its maximum carrying capacity as defined by the policy, then new work stays in the buffer.

But as soon as capacity opens up, in Laura’s case, as soon as she’s down to 39 total cases then she knows that she can let one new one in. If she closes two cases, she can let two new ones in. But the rope doesn’t open the intake door until enough cases have exited the system. It’s like a fancy night club. Now, another name for this type of policy is a WIP limit or a Work in Progress limit. And there are other ways to use WIP limits at a more granular level inside the different stages of your practice.

But a carrying capacity is a really good place to start, and that’s actually the third of the six practices from the Kanban method, limit Work in Progress. And so we now have six. We’ve got to make work visible, make policies explicit, and limit Work in Progress or limit WIP. And as I explained, a WIP limit really is just a kind of a policy. But it is such an important one and frankly, such a magical one when it comes to improving processes, that it gets its own call out in the method overall.

It also brings up another concept from agile and the Kanban method that you may or may not have heard of yet. And that’s the usefulness of setting up pull based systems instead of the more common push based ones. A pull based system is one that pulls work in, maybe using that metaphorical rope, only when the system has capacity to deliver on that work. A push system is the one where you keep adding new work into the system based on demand, not based on capacity. And as you’re hopefully figuring out by now, a push based system is a recipe for overwhelm and gridlock.

Let me wrap this up by pointing out how this capacity limit policy, this WIP limit at a firm level, actually accomplishes the same thing as the Service Level Expectation policy I detailed a few minutes ago. Both of them work to encourage you and your team to close cases that are ready to be closed. But the WIP limit actually gets you to put a little more skin in the game in a good way in the form of not letting you do the thing that your brain kind of wants to do, which is start work on new matters until the old ones are closed.

Like I said, there are a lot of other benefits of WIP limits that I’m going to explore in a future episode, probably in a couple or three weeks, but I’ll leave it there for now. The thing I hope you’ll take away from this episode is that any policy is better than no policy. If you implement some policy, but it doesn’t accomplish what you’re hoping for, you can update the policy, try to get it working better. As I said about my experience with Laura, we considered this capacity limit policy to be an experiment. It was a test, and it just happens to be that it’s a test that is working out really well for Laura and her team.

But if you don’t have a policy at all, then it’s really hard to develop any sort of consistency around how and when you deliver your work. And again, go back to last week’s episode and you can find the graphic on my website around how defining quality actually leads to consistency and efficiency. Now, not quite as bad as having no policy, but still not great is when you have an unspoken policy. Something you’re holding in your head as a notion around how you feel like you or your team should be working but you haven’t really committed to it by writing it down and sharing it.

And those unspoken policies can be especially problematic when someone else on your team doesn’t follow your policy, and then you get frustrated by it. But also, it’s completely understandable that they didn’t follow your policy because they can’t read your mind. And so those unspoken policies, those things that you’re carrying around, those are great policies to write down and begin the process of communicating with your team.

Okay, going back to last week’s episode, episode nine, a policy is a form of quality standard. If you want standardized work, you need to commit to a standard. And then communicate that standard and your team has to agree to the standard in order for it to actually work. So here’s your homework. Write down at least one new policy. Maybe you’re inspired by Laura’s story to commit to a capacity limit. Maybe you’re not ready for it yet, but if you are, write it down and make a plan for achieving it.

Maybe you’ve got some of those unspoken policies floating around in your head. Write them down, bounce them around with your team. Or maybe you like the idea of a Service Level Expectation, an SLE like I talked about in the middle of the show. I encourage you to try that policy too, but one word of caution. Don’t implement a Service Level Expectation anywhere that is upstream of your practice bottleneck, because it will just increase the amount of work that gets stuck at the bottleneck.

And that especially includes intake, if you’re overwhelmed already, you don’t want to speed up intake. In fact, it’s far more likely that you need to slow down intake than speed it up. Aside from that, I hope you’ll take this episode to heart and go out and make some policies explicit.

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 [email protected].

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.