After many years in the profession, I’m convinced that the most difficult skill for any lawyer to master is the ability to write with simplicity and clarity. I believe there are several reasons for this. The first is that under the ethics rules of most bar associations, lawyers are charged with “zealous” representation of the interests of their clients. Not “good” or “satisfactory” or “adequate” – but, “zealous”. As a result, most attorneys draft agreements to cover every possibility no matter how remote or unlikely.
A second reason is that attorneys seldom create agreements from scratch. Instead, in the interests of efficiency, we build off existing templates and add additional language covering any contingencies that we have experienced or imagined. When the next attorney uses your template, he or she rarely challenges the necessity of the additions that you have made. With each revision, the agreement grows in size and complexity. It’s not dissimilar from the process of creating some software.
Now layer onto this a third factor – fear of malpractice. Those stories about a minor drafting error resulting in a significant damage award are not just apocryphal.
The result is lengthy and verbose documents that create more ambiguity than they resolve. A classic example is the “force majeure” clause that you see in many agreements. Originally, it was intended to identify occurrences outside the control of the parties that would excuse non-performance – i.e. “acts of God”. Attorneys then decided to include a list to identify what specific events were intended. Rather than tailoring that language to each contractual arrangement, successive attorneys kept adding to the list – “just to be on the safe side”. I’ve seen agreements identifying “volcanic eruptions” as a force majeure despite the fact that the geographic location of the contracting parties has not seen this type of event since our long ago predecessors walked the earth.
Unfortunately, these habits are difficult to break. For me it wasn’t until attending a class on legal writing that I began to understand that the complexity of my drafting was in many cases not protecting my clients. Instead, it was creating ambiguity. And, in the contract world ambiguity begets litigation.
With this in mind, I have actively “encouraged” 🙂 my organization to create contracts that are models of clarity and simplicity. We owe it to our internal clients and especially our customers. I’m happy to report that we are making progress. With the support of outside counsel (one who understands the benefit of drafting clarity) and reliance on the SEC’s guidelines for Plain English” our team is beginning to roll out new forms of contracts that we will be using with customers this year. I’ll admit it is not happening at the pace I would like, but given the breadth of our company’s business and our many types of partner relationships, we have a large number of agreements to change.
To give you a small example of the magnitude of the change, here’s what one agreement used to say about ordering:
- Company may order Products or Services by:
- submitting an Electronic Order in the manner directed by Sun; or
- submitting a Purchase Order to Sun (and Company acknowledges that Electronic Orders for certain Products or Services may require to be supplemented by a Purchase Order); in each case specifying the Products or Services required and referencing the General Terms and applicable Exhibit numbers. By doing so, Company agrees that the Order is governed by the Agreement.
- Sun may accept the Order by:
- issuing an Order Confirmation to Company; or
- shipping the Products or initiating performance of the Services required in the Order.
- The identification of the Products or Services in the Order, Service Contract and any Order Confirmation, together with any applicable Service Listings or SOWs and the Agreement, will create a binding contract between Company and Sun for the purchase of those Products or Services.
Here is what we say now:
To buy a Sun product or service you must send a purchase order to us or, if you meet our requirements for placing orders electronically, you may send your order to us electronically in the way we tell you.
How we accept an order
We will show that we have accepted your order by:
- shipping the product;
- starting to provide the service; or
- sending you a written acceptance.
You agree that these contract terms apply to any order we accept.
Notice any difference?
By the way, just to make sure that our efforts resulted in truly simple and easy to understand contracts, we did something else. We sent our agreements to an organization in England called the “Plain English Campaign”. This organization is an independent group with members in over 80 countries focused on fighting for plain English in public communications. The result? The Plain English Campaign reviewed our agreements and awarded them a “Crystal Mark” certification. It’s a sign that the terms meet the Campaign’s criteria and are considered a model of simplicity and clarity. We think our customers will feel the same way.
mike's blog 
This is great… we should do this in every part of our business, from emails we’re sending out to clients, Sun.com, technical documentation and training. We seem to be so “zealous” about our products, that we tend to create more technical rat holes than talking in plain <select your language>.
Great job, Mike. Not only do cleaner contracts reduce litigation-inducing ambiguity, in my experience, they also reduce the transaction costs of negotiating with customers because it’s cheaper and quicker for both parties to review shorter, easier-to-read contracts. Have you thought about tracking the “time-to-close” of sales contracts pre- and post-contract revision? My guess is that you’ll markedly increase the velocity of deals with your approach. Eric.
A big problem, it seems to me, are legal writing classes. You can take a perfectly good writer, send him to law school for three years, and then wind up with a writer whose writing is cryptic, at best.
A big solution is to use editors to review legal documents. Every writer needs an editor, and lawyers are certainly no exception to that sturdy rule, as the Rogers/Aliant dispute shows.
Mike: Given your interest in contract language, you might find of interest my book, A Manual of Style for Contract Drafting (ABA 2004), and my blog, which is at http://www.adamsdrafting.com. Regards, Ken Adams
As with most of these “plain language” rewritings, the rewritten version has different meaning.
Here, the main thing that has happened is that various requirements in the orginal were just deleted. There is no requirement that Company acknowledge that Electronic Orders sometimes need be supplemented by a P.O., and the requirement of specificity in the P.O. is also deleted. Thus, most of a.ii is deleted. The whole clause about binding contractual obligations in c is also deleted in the rewrite. The “Order Confirmation,” presumably a defined term, is replaced by “written acceptance.”
Most important, in the original defined terms like Product, Order, Order Confirmation and so on are capitalized. This usually indicates that they are specially defined in a separate section. Here, they are all lower-cased, and it is harder to figure out which of them are defined terms and which of them are just using the colloquial definition. Even if they are defined in a special section, because they are lowercased they might be used colloquially as well in the contract.
Although it is true that the rewritten version gives laymen a quicker overview of the requirements, it’s not as precise, it’s not as flexible, and it would be more – not less – expensive to litigate because of the lack of defined terms.
Since your from Sun, here’s an analogy. Java is much wordier than Perl – but Java is also safer, each term having a specific, precise, defined, meaning that is immediately apparent from the text.
While I applaud your efforts, I’m going to have to say that the two provisions possibly create two very different business terms (and possibly several different use scenarios).
What criteria have you used to decide that they are the same?
The first provision is obviously convoluted and awkwardly structured. However, the second is a departure from some of the very terms that make it convoluted and awkward. I wonder if your example is a better illustration of reviewing terms that no longer reflect the desired process. I wonder, instead, if much of the first could be improved by simply removing the redundancies. From my personal experience, that results in a significant gain without any real loss, and indeed some of that obviously occurred in this example.
In addition, the second provision makes considerably better use of language. However, I’m left with a feeling that not all the relevant concepts were captured and, instead, would be pushed off to things like the order forms.
I’d like to see Sun work to promote more “plain language” in open source licensing. While the CDDL was an improvement over other open source licenses that I’ve looked at, I was still surprised at how much complexity was left in. Members of the open source community want clarity in the legal documents that bind them, so that they don’t need counsel at their side before participating in the open source community. “Plain language” helps promote the trust that is necessary for healthy open community growth.
Legal clarity. Now there’s an idea.
The FreeBSD community is still waiting.
Testing
The lawyers at UK brewer Scottish and Newcastle have taken this even farther. See http://legaltech.com/cblog/index.php?/archives/21-Extreme-Contract-Simplification.html.