Podcast Ep #84: Technical Debt in Law Firms: How Small Shortcuts Create Big Problems

In last week's podcast episode, I introduced the concept of delivery debt, and I explained why it can be just as dangerous for your law practice as financial debt. This week, I'm going to introduce yet another form of debt, known as technical debt, which is sometimes referred to as design debt. And this one is sneaky. It's often the root cause of delivery debt, and it's likely slowing you down in ways that you may not even realize.

If your team is still pulling up old documents, stripping out client names, manually reworking each version, you're not just wasting time, you're racking up technical debt. And that debt is dragging down your efficiency. It's creating potential quality problems, it's clogging up your capacity, and it's possibly even eroding trust in your firm.

You're listening to the Agile Attorney Podcast, powered by Agile Attorney Consulting and Greenline Legal. 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.

Hey everyone, welcome back. So, this is going to be another quick-hit episode, but I want to introduce, and I've actually been wanting to introduce this concept of technical debt for a while now.

And like I said in the top of the show, technical debt is drawn from the software industry and is kind of referred to as the thing that happens when you take shortcuts in building your systems or your processes or your workflows that feel fast in the moment but actually cost you more over time, right? It's that failure to do the ounce of prevention that creates the need for a pound of cure somewhere down the road.

Basically, it's the thing that happens when you just kind of throw something together because it's easy in the moment. It's like this duct tape process design that emphasizes quick fixes instead of clean architecture. And while those quick fixes might help you move faster in the short term, they tend to create more fragile systems, higher friction systems, and overall workflows that just bog you down over the long term.

And there's a lot of examples of technical debt in law practices, but the one that I think is the classic example is the thing that happens where instead of building a true template for a document that you use on a regular basis, where ideally you would have something that you could use in a document automation system like Gavel or Docassemble or Clio Draft.

What the firms tend to do instead, and we're all guilty of this to some extent, is you take some previous work product that you did this thing for another client, and you kind of go into that document and you delete all the things that applied to the old client and you type in the things that apply to the new client, and then you just kind of call it good and hopefully you delete all the things and you catch all the things. You don't always do that. This is one of the quality problems that gets introduced when you take this approach.

But because we're constantly rewarded and a lot of our culture and systems are built around doing this hourly work for the next client and then the next client, we're not really rewarded for taking the half an hour to an hour that it might take to actually say, "Oh, okay, I need to go into this thing and convert some of these parts of the document into variable fields and be able to sort of program that into my document automation tool."

And we've all heard or seen or maybe experienced the horror stories that come from this where you're doing a thing for a client and they call you up and they're like, "Why is XYZ name in this document? I don't know who this person is." And now it seems like maybe you're sharing information about another client with me that shouldn't be shared with me, and that makes me worried that you're going to share my information with someone that you shouldn't be sharing it with.

And it just creates all of these problems where you have to do rework on the document that was a problem. You have to sort of repair the client relationship or the reputational harm that came from it. And it just generates this kind of snowball of problems or has the potential at least to generate this snowball of problems that we would rather not see.

And while that's the classic example, there's a lot of other places where technical debt kind of sneaks in a typical law practice. If you've got process documents or checklists or other sort of standard operating procedures that are inconsistent or out of date or maybe aren't worded in a way that the people on your team are able to follow in a consistent and predictable way, that's a form of technical debt, right?

If they have to ask you or someone on your team how to do X because the process documents you have aren't clear enough or maybe worse, they don't exist at all, that's a form of technical debt or design debt.

It can show up in your client-facing materials, right? If you've got intake processes or intake forms or client homework requests that don't actually gather consistently the information that you need to do your work, or they don't communicate what's expected of the client in a way that the client is able to follow in a reliable and predictable way, that's a form of technical debt.

It could be your engagement agreement that ties you to certain ways of working or certain ways of billing. And this is especially important to consider as more and more firms are switching to flat fee or phased flat fee or other non-hourly billing models. If your engagement agreement doesn't actually support your ability to charge in that way, that's technical debt.

And then the last one, and this is a little bit of a sneakier one, is if there are processes or procedures or certain parts of the practice that can only work correctly if a single person does them, that's a form of technical debt.
One of the things that can be incredibly useful as you're building and scaling and improving a law firm is to make sure that you've got the ability to do some load balancing.

And so taking those processes and procedures or the personal knowledge that people have about how to do certain things and turning it into institutional knowledge that is shared knowledge across your team, that can be a way of reducing technical debt, of reducing your reliance on that single person, which is ultimately at risk of being a point source failure if that person leaves your firm, gets sick or injured, or any other thing happens that makes them not available to do the thing that only they can do. That's technical debt.

I think you can probably see the relationship between technical debt and delivery debt, right? Because the technical debt is causing friction in your practice that causes the delivery of each individual unit of work to be a little bit longer, a little bit more friction, maybe a little bit more handoff or back and forth, and ultimately just take longer than it should to get it through your workflow and your system.

And that's what helps build up the delivery debt that makes it so that you're not able to consistently meet all of the commitments that you and your team have made to clients, to yourselves, etc.

So how do you fix technical debt or at least pay it down? And I've talked about this in the past, but I think the first thing is to just start building up your muscle for addressing technical debt in the first place. And that means that you kind of make it a common practice to slow down and say, "Hey, there's an opportunity to turn this document into a template," or, "There's a need to better document this process or procedure," or, "There's a need to update our engagement agreement or our client materials."

Whatever it happens to be, really recognizing and then cataloging, and I love a Kanban board for this because you just kind of can start throwing cards into a backlog that lets you build up the library of things that you know you need to address. Then you need to get in the habit of actually addressing some of them on a regular basis.

And you've heard me talk before about this concept of 5% time, this idea that not only you as a law firm owner, but really everybody on your team should be reserving about 5% of their available capacity to be doing on-the-business work as opposed to in-the-business work.

And when I say on-the-business work, I actually mean these process improvement, document improvement, template improvement, software improvement, whatever it happens to be, these are the places where you're intentionally reserving that capacity in order to pay down your technical debt or your design debt.

And I should say, this is not the time for your other sort of on-the-business activities like doing biz dev and marketing or like handling your financials. You should be reserving other chunks of time for that, right? I want this 5% time to really be focused on improvement efforts for your systems, your workflows, your tools, your technology, etc.

And as I've said before, 5% doesn't sound like much, but it translates to about half a day every other week. So it is not an insignificant commitment, but it can be a really important one because by chipping away at your technical debt, you will then also start to chip away at your delivery debt and the work in your system will flow more smoothly and predictably and ultimately more quickly through the various phases of your workflow.

You'll have fewer errors, you'll have less rework, you'll have better client relationships, and ultimately, I think happier team members because you're all sort of reading from the same playbook and you've got tools and systems that are empowering you instead of frustrating you.

So, my call to action for you in this brief episode, number one, reserve a chunk of time, ideally at least a couple of hours in the next, let's say two to three weeks, where you're really going to dive in and focus on just one piece of technical debt in your practice. And again, that can be a document, it can be a policy and procedure, it can be a technology thing, whatever it is, but I want you to reserve that chunk of time and then actually use it to address a piece of technical debt.

And this is what I'm talking about when I say building up your muscles for addressing this problem. And ideally, you would do this not just for yourself, but you would empower every member of your team to do the same thing. And they may not know exactly what to do at first, and that's okay. What we want to do is start to familiarize them with the concept and get them trying to improve something, whatever it happens to be. And they really can scratch their own itch here at first. It doesn't have to be the highest and best use thing. It can be a pet peeve.

And I know I've talked in the past about bottleneck theory and pet peeves aren't necessarily your bottleneck, and that's true, but sometimes it just feels good to scratch an itch that you've got. And so I give you permission and I give your team permission to do that in the early going because it's going to get us in the habit and show us what it feels like to be able to do these little process improvement or addressing these technical debt issues.

And then in the longer term, I'm going to suggest that you, number one, really commit to that 5% time. And so, however far into the future you need to go to be able to claim that half a day every other week or maybe two hours every week, and make sure that everyone on your team has blocked off their calendar and are committing to doing this work.

And not everyone has to do it at the same time. It can be scattered throughout the week or throughout the month, however you want to do it. But I think it's important that you invest in this process improvement, addressing of design debt and technical debt so that you're building up your systems and not just continuing to sort of work on these squeaky wheel type things.

Then in conjunction with that, I'm going to recommend that you kind of put something in place, and it can be, you know, a complaint box, it can be a ticketing system, or it can be a Kanban system where when someone sees something in their day-to-day workflow that they're thinking, "Hey, I should improve this," or "Someone on the team should improve this," they actually capture that thought and capture that need for improvement, and you kind of build up something of a backlog of potential things to work on in order to address technical debt.

Then every two weeks when this 5% time rolls around, if you're all doing it together, you can sort of spend the first 10 or 15 minutes of that time looking at the backlog and prioritizing or maybe even just voting which are the things that we should address first and who are the right people to address these things? Maybe you address them as pairs or as teams.

It doesn't necessarily need to be personal work, but I think getting in the habit of keeping track of the things that need to be improved or should be improved, and then preserving your capacity so that you're addressing them on a regular basis is really, really important.

And I'm going to leave it at that for now. So if you have thoughts or questions about how technical debt might be manifesting itself in your law practice or want to talk about strategies for how to address it and start to get at some of these improvements, feel free to reach out to me. You can reach me at john.grant@agileattorney.com or all of the contact things are on my website at agileattorney.com.
​​​​​​​
As always, this podcast gets production support from the wonderful team at Digital Freedom Productions, and our theme music is “Hello” by Lunara. Thank you for listening, and I will catch you again next week.