Here’s how it came to be:
I was at ABA Techshow a few weeks ago watching Jess Birken & Charity Anastasio deliver a talk about Kanban for Lawyers, which I think is great. My goal has always been to start a movement around Agile tools for legal professionals, so I love that others are spreading the gospel. Jordan Couch was in the room, who has also been teaching Kanban a fair bit lately.
Here’s the thing: I know I taught Kanban to Jess and Jordan, and I’m pretty sure Jordan taught Charity (or maybe it was Greg McLawsen, I’m not sure).
So I was standing in the back with the amazing Aastha Madaan (also an agile attorney) and I jokingly whispered to her, “I should start a video library of other people teaching my stuff.” Her response surprised me: She jabbed her elbow into my ribs and said, loud enough for a few people to turn around, “You should start a video library of *you* teaching your stuff, you dope!”
I knew immediately she was right. Or rather, I’ve known it for a while (in part because Jess and others have been telling me too). But, as can so easily happen, I’d been blocked on actually getting it out. I have a sticky note on the wall next to my desk that asks the question, “Are you procrastinating to avoid failure?” But even that reminder isn’t always enough.
Aastha’s elbow was my tipping point, however. So for the last couple of weeks I’ve been building lessons and testing content to get ready for this initial launch.
I call it a soft launch ’cause I’m actually building the course Lean Startup style (and eventually I’ll include a lesson about what that means). As of today I’ve generated enough lessons that I’m comfortable launching as a Minimum Viable Product, and I’ve priced the course accordingly.
Anyone who enrolls now will get locked in at that price—no additional charges no matter how many lessons I add. As I add content, however, I’ll also ratchet up the price bit by bit to reflect the value of the total content in the course.
But I also want to include a special deal for those of you who have been listening and supporting and working with me this whole time, which is why I set up a special coupon where the first 30 people who enroll in the course get it for free forever! In exchange, I hope you’ll engage with the lessons and give me your feedback so that I can continue to deliver valuable content and improve upon what’s already there.
Once those 30 slots are gone (and a bunch of them got claimed from a single tweet I sent earlier today), I’m offering the next 30 slots at a discounted rate, so if that first link stops working you can click this one for the early adopter rate. After that, I’m going to let the course stand on its own for a while to make sure I’ve got the value premise right.
(Crazy as it sounds, one amazing person has told me that they want to pay the full price in order to support my work. If you’re one of those people, you go to the regular course page. Megan Zavieh I’m looking at you ?.)
Special thank yous to Aastha, Jess, Jordan, Greg, & Charity for spreading the word about Agile methods for lawyers. And also to Ernie Svenson for his advice and encouragement, and to Sam Glover, Matt Homann, Aaron Street, and the entire class of the Lawyerist TBD2 (now LabCon) conference for continuing to encourage me to draw the owl!
Finally, you may have noticed that I’ve put my office hours sessions on hold for now. Partly that was due to a crazy travel schedule through February (5 weeks in a row) and partly due to me going heads down in building out this course. I do hope to start them up again, but I’ll be on spring break with my kiddos next week so it will be at least a couple of weeks.
I’ll likely change the format too; I enjoyed the conversations I had, but demand wasn’t exactly beating down the door so I’m going to re-work a few things before it returns. You can still sign up though and you’ll be the first to know whatever format it takes.
As always, I’d love to hear from you about the course or any other topic. Please don’t hesitate to drop me a line.
Quality standards prevent mistakes.
As a standalone sentiment it seems like a no-brainier. Lawyers strive for quality: how often have you seen lawyer marketing with claims like “We provide our clients with the highest quality legal work,” or “We do quality work at an outstanding value”?
Of course we strive for quality. It’s why people hire professionals like us, and it’s what we’re trained to do (especially when it is drilled into us by our superiors).
Why, then, do lawyers keep messing up?Continue reading
Unless you’re a lone wolf, your project is going to have hand-offs.
Sorry, did I say “project?” I forgot for a moment that this is a legal blog. I meant “matter.” Or “case.” Or whatever else you call that “individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim.”1 For consistency with the rest of the business world, let’s call it a project.
Oh, and even if you’re a lone wolf you’ll have at least one hand-off (assuming you have a client). Unless you’re working on something for yourself and you plan to work it from start to finish in one sitting, every project has some transfer of work from one resource to another. And those transfers are one of the biggest reasons your projects fall behind schedule. (They are far from the only reason, which is why I’m calling this post Part 1).
The most obvious source of a hand-off is when the project (or any task within it) passes from one person to another in order to get something done. But there are many others that are a little less intuitive. Handoffs exist between attorneys and clients, attorneys and supporting professionals, attorneys and other attorneys, and even one person and that person’s future self (as when you put down one project to pick up another, and eventually have to get back to the first one).
Why are hand-offs so problematic? You probably have an intuitive sense of some reasons, but let’s dive in a little and see why they are so fraught with peril.
Okay so this might be an esoteric place to start, but it really is the simplest. There is a simple logical rule that says that for every new dependency in a project (hand-offs, by definition, involve dependencies), your chances of the overall project being late doubles. This was articulated by Agile mentor Troy Magennis at his 2015 Agile Alliance talk and echoed by Dominica DeGrandis in her excellent book Making Work Visible.
Think about it like this: For every dependency necessary to deliver a project, there are two possible outcomes for the timing of the project’s delivery: On-Time, and Late. (Theoretically you could deliver early, but when was the last time that happened?)
For a single dependency, then, there are just two options, and (for now) let’s assume each has a 50% likelihood.
What happens when you add a dependency? Well, each one has a 50% likelihood of delivering their part of the project on-time, but the likelihood of the overall project landing on-time gets cut in half. Why? Well in one possible scenario it is easy to see: if both dependencies are late the overall project will be late. But what happens if one resource is on-time while the other is late? Of course that makes the overall project late too (baring heroics from the on-time resource). Only in one of the four possible scenarios will the project deliver on-time, and that’s when both resources deliver on-time. That means the project has a 25% chance of being on-time (half of what it was with a single resource).
Add a third resource and the likelihood of delivering on-time drops to 12.5%—just 1 in 8. This starts to get a little harder to hold in your head, but the picture below illustrates the possible outcomes.
Add a fourth resource, and the chances of delivering on-time halves again (6.25%), and again, and again, until getting something out the door on-schedule starts to look pretty bleak.
Of course the model above is a simplistic one. Surely you and your team are experienced enough at what you do that you all can deliver on-time more than half the time, right? Just because you’re capable of delivering on-time, however, doesn’t mean that you will.
Three cognitive biases conspire to rob you of your on-time delivery even under the best of circumstances.
The first is the Planning Fallacy. First articulated by Nobel Laureate Daniel Kahneman and his research partner Amos Tversky Kahneman defines the bias as the “tendency to underestimate the time, costs, and risks of future actions and at the same time overestimate the benefits of the same actions.” This is true even when you’ve worked on similar tasks before, because we tend to see the successes of our past behavior as a normal part of the work but we view any shortcomings as one-off occurrences that are unlikely to recur.
That last part is known as the Optimism Bias, and it is wrapped up in our very egos. We tend to overestimate our own abilities (while simultaneously underestimating the abilities of others), and we also tend to want to present ourselves in a favorable, capable light. That’s all well and good when it comes to social signaling, but it is a handicap when it comes to estimating how long it will take you do get things done.
Let’s say we’re hip to our own lesser instincts though, and we recognize that we need to give ourselves more time than we think to get things done. Maybe you go with the conventional wisdom and double or triple your gut instinct in order to avoid delivery. Or maybe you’re even geekier and you’ve joined the “multiply by π” bandwagon. In any event you’ve left yourself plenty of cushion to make sure you don’t fall behind schedule.
Unfortunately that’s where Parkinson’s Law kicks in, the adage that “work expands so as to fill the time allotted for its completion.” Now this one doesn’t have quite the scientific backing as the others, but as a rule of thumb in the business world it is probably better known.
There are a couple of things that come into play with Parkinson’s Law. For one, when we have a long time in which to complete something, we have a tendency not to start working on it until the deadline feels imminent. When we delay starting, we delay learning—especially learning whether the assumptions we’ve made about the project length and complexity are any good. If things proceed more or less as we expected them to then the delayed start may not be a problem (more on that in a sec), but if any unknown unknowns rear their ugly head then the timeline is at risk.
The true sense of Parkinson’s Law is that we all have a tendency to stretch out the work itself. Need to do some legal research? With a longer deadline you’re more likely to dive down some rabbit holes. Drafting a contract or a brief? You might spend a little more time than necessary noodling on the TPS clause, or making one extra argument, or reading through it an extra time or two to
second-guess yourself check for errors. Expand the work too-early in the process, however, and you become susceptible to surprises in the latter part of your work that can still cause delays.
Let’s say you know all about these biases and make a good effort to prevent them; unfortunately, as I said before, they are nasty conspirators. Take the Optimism Bias: You take it fully into account and give yourself the exact right timeline. But the flip side of out optimism about ourselves is our pessimism around the capabilities of others. So you’ll tend to give your assistant, or your client, or your partner, a little extra time to do their part.
But when the task lands on their desk, then their own optimism bias kicks in. They think your deadline is way too long, so they’ll have a tendency to delay their own start, expand the work, etc. Even when you’ve done your part (say you’re resource 1 in the graphic above), it is really hard to control for the dependencies.
The third killer stems from the fact that hand-offs are rarely hand-to-hand. More often they are hand-to-inbox, or worse, hand-to-flung-over-the-fence. When a hand-off is anything but instantaneous, it inevitably becomes part of a queue—a limbo state—while it waits for the needed resource to become available.
Queues are a silent killer of productivity, especially in a profession that pays an inordinate amount of attention to metrics like utilization and then designs its incentives accordingly. Queues are a funny thing, simultaneously weighty and invisible; important yet neglected. And they have strange properties.
Take Little’s Law (a component of Queueing Theory), which teaches us that the length of time a single item will spend waiting in each part of a queue actually grows longer for every additional item that is also in queue. It is a remarkable finding backed up by empirical evidence: even the item that is next-in-line will wait longer in that penultimate state if there are lots of items lining up behind it than it would if it were the only thing in queue.
Think about all of the different queues most of us have controlling access to our attention: email, voicemail, appointments, to-do lists, productivity apps like Slack or Asana, and unproductivity apps like social media. Each of them demands our attention and queues up items for us to process. Little’s Law tells us that each of those additional items has a cost, and that’s before the additional effort needed to review and prioritize everything.
The proliferation of queues makes it hard for anyone to find a single source of truth as to what they should be working on next. Some queues simply become black holes while we spend our time and attention on other inputs, while often those inputs are actively
hijacking your attention to impose someone else’s priorities upon you.
Those queues, in Lean parlance, are pure waste. Investment without benefit, neither to the customer nor to you, the provider. From the customer’s point-of-view, they do nothing but delay the delivery of value they’re paying for. And for you, they add nothing to the bottom line while taking time and attention and resources to manage. The project itself is WIP, or work-in-progress, that dreaded state where investment has been made but can yield no returns. It is a necessary evil, but one that should be managed and minimized.
One last thing about queues: they form even if the resource you are handing work off to is your future self. Every time you finish part of a project and put it down with the intention of finishing later, it goes back into queue. Once in queue it waits, and forces the other things in queue to wait, for your attention to return. In fact, you could go back up to the graphic in section 1 of this post and insert your “future self” as any of the resources you are handing-off work to; something that even lone-wolves are prone to do.
I’ll dive deeper into solutions in future posts, but for now a few things for you to try to minimize the effects of hand-offs in your workflows:
1) Eliminate unnecessary hand-offs. If your project gets initiated by Alice, gets worked on by Ben whose work is reviewed by Alice before going back to Ben for more processing, consider whether you’re passing things back-and-forth more often than necessary. Maybe Alice can do a little more up front so that Ben can do all of his tasks at once. Or maybe she can wait for her review until Ben has finished both chunks of work. Remember, any hand-off you can eliminate doubles the likelihood that your project will be delivered on-time.
2) Make deadlines, even arbitrary or artificial ones. If the work is in your court, give yourself a timebox for completing it. If it is passing to someone over whom you have authority, set an actual deadline. Or if it is someone you can only hope to influence, give them a deadline anyway—especially if that someone is a client.
And make the deadline a little shorter than you might think is needed (but consider giving people an opportunity to ask for an extension). You want to encourage the resource to engage with the work as soon as possible, not just to get it done but to expose those unknown unknowns that so often pop up. We often think we are doing people a favor by giving them more time to work on something, but in reality we’re usually just delaying their starting it. We’d be doing them more of a favor by setting the right conditions for them to get it off their plate completely.
3) Work the project until it is done. Whenever you put the work down, it enters a queue. Not only that, when it hits the front of the queue you need to re-boot your brain around the parameters of that particular piece of work. Taking something out of your queue only to have it re-enter that same queue does nothing to improve the speed of your line. Better to power-through and move it on to completion (or the next necessary hand-off to a new resource).
Have questions about hand-offs or any other element of legal project management or team productivity? Join one of my weekly office hours sessions and I’ll do my best to talk you through it. Just fill out the form below to get notified when I’m going live.Trigger goes here
1. Google’s definition of “project.”
A few weeks ago I woke up on a Saturday to a small explosion on my Twitter feed (when you write on an arcane topic like legal operations, small explosions seem significant). Turns out Joshua Lenon from Clio was presenting at the LegalLean conference in Toronto, where he was liberally and admittedly teaching from this very blog*. His presentation is great, and you can watch it below.
Stealing back from Joshua, I really like one of the things he talks about at the end pertaining to legal process/project management and I want to try to expand on it a little.Continue reading
Legal Project Management is quite the buzzword these days. Of course the concept has been around for years, but the recent publication of the ABA’s The Power of Legal Project Management has renewed the push for lawyers to adopt the project management techniques that have been used in the business world for decades.
Here’s the problem: the project management methodology being marketed to lawyers—whether by the ABA book, an upcoming ALI CLE, or any number of consulting firms—is outdated. Not only that, it isn’t especially well-suited to the dynamic and sometimes volatile nature of legal work.Continue reading