The Times of London has published the first of six excerpts of Richard Susskind’s new book, “The End of Lawyers.” (Click here to go to the excerpt.) The book will be coming out in May 2008.
Susskind is a well-known English commentator on law and technology. I’ve previously had occasion to mention him, namely in this post. To this casual reader it seems that he’s been saying the same thing for a while now. That can make for repetitive journalism, but I don’t think he can be faulted—the trend that he writes about has been percolating for many years.
Here are a couple of paragraphs that caught my eye:
That said, I do admit, if I may give away the ending, that these articles will point to a future in which conventional legal advisers will be much less prominent in society than today and, in some walks of life, will have no visibility at all. This, I believe, is where we will be taken by two forces: by a market pull towards commoditisation and by pervasive development and uptake of information technology. Commoditisation and IT will shape and characterise 21st century legal service.
…
I will argue that the market is increasingly unlikely to tolerate expensive lawyers for tasks (guiding, advising, drafting, researching, problem-solving and more) that can equally or better be discharged, directly or indirectly, by smart systems and processes. It follows that the jobs of many traditional lawyers will be substantially eroded and often eliminated. At the same time, I foresee new law jobs emerging which may be highly rewarding, even if very different from those of today.
This time around, I imagine that even the most hard-boiled members of the legal profession will recognize that Susskind isn’t offering some utopian vision but instead is describing a phenomenon that has already changed the way many lawyers practice. The pace of that change will only accelerate.
Note that Susskind includes drafting in the functions that could be handled by smart systems. No surprise there—the technology is more than up to the task. In fact, the focus should now shift back to content. The challenge will be to ensure that the inadequate language of mainstream contract drafting doesn’t subvert the efficiencies offered by the technology.
In that regard, I expect an exciting 2008. Watch this space!
Hmm. Here’s some reasons why I don’t subscribe to that view:
1. The software just isn’t that good – it takes a lot of time and effort to draft and mark up a complicated document so that a piece of software can produce a ‘100%’ first draft (it’s easier if you set your sights lower – say 70% – but then – guess what – a human has to check it and amend it to get it to 100%. And how long have we been told that voice-recognition is on the way … ?
2. People like to do complicated deals – the last one they did plus some other angle. That takes people, not software.
3. Word processing allows everyone to say more and deals are more finely calculated (the influence of accountants?) so that more has to be said in the contract. When I began in practice 25 years ago you could do a share sale contract in 30 pages – no more. But then no-one then had to worry about pensions, European law or TUPE etc.
4. Governments pump out more and more law. Lord Justice Carnwath recently asked the House of Lords to revise their practice direction that allowed their Lordships each to give an opinion – he pointed out that when the direction was made in the 1960s, no-one had heard of European Law and a year’s legislation fitted into one bound volume. Now it’s several volumes – and shows no signs of slowing.
Nigel: I can’t speak for Susskind, but I don’t have an absolutist view of document assembly—I don’t foresee a Brave New World where all our drafting is done by machines. But I think that much drafting could, or should, be done by document assembly.
Now on to your points:
1. I suspect that you have more hands-on experience of document assembly than I do. But what I’ve seen and the glimpses I’ve been given of the imminent future indicate that the best document-assembly software is extremely versatile and is straightforward to use. The weak link in the system is now the human component, namely preparing the language that goes into the system—getting the logic down isn’t for everyone, and I suspect that that’s the source of most glitches. That’s why I’m now working closely with Business Integrity, developer of DealBuilder document assembly software—adding my expertise to the mix would ensure that DealBuilder customers are covered when it comes to both the human component and the software component.
2. It would be unrealistic to expect document assembly to allow you to produce a first draft that reflects all the terms of a complex transaction—at some point, it’s no longer economic to provide for additional permutations in a document-assembly template. But if you could produce in an hour a draft that includes 90% of what you need, you’d be much better off than you would have been had you prepared a draft by scissor-and-pasting it together from contract models. And of course addressing complexity takes people, not software—we’re talking about document assembly here, not artificial intelligence. But if you can draft a contract to reflect complexity, then you could just as readily draft a document-assembly template to replicate permutations of that complexity, subject to the economic constraints that I mentioned.
3 & 4. Sure, deal documents can be voluminous. But that’s not an argument against document assembly. If anything, it’s an argument in favor.
Note that the key to successful document assembly is high volume—if you need to create a given kind of contract dozens, or hundreds, or thousands of times (the tipping point would depend on the kind of contract involved), you’d likely be willing to make the up-front investment in time and money to automate that contract. That’s why thus far DealBuilder software has mostly been used by large law firms and by major companies to generate sales documents. But another way to achieve the necessary high volume would be to offer to a broader audience versatile document-assembly versions of widely used business contracts. That’s something I’m currently exploring.
Incidentally, I think that an underappreciated feature of document assembly is its training function. You can annotate a document-assembly questionnaire to provide guidance regarding the factors that come into play in selecting among any given set of options. That sort of on-the-spot guidance is vastly more valuable than the same guidance doled out in a conference room or webcast, divorced from context.
Anyhow, I’m sure I’ll have occasion to revisit all these issues.