Podcast Ep #62: Delegation Pitfalls: When Legal Work Goes Too Deep or Too Wide

When delegating work inside of a law practice, there's a constant challenge around calibration. You might get back something that only bounces over the surface of what you needed. You might get a great answer to the wrong question, or you might get something that is so overworked that the original need is buried beneath unnecessary extras. In today's episode, I'm answering a listener question around managing these extremes. What to do when you've got a true lawyer's lawyer who likes to dive deep down every little rabbit hole, and what to do about the more junior team member who has no real context for understanding which is the right path to take.

I'm excited because I get to draw from my experience in my very first big legal ops consulting gig. And I'm gonna share some very specific techniques, including an important concept that I've never talked about on this podcast before, that I think can help you avoid all three of those undesirable situations and help make sure you get delegated work back in a way that truly meets your and your clients' needs.

You're listening to The Agile Attorney Podcast, powered by Agile Attorney Consulting. I'm John Grant, and I 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 to The Agile Attorney Podcast. I am going to bring you a listener question this week. It's actually one I've been sitting on for a few weeks because I wasn't sure where to work it in. But in light of the last few weeks’ episodes around AI and around legal workflows, I think this one is pretty timely.

It comes from someone who is a senior associate in a decent-sized firm, I think about a 10-attorney firm, best as I can tell. And the context is speeding up legal workflows, right? My topic from last week's podcast. And they ask this, how do I deal with a team member who is a senior lawyer, but he's a real lawyer's lawyer? And every time I send him something, he wants to go deep on everything. On the other side of the coin, how do I deal with brand new lawyers when I give them assignments and they tend to go on and on and on with their work because they don't know when to stop?

Now this is an interesting one for me, partly because it reminds me of an experience I had in my very first legal ops consulting gig. And I had this funny thing where my business partner and I, when we first started trying to do some legal operations work, the very first client we landed was a whale. It was the in-house legal department for a Fortune 50 company, one of the biggest brands in the world. And it turned out they had put out to bid some analysis work and got responses back from some of the big four accounting firms that were kind of stupid expensive. And at the time, at least, those firms didn't have a lot of experience in legal operations. In fact, the whole discipline was relatively new. This is over a decade ago now. I think they have a lot more going on now.

One of the things that I did as part of that engagement is interview a wide swath of the in-house attorneys at this company in order to gauge what their feelings were about their relationships with outside counsel. And they came up with some really consistent answers. They complained that, I like my outside counsel but they don't really understand our business very well. They can never tell me how long something's going to take or how much it's going to cost. They have a tendency to overwork the problem and wind up making it more complicated than it actually needs to be. And they don't give me deliverables in a format I can use. And those five things came up over and over and over again in the conversations that I had.

I then made what I now recognize was a grave political error, which is I thought that because we had gotten such interesting insight around these questions about the in-house lawyers' relationship with their outside counsel, what would it be like to go talk to business leaders inside of this company and ask them what they thought about their in-house counsel? And guess what I learned? They don't really understand our business very well. They can never tell me how long something is going to take or how much it's going to cost. They overwork the problem and wind up making it more complicated than it should be, and they don't give me deliverables in a format I can use. It was the exact same set of answers.

My friend Casey Flaherty actually blogged about this story many years ago on the 3 Geeks in a Law Blog blog, and he used it to make the point that lawyers are often working towards a different set of values than the clients actually have when they're asking the lawyer for legal work. And this disconnect between what the lawyer values and what the client's actually looking for is in Casey's summation, the root cause of a huge part of the problem in the legal delivery industry in general. And I'll provide a link to that blog post in the show notes. It actually even got picked up by a few other blogs. It was a very popular one at the time.

But the reason it comes to mind, right, in the question that I got this notion of the lawyer's lawyer, right? And I think we all know that person. It's someone who really loves the deep research, the issue spotting, the untangling of all of the various elements and taking the thing and looking at it from lots of different angles. And on the one hand, I respect the hell out of those people. I love to be there sometimes myself. It's fun, it's engaging. It is kind of what we went to law school to do. It's like we are out there, you know, on the open highway, just free to do our craft. And again, I get it.

But of course, we're not on the open highway, right? We're on the client's nickel or we're working with other members inside of our firm, and we can't just do work in this open-ended way without running into some frustrations or some problems in the way that we interact with the other constituents in this thing.

And I think I come back around to really agreeing with Casey's synopsis, which is, you know, when you have these lawyers that put a lot of value in the art and skill of lawyering, then that's what they're going to do. Right? And certainly absent other information, that's going to be the default place where they want to operate and the way they want to do their work.

But I think the reason that this senior colleague is annoying the listener who wrote in with the question is related to some of those things that I discovered in my long ago consulting gig, right? This attorney is trying to deliver the work on a certain timeline.

I think the context is that even though this is a senior associate, they actually have a lot of interaction with the client. And when they put the work out to this colleague of theirs, even though it's a more senior colleague, they're in this place where they don't understand the need of the client, they're taking too long to deliver something, which is also driving up the cost. They're overworking the problem and making it more complicated than it might actually need to be.

And then I don't know whether, you know, the deliverable in a format I can use is an issue here or not, but certainly if there is a more voluminous answer than is actually needed to solve the client problem, then it probably isn't a format that you can use. At the very least, you got to edit it down and make sense of it from a client standpoint.

So what can this senior associate do in order to get more focused work, more timely work, and ultimately a better deliverable out of this colleague of theirs who, again, the lawyer's lawyer, I want to have those people on staff. I'm again, I'm not knocking them, but they're not always the right tool for the job unless you can actually calibrate them around the needs of this particular project. And so that's where I think the opportunity lies.

So my first suggestion would just to be really intentional about engaging that senior colleague, right? And really whenever you're delegating legal work, engage the person you're delegating to with the why, right? What does the client need from this? What is the purpose of this project? The purpose of this task set? So that hopefully we actually get them in the right mindset to deliver to that purpose.

I've talked in the past about fitness for purpose, the concept of work that is fit for purpose, and that's what we're looking for, right? Not too much, not too little. We want that Goldilocks zone of just right. I've also talked about the power of leading with purpose back, I think, in episode 22, where I talked about how to write effective law firm policies and that a law firm policy should always lead with a purpose statement, right? Why do we have this policy? Engaging people around the why is one of the most powerful things you can do to try to keep things in scope and to try to deliver work that is fit for purpose.

I also think how you deliver the why statement, right, how you communicate makes a difference. And the temptation is always going to be to use email or, you know, if you're using Slack or Teams or one of those other internal communication tools. Or frankly, even if you're using a Kanban system and you're communicating through the Kanban card, which is my preferred method, that's still that non-real-time, sort of time-shifted communication isn't ideal because it's not really a conversation, right? It's a series of statements back and forth.

So with some people it can work fine, but I think in order to begin to improve the relationship with your delegee and to really sort of try to do that mind meld around what are we trying to accomplish here, I really strongly recommend that you turn it into a conversation. And that should be an in-person conversation, if you can swing it, maybe a video call, if that's your next best option, and a phone call being sort of the third way of doing it.

But I would try to make sure that you can actually converse over it and engage in some back and forth, some question and answer, some challenging of assumptions, right? Maybe they think of something that you didn't have quite right. So it's useful for both of you to really spend the five or 10 minutes that it takes to get to the bottom of what are we looking for here? What is the client need? How is this helping us advance the matter? Whatever it needs to be, but getting to that why so that regardless of what the rest of the instructions are around the deliverable, we're making it more likely that it's going to be delivered in a way that is fit for the purpose of the task set or the project.

The other thing sort of out of the Agile tool set that you could do if you're gonna be having that conversation is to agree on what is the definition of done for this task? What are the acceptance criteria? What are the key things that need to be present or at the very least accounted for in order for this thing to be of sufficient quality. There too, you know, your instinct might be to make that an email or a chat message, whatever.

I think that it's going to be better if it is at least starting with a conversation, although I also, you know, I'm a lawyer, I get the idea of papering the trail. I think memorializing it in a written communication or inside of the Kanban card can be useful too. But whatever it is, establishing again at that high level, what are the things that we want this deliverable to have so that we can achieve the client outcome or meet the client need.

So those two sets of tools are sort of related to each other. They're what I might loosely think of as scoping the work or scoping the project. Really important. I think the other thing that can be really helpful is a technique that I've also talked about before, which is time boxing.

And there's actually a concept from the world of project management that I meant to talk about last week and didn't actually get to. So I'll give it to you a little bit here. It's known as the Iron Triangle of Project Management, and it basically goes like this. In order to achieve a quality outcome, there are three components of any project. There is the time it takes to deliver the project, there are the resources available to do the work on the project, and then there's the scope of the project itself.

And so if you think of those as the three corners of the triangle, time, resources, and scope, and then quality is in the middle. And the reason it's an iron triangle is that if you want to change one of the things, one of the corners of that triangle, then at least one of the other points also has to change.

So if you have a scope of work that you're trying to deliver to a certain quality and you want to deliver it faster, then you generally are gonna need more resources on the team that's doing the work, right? You need the people available to speed the thing up. Or if the goal really is speed, then you actually have two options. You can either, again, increase the resources available on the project or reduce the scope. And if you reduce the scope, then you're likely to deliver the project faster.

And one of the big differences between traditional project management and Agile project management is that traditional project management is usually built around this notion of a fixed scope.

Right, we've defined all the things that need to be in this project or in this deliverable. And that means it's going to take as long as it takes to actually deliver those things, unless we add more people to the team. And even that, as you probably can recognize, adding resources to the team doesn't always help, right? That's not always the best option. And so oftentimes time and scope are the things that are most likely to float one direction or another when you're trying to change things around a project.

So again, when you're talking about traditional project management, where you're delivering to a fixed scope, then oftentimes one of two things floats, either it takes longer and longer, which I'm sure is something you've all encountered. Or the other option, right, and this isn't the good option, but it's the one that happens a lot in reality, is that quality suffers.

All right, I'm gonna take a quick break. When we come back, I'm gonna teach you how the Agile approach flips this concept on its head, focusing on time rather than scope to create powerful feedback loops. Back in a minute.

So you're delivering to the scope within the time period with fixed resources, so those are the three corners of the triangle. But if you try to fix all three of those things, then the only thing that's left to change is quality. And that's not always a good thing.

What's interesting about the Agile approach, I mean, I obviously find a lot of things interesting about the Agile approach. I call myself the Agile Attorney. But one of the things that is interesting about the Agile approach is that we don't worry ourselves nearly as much about scope and instead we really try to focus on time.

And partly this is going to the Scrum methodology of Agile, which isn't the only one. It's not even the one that I use the most, but the thing about Scrum is that it's really intentional that we are going to deliver something every sprint. And a sprint might take a week, it might take two weeks, but whatever it is, we're basically saying, okay, we've got this team of people, the resources is fixed. We've got this time frame, the time frame is fixed.

And so we're going to deliver as much scope as we can, but we're not going to concern ourselves with falling short on scope. We just are going to deliver what we have. And the reason why we do that is because it generates a feedback loop. And I've talked a lot about feedback loops on this podcast before, too. But the great thing about a feedback loop is that it generates learning.

And so coming back to this question about how can I prevent this associate who likes to overwork a problem from overworking my problem, the answer is give them a time box. And as I talked about last week, that time box might actually have two components.

Number one is tell them you need something within the next three days, right? And you don't care what it is. It could just even be an outline, but you want to make sure that there's something that they can turn around for you that you can evaluate. And then maybe together you can determine whether you think that this thing is on the right track as far as meeting the client's need or meeting the needs of the deliverable.

The other form of a time box, and these aren't mutually exclusive, is to give them a working time, right? So tell them, hey, get as far as you can get in an hour and then show me what you got. Again, because it generates a feedback loop, it generates an opportunity for learning, an opportunity for conversation, so that when you then pick up, or when the colleague then picks up to do the next time boxes worth of work, they have gotten better information, or the two of you are at least more on the same page as far as what the deliverable needs to be and whether we're building on the right track.

The other reason time boxes can be great is that if someone is going down the wrong rabbit hole, but you've put a time box on it of an hour or a couple of hours, and you get that feedback back, and you're like, oh, no, I'm sorry, you misunderstood what I was looking for here or what the client's looking for here. You've only lost that hour or that couple of hours, and obviously the bigger a chunk of time you give somebody, the more you're putting at risk.

But at the end of the day, writing off an hour, assuming you're billing hourly, or writing off an hour if you're working under a flat fee or a contingency or one of the alternative fee structures that I propose, it's not that big a deal if you've learned. But if the lawyer's lawyer is given time to really noodle and really take a lot of rope and go down these different pathways, then the amount of time that you have to write off is going to be a lot higher.

And at that point, especially if you're still working under an hourly comp model, which most of you probably are, and I'll do a whole episode about why that's a terrible idea later. But if you're working under an hourly comp model, then obviously there's going to be hard feelings if you have to write off that time, again, depending on sort of what your policies are as far as crediting that time, whether you actually bill it or not.

So just a quick rehash of this first scenario, right? Dealing with the lawyer's lawyer, dealing with the person who wants to really go deep and maybe their natural instinct is to overwork a problem.

Number one, make sure they're really connected with what it is we're trying to accomplish with the work. Number two, come up with some clear guidelines around what done looks like or what the elements of completion or success look like. Another word for it in Agile that I haven't used yet is acceptance criteria. It's all roughly the same thing, but making sure we know how we're going to be able to identify that the deliverable is in fact fit for purpose. So we want to know what the purpose is and then how we're going to know whether or not it's fit for purpose.

And then the other half of the equation is making sure that we're really clear about our turnaround time, our feedback loops, using short turnaround times to generate feedback loops so that we can learn, so that we can make sure that things are on track, make sure we don't go too far down a path that isn't actually the one we want to be going down.

And so flipping over to the other half of the question, right, what happens when I've got a brand new lawyer who really just tends to go down these weird rabbit holes because they don't have the context or the experience around how to do this work, as you probably can guess, I think the recommendation is about the same. The context or the dynamic of it might be a little different, right?

When you're working with a senior lawyer, a lawyer's lawyer, you're gonna be working more as colleagues or in some situations, you might even be managing up a little bit, they may be more senior in your office, in your practice, it might even be your boss. And so, the conversation is a little bit more delicate or you might have to be a little bit more savvy about how you engage in those conversations. But I still think most people, most of the time, are going to be willing to have those conversations.

When it's a junior person, a brand new lawyer, a brand new, you know, and not just lawyers, right? Could be paralegals, it could be assistants, all the same stuff applies. We're using that context setting again in a conversational way as a teaching tool, as a way to train that new person on how to be better at their profession. And I think you'll find that most newer professionals are thirsty for that kind of context, right? They really want to know, they know they don't have the big picture, they want to get it. And the time that you take to have those conversations, invest in them, but also, you're investing in solving the client's problem.

It is not admin time. It's not overhead. It is an investment in achieving the outcome for the client. Again, I'll debate whether or not it's all totally billable back to the client. If you're in the weird world that is hourly billing, I stay out of that rabbit hole myself, but either way you should be having that conversation. The ounce of prevention, even if you are billing for it, or, you know, if you're in an hourly billing metric and you write it off, that ounce of prevention is going to save you the pound of cure of having to either write off a bunch of time, redo a lot of the work yourself, or delivering something to the client that isn't actually solving their problem. Which, again, we hope you don't do, but my experience in the consulting is that it happens all the time.

The other thing with respect to new team member training is that if this is a kind of deliverable that you like request on a regular basis, then it can be helpful to have that conversation. Think about how that conversation went, document the outcome of that conversation, obviously for this specific use, right? This specific task set, but then also capture it as a policy or as a standard operating procedure and start to use it to build up a knowledge base or a library of information that people can refer back to and that maybe you can use as a shortcut the next time you have to explain something like this to a different new associate or new person or maybe use it as a template for having a conversation about a different kind of legal work.

But the more you can sort of take this implicit knowledge that you carry in your head around how to do things and turn it into explicit knowledge that is systematic, it's durable, it is part of the organization and the culture of the firm, of the system, then the better these conversations are going to go over time.

The last thing I'll hit on with respect to this question is a caution to just sort of look in the mirror and make sure that maybe you're not sometimes guilty of some of the things that you're complaining about from your colleagues, right?

So as we go to do our own piece of work, do I understand the why? Do I understand the purpose behind it? Do I have a good sense of what my quality standard is, my definition of done, my acceptance criteria? Anything you can get to, to be able to say, okay, do I actually understand the client's business or the client's needs here? What am I going to put in place to make sure I'm not the one overworking a problem? How can I be more predictable in terms of how long something is going to take or how much it's going to cost?

And then I think the one that really is more important than the rest of them for me, how do I deliver my work product in a format that the client can actually use and understand?

So just to recap, right, whether you're managing up, managing down, or managing yourself, these are sort of the bullet points that I want you to take away from this episode. Number one, focus on the why, make sure you understand what the purpose behind the matter, the task set, the project, whatever it happens to be is, and that you've really are comfortable that you understand it in a way that is gonna resonate for the client or for whoever the customer of the work is.

Number two is to define the deliverable through the lens of fitness for purpose, right? How am I going to deliver work that is going to be useful to the client, help the client achieve their desired outcome or their goals, and how can I do it without under-building it and sacrificing quality or over-building it and running up the cost?

Number three, use time boxes as a way of generating feedback loops. And again, that's both total elapsed time and also working time. You wanna make sure that we're on the right track and that there is the right check-in with the right person. And again, that could be the person you've delegated work to checking back in with you. That could be you checking in with the client or whoever the customer is for the work that you're doing.

So getting those feedback loops and using sort of a minimum viable product approach, right? Maybe you do a feedback loop on the outline before you hang a lot of effort onto fleshing it out. Maybe you get a feedback loop on the first part of the deliverable or the argument to make sure that it looks like you're headed down the right path. Whatever it is, you know, if you wait until you have to deliver a full draft of the whole thing before you get feedback, you run the risk of going too far down the wrong path and then having to do rework and all the other things that I've talked about before as adding to delay.

All right, that's it for this week. As always, if you found this episode useful, please forward it to a colleague or a coworker, or if you wanna shout about it on LinkedIn, I would certainly not be against that either.

If you have any questions that you would like answered about legal operations, process improvement, project management, business model change, adaptive strategies, all the stuff that I work on, please don't hesitate to reach out to me. You can reach me at john.grant@agileattorney.com. You can also come in and ask it in the free Agile Attorney Lite community, which you will find at community.agileattorney.com.

This is new, we're just getting ramped up, but I would love to see you in there. As always, this podcast gets production support from the fantastic team at Digital Freedom Productions and our theme music is Hello by Lunara. Thanks for listening and I will catch you next week.