lawyers don't get it

Not a Brain in a Vat

I’m not a brain in a vat. At least I don’t think so. (Lame attempt at humor there, I know.) Well, assuming that I am embodied for real, then equally “for real” are all the file folders, unfiled documents, notes that I’ve taken, treatises, deal books and loose-leaf reporters spread around my office. What I’ve found, the longer I’m in this game, is that the unavoidably physical task of assembling contract precedents for review, the very act of having to jump up from my desk countless times during the day to get my hands on a document or a volume is plain annoying, “wearying” is perhaps the best way to describe it all.
I’m in pretty good health, exercise regularly, don’t smoke and enjoy long walks in NYC – so it’s not a physical disability, thank God, that makes all this scrambling around painful. And, despite my affinity for tech, I do agree with those who say that there’s little yet on the tech front that can outdo good lighting and words printed on white paper to make the reading experience enjoyable. Also, it’s not the disorderliness of my office that’s the source of pain here; those items mentioned above as being spread around my office are far from being scattered randomly over desk and floor.

I guess what I’m saying here is that, as a senior lawyer -- but one who’s still very much involved in the hands-on practice of law (I do a great deal of “first draft” drafting, always at the computer mind you, and I review and comment on a lot of other lawyers’ work) – what I really want to do is just think and get paid for doing so. (I’m putting telephoning and negotiating at the bargaining table aside. They’re a big part of my day, too; but I’m more often than not at my desk drafting or reading). In asking whether document storage, sorting and retrieval systems can alleviate the “scrambling” around that I find so painful – and I mean with respect to ALL kinds of documented materials, not just files stored in the firm’s document management system – am I posing a question that goes to the “intelligent” application of information technology to law or am I just day-dreaming of a George Jetson kind of practice?

In answering my own question, let me ask you to consider how much more efficient I could be if those relevant drafting precedents could be found with a few mouse clicks, if the files from the deal under review didn’t have to be hauled from file room or even from my office floor to my desktop, if the regulations contained in the loose leaf service could appear on my wide screen flat-panel monitor in a column adjacent to the very document that I’m drafting or have under review. We’ve come a long way since the mid-70’s when I started to practice and it’s a far cry from the days of “White-out” (sp?) and cut-and-paste document assembly, so perhaps it’s plain old laziness that has me write my post today. No, I insist that the rallying cry should be “automate all but the thinking” (but see a previous post on artificial intelligence). Eliminate every bit of the drudgery and time-waste with intelligent machines and software use, and let me do what I really want to get paid to do – think, analyze, advise.

R&D

I made the mistake earlier today of searching “law and ai” on Google. Instead of getting hits of law and artificial intelligence sites, I mostly got hits that referred to sites discussing Jude Law’s role in the Steven Spielberg moving, AI. Well, my search string wasn’t that well-formed because, after modifying the search to read “law and artificial intelligence,” I got a number of hits relevant to my intended topic – hits that included sites dealing with academic conferences on the subject, as well as even a journal, published by Kluwer, devoted to artificial intelligence and the law.

But what I couldn’t find, not surprisingly, was any reference to a law firm’s role in artificial intelligence as applied to the law. Now, AI, after the over-blown promises of its earliest enthusiasts in the mid-50’s, has by and large proved to be a disappointment when it comes to its role in fields like the law (in fact, when it comes to its role in most fields of any kind whatsoever). Sure, there are aspects of legal knowledge that the expert systems of today can manage, and there are patterns common to rather standards sets of facts or to bodies of case law that neural networks could probably be trained to recognize. But to really get a hold in the law, much general artificial intelligence research remains to be carried out and, more importantly, research into AI’s specific application to the law must be carried out as well. Which leads me to my question: Why don’t the largest US law firms have R&D departments devoted, if not to exotica like AI, then to the development of other, lesser challenges such as the better automation of so many of the routine processes that lawyers, senior and junior alike, must content with still.

Law firm R&D? Preposterous you say! Law firms are in the business of practicing law, not carrying out blue-sky activities like research and development. But isn’t it really all a matter of return on investment and should that R&D come up with cost-saving, quality-bettering process improvements; well, who’s to say the return won’t warrant the investment. Our English cousins appear to have stolen a march on us here State-side when it comes to the sort of investment in R&D that I speak of here. And look at the budgets for R&D that the large consulting and accounting firms have.

But, if there’s one theme that will persist in this blog, it’s that an enterprising, far-sighted and rich large US firm will catch on (or “get it,” as it were) and see the positive ROI that lurks in devoting resources to automation R&D. Either that, or when the bars to those self-same consulting firms and accounting firms’ practice of full-fledged law come falling down, the R&D effort won’t be the law firms’ alone to exploit.

The language of the law . . . (Part II)

I’d like to take my “contracts as computer programs” idea (see post below) in another direction. Before doing so, hats off to Ron Friedmann of Prism Legal Consulting who, after looking at my earlier post, spoke much more felicitously of “contracts as code” and discussed yet another extension of the idea with the suggestions that contracts might merit coding with XML tags (take a look at http://www.prismlegal.com/wordpress/index.php?m=200401#post-127).

Alright, contracts as code it is, then. With this idea in mind, recall that, before actually writing the code for an application, a programmer might “outline” the program’s steps using a flow chart to picture all of the “if, then this, else that” meanderings of the program’s logic. Well, I’m not a flow-charting maven myself, nor do I presume to know how to code in any more than a very rudimentary way, but I have at times dealt with the hairiest of contract provisions. These are the clauses with so many internal conditions, dependencies, branches and the like that even the tried-and-true method of merely block-indenting the various dependent clauses and exception-like-provisos leave the drafting lawyers, let alone another lawyer or the client, reaching for the Advil bottle after several attempts at parsing the provision at hand.

Suppose that lawyers mustered enough gumption to learn the rudiments not of programming, but of using flow-charting tools – Microsoft Visio perhaps or some of its less expensive and complicated cousins. Maybe the lawyer will find that, by diagramming each of the clause’s very own “if, this, then yes, do that” internal structure, the meaning will become much more readily apparent, glitches in the logic will stand out more clearly and lay people will finally catch on to how the provision does or doesn’t work.

Case in point, a good ten years or so ago, a more junior lawyer in my then firm and I were asked by a non-US client to explain how a complicated contract provision worked. We started preparing our explanation in standard English prose, all the time mindful that we were not only going to have to hurdle the difficulties that the clause itself presented, but we were also going to have to get over the English-as-a-second language obstacle. Together, we hit upon the idea of using a flow-chart (nothing itself too sophisticated, no legend necessary to decipher the meaning of the use of circles vs. the use of parallelograms). We sent off our fax (little email in those days) and, voila, the client got it right away and readily understood a problem with the language’s logic that we pointed out in the briefest of text that accompanied the faxed chart. Who knows, maybe the client would have gotten the point if we had made our presentation in the “standard” way, but she herself enthusiastically endorsed the flow-chart approach (“one picture is worth, . . .” and all that).

I’ve tried to use this flow-chart approach when it comes to my own drafting and, all too frequently, I catch myself all balled up in a logical bind as I draft in English first, flow chart second and gnash my teeth at my gaffe third. And, yes, when disciplined enough, I even diagram first, and draft in English second.

Oh for a set of flow-charting tools developed just for complex commercial contract drafting. Had it been four years ago, I’d end this post with “Business model, anyone?”

The language of the law is logic and experience. (Apologies to Justice Holmes.)

Commercial contracts are a lot like computer programs. No great news to my lawyer/programmer friends who are trying to develop software that assists in the drafting of contracts.

Think about it. The typical bank credit agreement has a host of definitions that are like the variables in a program; little storage boxes that hold the “value” (i.e., the words comprising the defined term) assigned to each variable and that later get used throughout the program; er, I mean the credit agreement. And the various representations, warranties, conditions and covenants are like various “if-then” modules; if one of the contract parties does or doesn’t do thus and so or if a certain event outside even the contracting parties’ control does or doesn’t happen, a party does or doesn’t breach a representation/warranty, satisfy or fail to satisfy a condition, breach or not breach a covenant.

The analogy can be stretched too far, of course. Contracts don’t’ operate computers, contracts shift risk, thereby lowering the costs of dealing with events that happen over time in circumstances where it’s cheaper to deal with the future than to try to cram performance into the present. Unlike computer programs, the language in which commercial contracts are drafted by US lawyers isn’t governed by a strict syntax and semantics which admits of little or no vagueness and ambiguity. English isn’t, thank God, C++. But certain things do follow from even a properly cabined version of the analogy.

What relevance to commercial contract drafting. Well, several points of relevance. First off (and the subject of this post), one of the reigning aspects of computer programming today is something called “object oriented programming” or OOPs (a word not at all foreign to this lawyer). One prominent aspect of OOPs is the creation of standardized computer programs parts, modules if you will, that are written, tested and known to a high degree of confidence to carry out a particular task pretty darn well so that a computer programmer writing a new application can borrow the module from a library of same for use in the program under construction. Saves time by avoiding a reinvention of the wheel and makes for better quality control by piggybacking on the effort at testing that went into the module’s creation. It also allows the program to be analyzed on a piece-by-piece basis so parts of a program that may turn out to be millions upon millions lines of code can be worked on and understood separately by a team of programmers and then linked together. (Not to say that a whole host of other problems wont’ follow from the complexities of the linking-together exercise).

Most law firms have contract or brief banks. Stock clauses that have won the hearts and minds of the lawyers in the firm. These get linked together like the modules mentioned above to form a contract. As we warn all junior lawyers (and ourselves in our better moments): don’t be a slave to the forms, THINK about each word and clause and about how they’re put together.

But wait a minute! Think about each word. No. That’s my point, much of what we lawyers do even when we’re doing it superbly well shouldn’t require thinking about each word. There should be, not just within firms but even between them, more commonality of language in the contracts used so that junior and senior lawyers alike don’t have to read each word because they’re confident that, within certain confines, the words are the same contract to contract within a given category of contracts. How many times have I had to read each word in a 100-page credit agreement; confident that, say, 85% of what’s intended to be said comes from a stock set of ideas, and all I’m really doing is making sure that the language works as intended by all from the outset.

This is silly; efforts should be made to standardize contract modules that lawyers all over the country can count on to say the same thing that everyone in the field of law from which the contract comes knows ought to be said. Pie in the sky? Well, I don’t underestimate the problems of arriving at uniformity. Just look at the difficulties in coming up with uniform state laws. And, no, my litigator friends, you won’t have your business curtailed all that much; again, to take the uniform laws as my example, there’s plenty of argument over how to interpret the standardized language in Article 9 of the UCC.

But let’s face it business lawyers: The value we add doesn’t come from watch-dogging each jot and tittle in a 100-page agreement; it comes from the customization and tweaks that affect, in most deals – even the big-ticket deals, but few of the clauses before us in the contract at hand. It’s the 10%-inspiration, not the 90%-perspiration, that we are (or ought to be) paid for. And junior lawyers ought to learn from the standard clauses that a nationwide (?) committee of the best and brightest lawyers in a given field have labored over. And, again, the standard-clause approach I’m advocating can have its uses not just in the house-closing transaction, but in the mega-deals too.

They’ll be plenty of work, good and challenging work, left to be done in adding the custom language and revisions to the standard clauses once they’ve been adopted. Inter-firm standardizers of contracts unite; we having nothing to lose but billable hours that shouldn’t have been the billed to the client to begin with! (A whole other post, that.)

Don't modify the software, modify the way you practice law!

I've bent the ear of not a few acquaintances recently, singing the praises of "Softwar" a book by the former Economist technology writerm Michael Symonds, about Larry Ellison and Oracle. Not just a gossipy tale of Ellison's billionaire's life, the book is a serious treatment of Oracle's triumphs and goofs as one of the biggest software companies in the world.

Risking over-simplification, I cite one of Ellison's theses: When it comes to a business running Oracle's enterprise application software properly, the business ought to consider modifying its processes to fit the software, not modifying the software to fit the existing business processes. Much of the thesis' argument is based on the importance of avoiding the horrible complexity of taking an already complex piece of software such as enterprise ERP or CRM and tweaking the code to find that you've only broken the application. But a more significant take for me is that, assuming the software's any "good," perhaps the altered business processes that the unmodified software calls for are better than the business processes that had been operating before the software was installed.

Serendipitously, in the January 12, 2004 issue of "Fortune," there's an interview with Peter Drucker in which the interviewer asks the 94-year old guru, "What is the most important impact of information technology on business?" Drucker answers: "Information technology forces you to organize your processes more logically. The computer can handle only things to which the answer is yes or no. It cannot handle maybe. It's not the computerization that's important, then; it's the discipline you have to bring to your processes. You have to do your own thinking before you computerize it or else the computer simply goes on strike."

Now, Drucker goes on to point out several disadvantages of "this enforced discipline." It tends to force oversimplification; some business decisions can't always be systematized successfully. He then goes on to point out, too, that "older executives find it excruciating to have to be [as] explicit [in arriving at and implementing their decision processes], because they just don't want to be."

The "common law tradition" praises the accretive, incremental, at-the-margin, unsystemized results that - benefitting from the wisdom that comes of slow modification and experience - slowly build and alter the corpus that is the common law. Much of the way law firms conduct their practices seems to me to be a variant of the common law's approach to "conducting law." But just maybe law firms ought to think more consciously about how their practice processes work, and about how those processes can be explicitly, systematically rationalized.

I'm talking here not about law firm management, but about how deals are done, contracts get negotiated, and drafted, briefs get written and trial preparation gets done. Maybe, just maybe, the hoary old objection that practice software shouldn't be installed because it forces lawyers to modify the way they conduct their practices and that doing so is a bad thing is not 100% correct. When I hear that the software must fit existing practice processes to get the necessary "buy-in," to really be useful for the lawyers, I now think to myself - "not really."

Maybe lawyers should ask themselves if they shouldn't get around to examining just how they ought to modifiy their practice processes to fit good software. Buy'in's tough to get, but continuing to practice law with unexamined processes that impair efficiency, make the quality-of-life aspects of practice worse and, someday, put the firm at a competitive disadvantage when other firms "finally get it," is worth the effort - to get lawyers to buy into not just new software, but also new and better ways to practice law.

Lawyers don't get it.

Get what? The intelligent application of information technology to the practice of law. Yes, there are a lot of "legal tech evangelists" out there, so why am I giving voice to my enthusiasm for the proper use of tech in the practice of law? Principally, just to get it off my chest. No, I'm not a cheerleader for just the latest gadget or software eye-candy (though I do have enough gadgets to set my wife's head a-shaking). I'm talking about quality-of-life enhancing, practice improving, profit-growing tools that can appeal to the hard-nosed budget minders and "law first, tools a distant-second" lawyers that, quite understandably, don't have any more enthusiasm for or fascination with hardware and software than they do for the penta-flex file folders that hold their paper files. (Oh, sometimes I will be dreaming a bit, out loud, about pie-in-the-sky devices which, if they could be developed and made cost-effective, would make me a better and more efficient lawyer; but I'll try not to let those dreams dominate the blog.)

Case in point: I can't tell you how many times I've been a conference call during my 28 years of corporate law practice in NYC and heard the following, maddening voice: "Let's go to line 23 on page 84; no, I said line "23" not "33," yeah, the line beginning with "-tion" and then count in 12 words from the left, yup, right after the open parenthesis and then add the following language, which I'll speak slowly. [A sentence of 32 words is now read out loud, not all that slowly. Then repeated twice, a little more slowly each time.] Well, does that new language sound OK?"

There's a much better way: Nothing original here, but suppose all lawyers from among the several different firms on the call could each get access to the document from a password-protected website, where they could take turns moving the cursor on their desktops to locate a place in the document under discussion and then also take turns typing out changes for consideration.

The products are out there. Intralinks is a web-hosted site that allows documents to be posted for review in a secure fashion. But it's not a device that is easily assembled on the fly and doesn't (at least in my use of it to date) appear to support collaborative editing. Groove Networks' web-based collaboration suite is out there - but, in my admittedly informal survey of lawyers young and old alike, no one's heard of it. In fact, when I pine for the interoperable, secure, inter-firm web-based tool that I've described, I'm met at best with looks of incompreshension and, at worst, with funny smiles (suggesting that I'm looney tunes) or loudly-voiced objections

Dear readers, do I make too much of the conference-call problem? Am I simply failing when it comes to describing the "better way's" way of making things better? Let me have your thoughts. All I can say is: One more three-hour conference call like the one I had recently, with five separate parties and one humongous document to discuss and review, and well, I'll just . . .