Carr shows that as much as automation enriches our lives, it can also impoverish. For example, he describes how all-encompassing flight automation appears to have resulted in a “deskilling” of pilots, leading to a new type of aviation accident. And how implementing electronic medical records has had all sorts of unintended effects. More generally, he argues that unthinkingly embracing automation risks making us unwitting and complacent cogs in the machine.
Anyone who is paying attention could offer plenty of additional examples. Recent ones that come to mind include evidence (1) that giving computers to disadvantaged middle-school students leads to a drop in grades (here); (2) that you retain information better if you take notes by hand instead of using a laptop (here); and (3) that people prefer print for serious reading (here).
So I agree with Carr that it’s important to be an informed consumer of technology. For me, here are some ways that plays out:
- I bought my daughter The Glass Cage, but in hardback, not an ebook version. I have it on Kindle, which is certainly convenient, given my traveling, but I regret not being able to flip the pages, which would allow me to more easily grasp its structure.
- Reading The Glass Cage left me relieved that I don’t use Facebook; I’m happy with my own little soapbox, thanks. Carr quotes Mark Zuckerberg of Facebook as saying that “having two identities for yourself is an example of a lack of integrity.” What an odd thing to say.
- Regrettably, I’ve allowed myself to become a slave to Google Maps. I often follow its instructions without having the foggiest clue where it’s taking me, and I panic when sporadically it seizes up or asks me to do something that would be a bad idea, such as making a U-turn as I’m barreling down the highway. Henceforth, I’ll use it as an aid instead of letting it be my master. (Let’s see how that resolution goes.)
But you might have noticed an elephant in the room. I’ve wholeheartedly endorsed using ContractExpress to automate the process of creating contracts. Won’t that result in contracts professionals being “deskilled,” just as pilots have been?
The answer is a resounding “No.”
To gauge the effects of automation, you have to consider the nature of the automation and what it seeks to replace.
When it comes to traditional contract drafting, let’s not have any illusions. It’s standard practice for lawyers to draft contracts by regurgitating, with little independent thought, precedent contracts that as a matter of substance and language leave much to be desired.
For a case study of substantive incoherence in traditional contract drafting, see The Three and a Half Minute Transaction: Boilerplate and the Limits of Contract Design, by Mitu Gulati and Robert E. Scott, which discusses the mysterious role of the pari passu clause in sovereign debt contracts. As regards evidence for language incoherence, well, you could do worse than browse A Manual of Style for Contract Drafting.
When considering contract automation as an alternative to traditional drafting, it’s important to know what kind of automation you’re dealing with. What I have in mind is a system that offers the user expert substance, clear and concise language, extensive customization, and plentiful guidance. In other words, something like my NDA template (here).
In theory, a contract-automation questionnaire could constrain the user in the same way that an electronic-medical-records questionnaire might constrain a doctor looking to diagnose a patient. But that’s not a realistic possibility, as transactions offer far less variety than does the human body.
Furthermore, a contract-automation questionnaire would likely offer users more choices than they would get from basing a contract on a precedent contract or two. A contract used for a given transaction necessarily reflects only a fraction of the choices that would be available to someone considering the transaction afresh, and that’s exactly what a contract-automation questionnaire permits.
Similarly, rote copying of doctor’s notes in electronic medical records might be a problem, but it’s unobjectionable in contract drafting, as it makes sense to use the same language to express the same transaction components.
Nevertheless, in The Three and a Half Minute Transaction, Gulati and Scott attempt to blame “commoditization of standard-form contract drafting” for how law firms have mishandled the pari passu clause. Indeed, that notion underlies the book’s title. But that’s a flaw in the book. Here’s what I say in my review (footnotes omitted):
[Contract-automation] systems make it easier to control what’s in an organization’s contracts. Gulati and Scott acknowledge as much, stating that “[i]f anything, firm-wide standardization and centralization should make changes easier to implement than in systems where contract drafting is done in the offices of individual partners.” It’s hard to see how allowing individual lawyers to revert to cobbling together contracts as they see fit, with all the reinventing of the wheel and room for error that that allows, would improve contract language.
That’s why after highlighting commoditization as a factor, Gulati and Scott ultimately do not in fact make a case that commoditization played a significant role in how the pari passu clause was handled. That element of their analysis simply fizzles out.
So a serious contract-automation initiative would offer results that are more customized, and far clearer, than the average product of the traditional copy-and-paste system.
But according to Carr, automation falls short when engineers and programmers “hide the workings of their creations from the operators, turning every system into an inscrutable black box.” Isn’t that a problem with automated contract creation? Not with ContractExpress: the control freaks among us could select “Preview” mode, which shows the user how the contract text would change to reflect how you answer a given question.
That said, I’ve noticed two ways in which reliance on technology can subvert contract automation.
First, sporadically I hear from people who are put off by the number of questions in my NDA questionnaire; they would prefer to answer perhaps a dozen questions instead of, say, fifty. But my NDA template is for users who feel that enough is at stake in creating an NDA that it’s worth their while to take an hour or two to get to grips with the questionnaire. Perhaps reluctance to grapple with the questionnaire is due in part to our being used to the instant gratification that comes with having a vast universe of information at our fingertips.
And second, one way to guarantee poor contract automation is to let technology decide what language to use. Technology can’t tell you what language works best, in terms of clarity and relevance, for a given provision. Instead, all it can tell you is the relative popularity of different formulations. For an example of contract automation that put too much faith in technology, see this 2012 post.
I use technology not to create optimal contract language, but as a way to scale it.
Contract-Automation Clearinghouse is where I put my posts on contract automation and related topics. My regular blog is at Adams on Contract Drafting.