While many may not realize it, lawyers could learn a great deal by examining how software developers work and solve problems. A few years ago, I spent every day with outstanding lawyers while practicing at a large firm. It was a great experience that eventually led me to the world of legal technology. Now I work every day with incredibly talented software developers. Reflecting on this transition, I have come to realize that for all the differences between lawyers and developers, profound similarities exist.
But let’s start by stating the obvious: lawyers and software developers often fall on opposite ends of the technology spectrum. Some lawyers openly profess to not understanding technology, despite the fact that the American Bar Association and numerous states enacted a duty of competency surrounding the use of technology in the practice of law. By contrast, most developers love exploring new tech, eager to try out the latest apps and devices. And while lawyers typically excel in the soft skills of argument, persuasion and compromise, software developers are proficient in math and computer science – precision-based disciplines needed to build great code.
Fascinating, however, is that lawyers and software developers alike are considered knowledge workers. Both often are engaged in “non-routine problem solving that requires a combination of convergent, divergent, and creative thinking.” In short, they are paid to devise solutions, not just follow instructions.
Neither lawyers nor developers produce work in a vacuum. Rather, they focus on solving particular problems for their clients. A developer’s client could be an external paying customer or the developer’s own company. Either way, solving the problem generally involves a combination of education, experience, original research, and effort. And, that is knowledge work in a nutshell.
Watching how developers approach their clients’ problems has taught me some valuable lessons that lawyers would be wise to adopt in their own practice.
Lesson One: Plan, Then Execute
Although this may seem obvious, for many lawyers opening a new matter triggers an urgent rush to act. Whether jumping in with research assignments or document drafting, doing something feels productive. But, is that the best approach?
When starting a new software development project, writing code is among the last steps a developer completes. Before starting, good developers spend significant time planning the project, asking the client questions like:
- What is your goal? Often, the client’s goal can be accomplished in a better way that differs from what the client initially had in mind. Understanding the goal helps formulate the best course of action.
- What seems to be the best way to reach your goal and what risks might require us to change our plan? Developers look well down the road to envision the completed project to visualize both the end point and every step needed to get there. Developers frequently use kanban boards to visualize the process, a method becoming increasingly popular with lawyers, as well.
- What tools and people are needed to best execute our plan and will those resources be available? Rarely can a project be handled by one person. Ensuring the right resources are in place – people with the appropriate knowledge and skills – when needed is critical to understanding how and when a project can be delivered.
Lawyers should ask similar questions before beginning work on their next matter. The planning process doesn’t take too much time and is essential for building a path toward client success. And, in most cases it may even be billable. Clients appreciate your taking time at the outset to plan their work because doing so can help prevent costly mistakes.
Lesson Two: Automate, Don’t Repeat Common Tasks
As observed above, a key component of knowledge work is original effort. If the same task has been repeated hundreds or thousands of times with little or no variation, it no longer remains a problem that a knowledge worker need solve. The task is ripe for automation.
The image to the left illustrates the lifecycle of a task that can be automated. The first several times require significant planning, research, and effort. But over time, the task becomes more familiar, risks diminish, and the process takes less time to complete. As a process matures, the task can be automated.
Automation brings many benefits. First, it reduces the likelihood of error when completing the task. Second, it increases both quality and consistency. And third, it increases the volume of work that can be completed in the same amount of time.
Software developers are experts at identifying and building solutions that automate repetitive tasks. Once developers have done a task several times, they begin looking for ways to automate that task going forward.
Somewhat slowly, automation is taking root in legal work. Tools like document assembly, automated contract review, and technology-assisted e-discovery all are examples of how automation is making traditional, repetitive tasks faster and more reliable. Yet many lawyers still refuse to incorporate them into everyday practice, even though the firms that are leveraging these tools have a distinct advantage in attracting new clients.
Lesson Three: Ditch Blame, Embrace Process Improvement
Like many of us, lawyers want their work to be perfect. But, too many lawyers assume that if no problems cropped up, their work was in fact perfect. In reality, this rarely is the case as numerous important documents that top law firms have drafted have been rife with errors. (Read here, for example.) To lawyers, an error means that something has gone wrong, which in turn means someone’s work was not perfect. Mistakes are always blamed on people instead of on processes; and, the tendency to place blame on someone generally outstrips even the desire to solve the problem.
In the engineering world, big mistakes also happen – mistakes like, for instance, causing $135M worth of damage to a satellite…by dropping it on the floor. Or, like accidentally erasing all of the animation files for Toy Story 2 during the film’s production. While both instances involved individual mistakes, they stemmed from process failures. In the latter, a single computer command deleted Pixar’s next big film release. But, rather than lead a witch hunt for the guilty finger that pushed the button, management chose to empower the engineers to recover the film and put new processes in place to make sure this kind of accident would never happen again.
In law firms, the instinct to assign blame for errors can be powerful. And, it’s not always useful. Lawyers faced with grave errors in delivery of their services should first ask themselves what they can do to immediately fix the problem for the client and, as soon as the fire is squelched, examine the causes – causes that go well beyond who made the mistake. Was sufficient time allocated to review and check work-product before submission? Was something missed because research tools were inadequate or users were improperly trained? Were responsibilities miscommunicated? All of these questions can help formulate processes that prevent mistakes in the future.
Lesson Four: Hourly Billing Is Okay – If You Are Efficient
The debate over the billable hour is unending. Yes, it can reward inefficiency and create cost uncertainty. But here is an interesting fact: most software developers also charge for their time, in one-hour increments or by the day or week. If developers are so smart, why can’t they figure out a better way to price?
The answer goes back to the core idea of knowledge work as solving non-routine problems. When the problem and solution are familiar, the appropriate cost also is familiar. Certain types of legal work – for instance, creating an entity or filing immigration applications – can be easily packaged into a simple fee, and more and more lawyers are taking this approach for these types of matters. These tasks are also well-suited for automation, meaning the lawyer can focus on generating higher volume.
On the other hand, if you face a non-routine problem, the issues that arise are difficult to anticipate in advance. The time it takes to address those issues is likewise difficult to calculate. For a software developer, the only hedge against a problem is the charge for his or her time. On the flip side, the client’s protection is that the software developer excels at planning and has access to the best tools and people to complete the task efficiently.
The same is true for lawyers. While some tasks can be automated, many still require original effort to develop a solution for the client. Any number of things can arise to complicate that process. Charging for time makes sense. But that also means assuring your client that you have the best tools, people and processes to complete the work.
Lawyers and software developers certainly could exchange many more lessons. The key is recognizing that despite the differences between the two professions, the end goal of client satisfaction is exactly the same.