W hat's the current state of business contracts? Well, we have bad news, then good news, followed by more bad news and good news: Most contracts prose is dysfunctional, but training is available to help contracts professionals draft clearly and concisely. But that gets you only so far; you also have to supplement training with centralized initiatives.
The Current Dysfunction
The first bit of bad news is that the writing in most contracts is fundamentally flawed. Any given contract will likely be riddled with deficient usages that collectively turn contract prose into "legalese" — flagrant archaisms, botched verbs, redundancy, endless sentences, meaningless boilerplate, and so on.
Even contracts at the clearer end of the spectrum show plenty of room for improvement. For example, see the analysis by one of the authors, Ken Adams, of IBM's revamped cloud-services agreement. 1
Because of the confusion caused by defective contract language, it takes longer than it should to close deals, so you waste time and money and potentially hurt your competitiveness. And contract parties routinely end up in disputes that could have been avoided.
But what's required for clear, concise contracts is no mystery. Contract language is limited and stylized — it's analogous to software code. It follows that it's possible to specify in a set of guidelines those usages that are clearest and those that are conducive to confusion — that's what Adams does in his book A Manual of Style for Contract Drafting (MSCD). It also follows that it's possible to train your contracts personnel in how to draft and review contracts consistent with a set of guidelines. That's the good news.
Clear Contract Language
Here's a small taste of what clear contract language looks like.
Lose the Archaisms.
A simple way to assess the quality of a contract is to see if the front of the contract is littered with archaisms, usually in all capitals: whereas, now therefore, and, if you're particularly unfortunate, witnesseth. They're useless relics from long ago. In themselves, they're harmless, but they clog up the works, insult the reader's intelligence, and are a reliable sign that the contract contains other, more worrisome dysfunction. But it's easy to eliminate them, and no one will miss them — certainly not business people.
Gain Control of Verbs.
Chaotic verb structures consistently afflict traditional contract language.
On the one hand, in traditional contract drafting the word shall is drastically overused — it's found in many different contexts, even though in contract drafting you should use one word to convey only one meaning. For example, drafters routinely express as an obligation (The Buyer shall submit a Dispute Notice …) what makes sense as a condition (To dispute an invoice, the Buyer must submit a Dispute Notice …). The resulting confusion can lead to dispute. 2
On the other hand, drafters generally also use many different verb structures to convey the same meaning. The most concise way to express discretion granted a contract party is to use may, but you see in contracts no end of wordier alternatives used haphazardly: is authorized to; is entitled to; shall have the right to; will be free to; has the option to; and so on. That forces the reader to work harder.
Purging contracts of this sort of dysfunction requires recognizing that when it comes to how verbs are used, each sentence in a contract expresses one of a range of meanings. Adams refers to this approach as "the categories of contract language," and he has identified the different categories — language of performance, language of obligation, and language of policy, among others.
You have better command of meaning, and readers benefit, when you use specific verb structures for the different categories of contract language, with those verb structures being consistent with standard English, as adjusted for the specialized context of contracts. For example, we recommend that you use shall only to impose an obligation on a party that is the subject of a sentence, as in The Company shall purchase the Equipment. Using will or must instead of shall offers an easy sense of modernity, but at the prohibitive cost of muddying the distinction between categories of contract language.3
Stop Using the Phrase Best Efforts.
A fixture of commercial contracts is use of the word efforts to modify contract obligations. (In England, the equivalent is the fusty endeavours.) It's appropriate to use an efforts standard when a contract party doesn't have complete control over achieving the contract goal in question.
Most contracts professionals will tell you that of the efforts variants, best efforts imposes a more onerous standard than does reasonable efforts. But such distinctions make no sense as a matter of idiom and as a matter of contract law. That's why US courts have, with a remarkable degree of unanimity, said that all efforts standards mean the same thing — reasonable efforts. By contrast, courts in some other jurisdictions have tried to distinguish between efforts (or endeavours) variants and have failed utterly.4 It follows that although it's routine for contract parties and their lawyers to haggle over these and other efforts variants, they're unable to articulate a principled distinction between different efforts standards for purposes of a given obligation.
The fix for this confusion is straightforward: use just reasonable efforts, as best efforts promises more than it can deliver. But bear in mind that structuring efforts provisions involves more than just which efforts standard you use.5
Don't Rely on Mystery Usages.
Too often, those who work with contracts rely on mysterious legalisms that have somehow become fixtures in contracts.
Consider just one example — hold harmless, which usually is found in the phrase indemnify and hold harmless. It has no established meaning, although legal dictionaries will tell you that it means the same thing as indemnify. Using indemnify and hold harmless in a contract adds redundancy, and it gives a disgruntled party the opportunity to try to insert unintended meaning into the contract by arguing that hold harmless means something distinct from indemnify.
So if a contract provides for indemnification, don't leave hold harmless in there simply because it happens to be in whatever language you're copying. State explicitly what indemnification covers. Reimbursement of out-of-pocket losses, assumption of liabilities, or both? Just nonparty claims, or also claims between the parties? To rely instead a mystery phrase such as hold harmless is to ignore that anyone who drafts or reviews contracts has the power and the responsibility to state the deal clearly.
The Limits of Training
It's standard for contracts personnel at companies to learn the rudiments of contract language on the job, with limited training of uncertain quality. They tend to rely unduly on the conventional wisdom they pick up, much of it shaky, and they tend to copy on faith what's in precedent contracts and company templates.
So your company would certainly benefit if your personnel were to become better-informed consumers of contract language. Books, seminars, and online materials are available to help them. But — and here's the second bit of bad news — that's not enough if you want a consistent and effective contract process.
For one thing, in the absence of centralized initiatives, training by itself leaves control in the hands of individuals with varying degrees of experience, aptitude, and dedication. It's likely that the contract language they produce will vary widely in terms of quality, relevance, and the usages employed.
Furthermore, the starting point for a company's contracts is the company's templates. If you don't fix your templates, there's a limit to what individuals can do to improve a company's contract language.
So fixing your contract process is possible if you take two or three additional steps — that's the second bit of good news.
First, adopt a style guide for contract language, so your personnel have standards to comply with when drafting and reviewing contracts. Without a style guide, you're essentially acknowledging that it's acceptable for your contracts to reflect an improvised and inconsistent approach to contract language.
It's unlikely that companies would be willing or able to produce a comprehensive style guide, but a style guide of twenty or thirty pages would provide only limited guidance on a limited range of issues. And companies can't count on having access to suitable expertise. Adobe's legal department has produced an ambitious and pioneering style guide for contract language, but it exhibits shortcomings attributable to these impediments.6
With the aim of taking advantage of the guidance offered in MSCD, Adams produced a model "statement of style."7 It's an example of a short document a company could use to say that it's adopting a contract-drafting style based on MSCD. But that approach offers users two unsatisfactory extremes — the model statement of style offers no detail, whereas MSCD offers more detail than many contracts professionals would be willing or able to digest. What is currently lacking is an authoritative style guide that offers comprehensive guidance with limited explication.
A second step toward fixing your contract process would be overhauling your templates so that they're consistent with your style guide, and then maintaining them. Clear, modern contract language would be built into your contract process, instead of remaining something aspired to but out of reach. Your templates would be more likely to truly address your needs, you would have on hand a body of reliable contract language to use when working with others' drafts, and your employees would be immersed in quality contract language.
Retooling your templates sounds like a lot of work, but it's not, if you enlist suitable expertise. Your contracts personnel might know your business intimately, but that doesn't mean they're the best people to translate your deal objectives into clear and concise contract language.
And third, if deal volume, deal value, and the level of customization required from deal to deal make it cost-effective to do so, automate the task of creating first drafts of your contracts. (Adams uses the software ContractExpress for this. Chris Lemens uses a more rudimentary but nevertheless effective hand-coded web page that allows sales people to assemble the set of documents they need.) With automation, you create contracts not with word processing but by answering an annotated online questionnaire, with the system then pulling together and adjusting preloaded language. That would allow you to create contracts more quickly, with greater control, and with fewer mistakes.
And in the right circumstances, automation would allow you to shift primary responsibility for creating first drafts of contracts from your law department to your business people, with the law department becoming involved only to handle whatever is out of the ordinary. That would allow your lawyers to focus on higher-value tasks and might reduce your need for additional legal personnel.
The changes we propose are feasible, and they could pay for themselves by speeding up the contract process, reducing risk, and keeping your headcount down.
But in the precedent-driven world of contracts, inertia is a force to be reckoned with. Many people don't like change or creativity. They prefer what they're used to, and they don't appreciate anyone suggesting that it's somehow lacking. And in big companies, turf battles can further impede change.
Furthermore, some lawyers would likely find it challenging to be instructed to change how they draft contracts: the illusion that one writes well is hard to shake. And promulgating a style guide for contract language can threaten notions of lawyer autonomy.
So although there's plenty of high-minded blather about effecting change in contracts, it's rare to see that reflected in a company's contracts.
If an organization isn't ready for change, it's unlikely that just demonstrating the shortcomings in its contracts would overcome inertia. What determines whether an organization is amenable to change is a broad mix of intangibles. It probably helps if it's undergoing a related change — for example, hiring its first in-house lawyer. A strong voice at the center advocating for change probably helps too. But perhaps the factor that facilitates change the most is if an organization is under pressure, so that people have to decide what they're most scared of, the notion of change or the likelihood that they're wasting time and money, hurting their competitiveness, and assuming unnecessary risk.
Even if a company has an appetite for change, it might be that change has a better chance of taking hold if you approach it incrementally. For example, instead of formally adopting a style guide up front, that could come later — with suitable training and revised templates, your personnel people would likely gravitate toward the preferred style without being told to. And instead of rushing headlong into an automation program, you could at very little cost get a pilot automated template up and running.
So if you're looking to make your contract process more effective and nimble, by all means train your personnel, but also consider making the necessary systemic changes.
1. See Kenneth A. Adams, Plenty of Room for Improvement: My Critique of IBM’s New Two-Page Cloud-Services Contract, Adams on Contract Drafting (Dec. 29, 2014). ↩
2. See, e.g., Howard v. Federal Crop Insurance Corp., 540 F.2d 695 (4th Cir. 1976).↩
3. See Banishing Shall from Business Contracts: Throwing the Baby Out with the Bathwater, The Australian Corporate Lawyer, Sept. 2014.↩
4. See With “Efforts” Provisions, Reasonable Is Better Than Best, The Lawyers Weekly, May 16, 2014 (Canadian caselaw on best efforts); Beyond Words, Solicitors Journal, Sept. 30, 2014 (best endeavours and its variants under English law). ↩
5. See A Manual of Style for Contract Drafting, ch. 8 (3d ed. 2013). ↩
6. See Kenneth A. Adams, Some Thoughts on the Adobe Legal Department Style Guide, Adams on Contract Drafting (July 16, 2015). ↩
7. See A Manual of Style for Contract Drafting, at 451–55; also available here.↩