The famed venture capital firm, Andreessen Horowitz, is well known for its mantra “software is eating the World.” They are right. I’ve spent a great deal of time studying computational law; the similarities between coding and drafting legal contracts; and the impact that blockchain technology will have on the legal industry — especially in the context of smart contracts. My perspective on these issues is slightly different from those in academics or technology companies that market products and services to law firms. I practice transactional finance law as a partner at an AmLaw 100 firm. I’ve practiced in this area for over 18 years, so I’ve seen my fair share of transition in the profession. My suspicion, however, is that the evolution of the legal profession over the next 5 to 10 years is likely to dwarf the last 18 (or 100 for that matter). In fact, to call it an evolution is probably misleading —utter disruption is probably a much better description of what is to come.
In a previous article, I discussed the relationship between software engineering and contract drafting. In short, contracts and even the law itself represent the logic that governs the relationship of two or more people. Whether the relationship consists of a buyer and seller of an office building, a debtor and creditor or a major financial institution and its regulator, those relationships can all be distilled into a series of if/then and other logic operations. Any reader who has even a basic understanding of computer programming will immediately see the similarities between these relationships and coding. Even the notion that law is more art than science has been severally challenged —the area of study known as “law and economics” shows us that law is rooted more in math and game theory than divine instructions from a higher power (this holds true even in areas such as gay marriage and other ‘social’ issues). I am certainly not the first commentator to notice this relationship. Until today, however, the above has rarely made it past theoretical discussions, or if implemented into a commercial product, it failed to live up to its promise of revolutionizing the practice of law.
In my opinion, the failure of the profession to adopt what I will call, for purposes of this article, an “engineering” approach, is the result of several factors. Of all these factors, three reasons stand out in my experience. The first is a misalignment of incentives created by the traditional method of law firm billing — the billable hour. An engineering approach requires a firm to make a capital investment that will ultimately allow it to perform client services better and faster. While for most businesses this constant refinement of business practices focuses on capturing these efficiencies. Apple for example strives the be able to produce a better iPhone at a lower cost of inputs. A law firm, however, loses revenue if it utilizes the same process. If a given task now takes one-half the time as before, then the billings for that task will be one-half. In other words, inefficiency can often lead to greater profits. From a purely microeconomic standpoint, markets should be able to account for the efficiency and allow the firm to adjust upward its billable hour rate versus its competitors. Unfortunately, the reality of how legal services are bought and sold, especially in corporate America, simply fails to reflect this adjustment.
Historically, commercial products offered to law firms, while well intentioned, and in some cases, advancing the ball, still fell short. I can’t help believe that part of this failure is the result of a disconnect between those designing the products and those using it. By analogy, it’s hard for a military contractor to design future weapons for our troops when the designers have never been in combat. No amount of focus groups or meetings with military commanders can replace the insight of a marine pinned down under heavy fire. Only that marine has an intimate knowledge of how he wants every device at his disposal to work and which devices he desperately wished he had under the circumstances — its his or her life on the line. One point of clarification — the military example highlights the issue of matching products to needs, and in no way implies that the struggles of lawyer are in any way similar to the intensity of a marine’s life in combat. I’ve not once feared for my life while staring at my shiny 28" monitors. What the development cycle needed was practicing lawyers to develop and design the software tool they needed and wanted.
While this article and my previous writings may leave one with the impression that it is easy to convert law to code — it’s not. It’s actually a fairly difficult and time consuming process. Over the last two to three years, however, two things have made significant advancements. The first is that the technology has become much more advanced — AI (especially machine learning) and blockchain technology are just two examples. In addition, the ability to leverage these technologies in a full stack application can now be accomplished by non-professional engineers. Even I can spin up a full stack web application over a weekend — which is what I did when I realized we could do a better job tracking what we call “post-closing” items after a transaction had closed.
All three of the impediments identified above are rapidly eroding. The proliferation of alternative billing arrangements — including flat fees for well defined tasks — have helped eliminate or at least reduce distortions in incentives. Today, there are more lawyers who are proficient coders than ever. I now spend at least one to two hours a day on average coding the legal relationships arising out of contracts and regulations into software that automates many of the tasks lawyers had to previously spent many more hours to address or document. For example, if a financial institution needs a process to verify Regulation B compliance for lending transactions, then rather than have a lawyer spend two to three hours of time analyzing the issue, the facts of the loan can be fed into a software module that I coded which includes all of the logic of Regulation B. The process takes about ten minutes of client time and does not require the involvement of a lawyer. Furthermore, the technology that exists today is exponentially more powerful than that which existed just three to five years ago. Yet the ability to use these technologies has become much easier. You no longer need a computer science degree from Stanford to utilize this technology — amateur and hobbyists can now tinker with deep learning technologies. I’m not the only one, there are hundreds, maybe thousands, of us coding lawyers in existence today.
So where does this leave us? Consider this proposition: One of the reasons that clients hire AmLaw 100 firms is that they tend to have a disproportionate number of lawyers who are VERY good at applying the logic of the law to an almost limitless number of real World situations — with a keen ability to distinguish unique aspects found in one transaction versus a prior transaction. In addition to this valuable skill, the most sought after lawyers are also able to manage the workflow of a transaction or other process (e.g., a regulatory investigation) in an almost robotic manner. Large law firms are a collection of these highly productive lawyers, which means as a group, there is an enormous amount of knowledge about the logical relationships described above. So, I will end with this question. If a well respected law firm with thought leaders in their respective practice areas are able to convert and organize this sought after knowledge and project management skills into software (imagine a collection of SaaS options) that clients can leverage for better results in their businesses, will corporate America purchase it? What if it reduced their outside legal expenses by 50%?
