Book Review: Working With Contracts

Con­tracts is one of those ar­eas that I always figured I ought to study, at least enough to pick up the ba­sics, but never seemed ei­ther in­ter­est­ing or im­por­tant enough to reach the front of my queue. On top of that, there’s a lot of differ­ent an­gles from which to ap­proach the sub­ject: the law-school-style Con­tracts 101 class cov­ers the le­gal prin­ci­ples gov­ern­ing con­tracts, the economists’ ver­sion ab­stracts away the prac­ti­cal speci­fics and talks about con­tracts in game-the­o­retic terms, more busi­ness-ori­ented books of­ten fo­cus on ne­go­ti­a­tion, etc.

Work­ing With Con­tracts: What Law School Doesn’t Teach You” is about the prac­ti­cal skills needed for work­ing with con­tracts on an ev­ery­day ba­sis—speci­fi­cally the sort of skills usu­ally picked up on the job by young lawyers. It talks about things like what to look for when re­view­ing a con­tract, how to or­ga­nize con­tracts, why lawyers use weird words like “heretofore”, var­i­ous gotchas to watch out for, etc. It as­sumes min­i­mal back­ground knowl­edge, but also in­cludes lots of tech­ni­cal nuts and bolts. In short, it’s the perfect book for some­one who wants a tech­ni­cal un­der­stand­ing of real-world con­tract prac­tice.

This post will re­view in­ter­est­ing things I learned from the book.

Back­ground Knowledge

First, some very brief back­ground info, which the book it­self mostly as­sumes.

Le­gally, in or­der to count as a “con­tract”, we need four main pieces:

  • Offer: some­one offers a deal

  • Ac­cep­tance: some­one else ac­cepts it

  • Con­sid­er­a­tion: both par­ties gain some­thing from the deal; it’s not a gift

  • Mu­tual un­der­stand­ing: both par­ties agree on what the deal is and the fact that they’ve agreed to it

A Con­tracts 101 class has all sorts of de­tails and gotchas re­lated to these. No­tice that “sig­na­ture on a piece of pa­per” is not on that list; e.g. oral con­tracts are en­tirely en­force­able, it’s just harder to prove their ex­is­tence in court. Even im­plicit con­tracts are en­force­able—e.g. when you or­der food from a restau­rant, you im­plic­itly agree to pay for it, and that’s a legally-en­force­able con­tract. That said, we’ll fo­cus here on ex­plicit writ­ten con­tracts.

Once formed, a con­tract acts as cus­tom, pri­vate law be­tween the par­ties. En­force­ment of this law goes through civil courts—i.e. if some­one breaches the con­tract, then the coun­ter­party can sue them for dam­ages. Note the “for dam­ages” in that sen­tence; if a coun­ter­party breaches a con­tract in a way that doesn’t harm you (rel­a­tive to not breach­ing), then you prob­a­bly won’t be able to sue them. (Po­ten­tially in­ter­est­ing ex­er­cise for any lawyers in the au­di­ence: figure out a re­al­is­tic con­trac­tual equiv­a­lent of New­comb’s prob­lem, where some­one agrees to one-box on be­half of some­one else but then two-boxes, and claims in court that their de­ci­sion to two-box benefited the coun­ter­party rather than harm­ing them. I’d bet there’s case law on some­thing equiv­a­lent to this.)

Note that this is all spe­cific to Amer­i­can law, as is the book. In par­tic­u­lar, other coun­tries tend to more of­ten re­quire spe­cific word­ing, cer­e­mo­nial ac­tions, and the like in or­der to make a con­tract (or com­po­nent of a con­tract) en­force­able.

What Do Con­tracts Do?

The “func­tional” com­po­nents of a con­tract can be or­ga­nized into two main cat­e­gories: rep­re­sen­ta­tions and covenants. A rep­re­sen­ta­tion says that some­thing has hap­pened or is true; a covenant says that some­thing will hap­pen or will be true.

Some ex­am­ple rep­re­sen­ta­tions:

  • ABC Corp signs a state­ment that they have no pend­ing law­suits against them.

  • Bob signs a state­ment that the house he’s sel­l­ing con­tains no lead-based paint or as­bestos in­su­la­tion.

  • Carol signs a state­ment that the forms she pro­vided for a mort­gage ap­pli­ca­tion are ac­cu­rate and com­plete.

  • Ti­tle Corp signs a state­ment that there are no out­stand­ing mort­gages on a piece of prop­erty.

Nom­i­nally, each of these is a promise that some­thing is true. How­ever, that’s not quite how they work func­tion­ally. Func­tion­ally, if a coun­ter­party acts based on the as­sump­tion that the state­ment is true and is harmed as a re­sult, then they can sue for dam­ages. In other words, when pro­vid­ing a rep­re­sen­ta­tion, we provide in­surance against any dam­ages which re­sult from the rep­re­sen­ta­tion be­ing false. Bob may not even have checked that the house he’s sel­l­ing con­tains no as­bestos, and that’s fine—if he’s will­ing to in­sure the coun­ter­party against any as­bestos-re­lated risk.

This idea of in­surance be­comes im­por­tant in con­tract ne­go­ti­a­tions—there’s a big differ­ence be­tween e.g. “no en­vi­ron­men­tal prob­lems” and “no en­vi­ron­men­tal prob­lems to the best of their knowl­edge”. The former in­sures against any en­vi­ron­men­tal prob­lems, while the lat­ter in­sures against any en­vi­ron­men­tal prob­lems which the signer knew about at time of sign­ing. One puts the duty/​risk of find­ing/​fix­ing un­known prob­lems on the signer, while the other puts it on the coun­ter­party.

The other key thing to no­tice about rep­re­sen­ta­tions is that they’re as of the sign­ing date. When Bob states that his house con­tains no as­bestos, that does not in­sure against the house pre­vi­ously con­tain­ing as­bestos or con­tain­ing as­bestos in the fu­ture. It only needs to be true as of that one mo­ment in time. This be­comes rele­vant in com­plex multi-stage con­tracts, where there’s an ini­tial agree­ment sub­ject to a bunch of con­di­tions and re­views, and the fi­nal clos­ing comes later af­ter all that re­view is done. For in­stance, in a mort­gage there’s an ini­tial agree­ment sub­ject to the bor­rower pro­vid­ing lots of forms (credit check, proof of in­come, proof of in­surance, etc…), and the fi­nal con­tract is closed af­ter all that is re­viewed. In these situ­a­tions, the bor­rower usu­ally makes some rep­re­sen­ta­tions early on, and then has to “bring down” the rep­re­sen­ta­tions at clos­ing—i.e. as­sert that they’re still true.

While rep­re­sen­ta­tions deal with past and pre­sent, covenants deal with the fu­ture. They’re the clas­sic idea of con­tract pro­vi­sions: pre­com­mit­ments to do some­thing. Some ex­am­ples:

  • ABC Corp agrees to not sell the ma­chin­ery they’re leas­ing.

  • Bob agrees to not use any lead-based paint on the house he’s buy­ing.

  • Carol agrees to main­tain min­i­mum lev­els of in­surance on the house she’s mort­gag­ing.

  • Mon­i­tor­ing Corp agrees to alert Bank if there is any change in the credit rat­ing of Com­pany.

Th­ese work ba­si­cally like you’d ex­pect.

Rep­re­sen­ta­tions and covenants of­ten run in par­allel: a rep­re­sen­ta­tion that X is true will have a cor­re­spond­ing covenant to make X con­tinue to be true in the fu­ture. For in­stance:

  • ABC corp states that they do not cur­rently have any liens on their main plant, and agrees to not cre­ate any (i.e. they won’t bor­row any money with the plant as col­lat­eral).

  • Carol states that she cur­rently has some level of in­surance cov­er­age on her house, and agrees to main­tain that level of cov­er­age.

This is mainly for con­tracts which will be performed over a long time, es­pe­cially debt con­tracts. One-off con­tracts (like a pur­chase/​sale) tend to have rel­a­tively few covenants; most of their sub­stance is in the rep­re­sen­ta­tions.

Par­allels to Soft­ware Development

Rep­re­sen­ta­tions and covenants seem pretty straight­for­ward, at least con­cep­tu­ally. One is in­surance against some fact be­ing false, the other is a pre­com­mit­ment.

The tech­ni­cal com­plex­ity of con­tracts comes from the in­ter­play be­tween two el­e­ments. First:

The goal of a con­tract is to de­scribe with pre­ci­sion the sub­stance of the meet­ing of two minds, in lan­guage that will be in­ter­preted by each sub­se­quent reader in ex­actly the same way.

In other words, we want no am­bi­guity, since any am­bi­guity could later be used by one of the par­ties to “cheat” their way out of the con­tract. This cre­ates a headache very fa­mil­iar to soft­ware de­vel­op­ers: like pro­grams, con­tracts mean ex­actly what they say. There is no “do what I mean” but­ton; we can’t write some­thing am­bigu­ous and rely on the sys­tem to figure out what we meant.

Se­cond: we don’t have perfect knowl­edge of the fu­ture. When mak­ing a pre­com­mit­ment in a con­tract, that pre­com­mit­ment is go­ing to op­er­ate fairly me­chan­i­cally in what­ever the fu­ture en­vi­ron­ment looks like. Just like a func­tion writ­ten in code may en­counter a vast space of un­usual in­puts in the wild, a pre­com­mit­ment in a con­tract may in­ter­act with a vast space of un­usual con­di­tions in the wild. And since we don’t know in ad­vance which con­di­tions will be en­coun­tered, the per­son writ­ing the code/​con­tract needs to con­sider the whole pos­si­ble range. They need to figure out, in ad­vance, what weird cor­ner cases could arise.

Put those two pieces to­gether, and the pic­ture should feel very fa­mil­iar to soft­ware de­vel­op­ers.

The re­sult is that a lawyer’s job ends up in­volv­ing a lot of the same pieces as a soft­ware en­g­ineer’s job. A client/​man­ager says “here’s what we want”, the lawyer/​pro­gram­mer says “ummm I don’t think you re­ally want that, be­cause <prob­lem> hap­pens if <cir­cum­stance>”, and they go back-and-forth for a while try­ing to bet­ter define what the client/​man­ager re­ally wants. An ex­am­ple from the book pic­tures a lawyer re­view­ing a con­tract with a client (sim­plified slightly by me):

Lawyer: This is a covenant that re­stricts your busi­ness from in­cur­ring debt…

Client: That’s fine, we don’t plan to use any bank fi­nanc­ing.

Lawyer: Well, the defi­ni­tion of “debt” used is very broad. For in­stance, it in­cludes pay­ment plans on any equip­ment you buy…

Client: Well, we can add some room for that.

Lawyer: How much room do you need?

Client: Based on our cur­rent needs, less than $1M at any given time.

Lawyer: But if that new plant you were talk­ing about gets off the ground, won’t you need to buy a bunch of new equip­ment for it?

Client: Good point, we’d bet­ter ask for $5M…

This could go on for a while.

De­spite the par­allels, lawyers are not very good soft­ware en­g­ineers, in gen­eral. The most com­mon solu­tion to the sorts of prob­lems above is to throw a patch on it, via two kinds of ex­cep­tions:

  • Carve­outs: ac­tion X is gen­er­ally for­bid­den, ex­cept for spe­cial case Y.

  • Bas­kets: ac­tion X is gen­er­ally for­bid­den, ex­cept in amounts be­low some limit (e.g. the $5M limit in the ex­am­ple above)

Over the course of ne­go­ti­a­tions, patches are lay­ered on top of patches. An ex­am­ple from the book:

Lit­tle Corp may not trans­fer any Shares dur­ing the term of this Agree­ment, ex­cept for (i) trans­fers at any time to its Affili­ates (in­clud­ing, with­out limi­ta­tion, Micro Corp) other than Medium Corp, and (ii) so long as an Event of De­fault at­tributable to Big Corp shall have oc­curred and be con­tin­u­ing, trans­fers to any Per­son (in­clud­ing, for the avoidance of doubt, Medium Corp).

This mess is the con­trac­tual equiv­a­lent of a se­ries of if-state­ments nested within if-state­ments. This is, ap­par­ently, stan­dard prac­tice for lawyers.

(Another com­plaint: in a com­plex con­tract, it would not be hard to in­clude pro­vi­sions alongside the table of con­tents which nul­lify pro­vi­sions which ap­pear in the wrong sec­tion. Then peo­ple re­view­ing the con­tract later wouldn’t have to read the whole thing in or­der to make sure they didn’t miss any­thing rele­vant to their use-case; it would be the con­tract equiv­a­lent of vari­able scope. My mother’s a lawyer in real es­tate and wills, so I asked her why lawyers don’t do this. Her pos­si­bly-tongue-in-cheek-an­swer: might put lawyers out of busi­ness. Kid­ding aside, the bar as­so­ci­a­tion en­gages in some pretty in­ces­tu­ous rent-seek­ing, but judges have been push­ing for decades to make con­tracts and other le­gal doc­u­ments more leg­ible to non-lawyers.)

The “Do What I Mean” Button

A con­tract writer’s job is much eas­ier than a pro­gram­mer’s job in one key re­spect: a con­tract will ul­ti­mately be in­ter­preted by hu­mans. That means we can say the equiv­a­lent of “look, you know what I mean, just do that”, if we ex­pect that a court will ac­tu­ally know what we mean.

This gives rise to a bunch of stan­dard tricks for in­vok­ing the do-what-I-mean but­ton. We’ll talk about three big ones: ma­te­ri­al­ity, rea­son­able­ness, and con­sis­tency with “or­di­nary busi­ness”/​”past prac­tice”.

Materiality

Roughly speak­ing, ma­te­ri­al­ity means ig­nor­ing small things. For in­stance, com­pare:

  • “Bor­rower shall not de­fault in its obli­ga­tions un­der any con­tract”, vs

  • “Bor­rower shall not de­fault in its obli­ga­tions un­der any ma­te­rial con­tract”

The first would be breached if e.g. the bor­rower for­got to up­date their pay­ment in­for­ma­tion on their $10 monthly github sub­scrip­tion, and the pay­ment was late. The sec­ond would ig­nore small things like that.

In gen­eral, ma­te­ri­al­ity is rel­a­tive to the size of the busi­ness. A $100k over­sight would be quite ma­te­rial to most small busi­nesses, but im­ma­te­rial to AT&T. It’s also rel­a­tive to the con­tract—if that $100k over­sight is di­rectly rele­vant to a $300k con­tract, then it’s ma­te­rial, even if the $300k con­tract it­self is small change to AT&T.

Where’s the cut­off line? That’s for courts to de­cide, if and when it mat­ters. That’s how push­ing the do-what-I-mean but­ton works; you have to rely on the courts to make a sen­si­ble de­ci­sion.

One par­tic­u­larly com­mon us­age of ma­te­ri­al­ity: “ma­te­rial ad­verse change/​effect”. Rather than say­ing “X has no pend­ing law­suits”, we say “X has no pend­ing law­suits whose loss would en­tail a ma­te­rial ad­verse effect”. Rather than say­ing “Bor­rower will no­tify Len­der of any change in their busi­ness fore­casts”, we say “Bor­rower will no­tify Len­der of any ma­te­rial ad­verse change in their busi­ness fore­casts”. This way a lender or buyer finds out about prob­lems which ac­tu­ally mat­ter, with­out be­ing in­un­dated with lots of minor de­tails.

Reasonableness

Rea­son­able­ness is ex­actly what it sounds like. It’s say­ing some­thing that has some ob­vi­ous loop­hole to abuse, then giv­ing a stern look and say­ing “don’t go pul­ling any bul­lshit”. Ex­am­ple: “Com­pany shall re­im­burse X for all of X’s out-of-pocket ex­penses aris­ing from...” vs “Com­pany shall re­im­burse X for all of X’s rea­son­able out-of-pocket ex­penses aris­ing from…”

Some pat­terns where rea­son­able­ness shows up:

  • Rea­son­able ex­pec­ta­tions, e.g. “Bor­rower shall no­tify Len­der of any changes which could rea­son­ably be ex­pected to have a ma­te­rial ad­verse effect…”

  • Con­sent not to be un­rea­son­ably with­held, e.g. “ABC Corp may not X with­out con­sent of XYZ Corp, such con­sent not to be un­rea­son­ably with­held.”

  • Rea­son­able efforts, e.g. “Bor­rower shall ob­tain X from their in­surer.” vs “Bor­rower shall ex­ert rea­son­able effort to ob­tain X from their in­surer.”

What would each of these do with­out the rea­son­able­ness clause? In the first case, the bor­rower could claim that they didn’t ex­pect Ob­vi­ous Bad Thing to im­pact their busi­ness. In the sec­ond case, XYZ Corp could with­hold con­sent for some case they ob­vi­ously don’t care about in or­der to ex­tract fur­ther con­ces­sions from ABC Corp. In the third case, an in­surer could sim­ply re­fuse to provide X, and the bor­rower wouldn’t be able to do any­thing about it.

Be­hav­ing Normally

Some­times a lender or prospec­tive buyer wants to say “what you nor­mally do is fine, so do that and don’t go crazy”. Two (similar) stan­dards for this: “in the or­di­nary course of busi­ness” and “con­sis­tent with past prac­tice”.

Typ­i­cal ex­am­ples:

  • “Bor­rower will not in­cur any <debt of spe­cific type> ex­cept in the or­di­nary course of busi­ness.”

  • “ABC Corp will not make any pay­ments to <sub­sidi­ary> ex­cept in a man­ner con­sis­tent with past prac­tice.”

In gen­eral, this is a pretty good way to let busi­ness con­tinue as usual with­out hav­ing to go into all the tiny de­tails of what busi­ness-as-usual in­volves, while still en­sur­ing that e.g. a bor­row­ing com­pany doesn’t sell all their as­sets, dis­tribute the funds as a div­i­dend to a par­ent com­pany, and then de­clare bankruptcy.

Re­me­dial Provisions

In gen­eral, if a con­tract is breached, the coun­ter­party can sue for dam­ages. If you want any­thing else to hap­pen as the re­sult of a breach, then it needs to be in­cluded in the con­tract. In par­tic­u­lar, com­mon things trig­gered by a breach in­clude:

  • Ter­mi­na­tion: coun­ter­party gains the right to ter­mi­nate the contract

  • Ac­cel­er­a­tion: loaned money must be paid back immediately

  • In­dem­nifi­ca­tion: coun­ter­party must be paid for any breach-re­lated damages

The last is some­what re­dun­dant with the court sys­tem, but by in­clud­ing it ex­plic­itly, the con­tract can also spec­ify how to calcu­late dam­ages, how dam­ages are to be paid, caps or ex­cep­tions to li­a­bil­ity, etc. Rather than leav­ing such mat­ters to the whims of a court, the con­tract can spec­ify them.

Ter­mi­na­tion and ac­cel­er­a­tion are par­tic­u­larly rele­vant from a ne­go­ti­a­tion stand­point—the former for one-shot con­tracts like sales, and the lat­ter for long-term con­tracts like debt.

The ear­lier stages of a com­plex sale (e.g. a merger/​ac­qui­si­tion of a com­pany) in­volve an agree­ment to sell sub­ject to a long list of con­di­tions be­ing satis­fied—i.e. the “due dili­gence” con­di­tions. If any of those con­di­tions are not met, then the buyer gains the right to ter­mi­nate the con­tract—i.e. walk away from the deal. But these things can take months; the last ac­qui­si­tion I saw took around a year. Dur­ing that time, the buyer may change their mind for rea­sons en­tirely un­re­lated to the sel­ler—e.g. mar­ket prices for the sel­ler’s as­sets may change. The sel­ler wants to pre­vent the buyer from walk­ing away in a case like that.

This means that the buyer has in­cen­tive to ask for very com­pli­cated and/​or very sub­jec­tive con­di­tions, to give them­selves the op­por­tu­nity to walk away when­ever they want. For in­stance, if a buyer man­ages to get a con­di­tion which re­quires “X which is satis­fac­tory in Buyer’s sole dis­cre­tion”, then the buyer effec­tively gains a blan­ket op­tion to walk away from the deal; they can always just claim that some inane de­tail of X is un­satis­fac­tory. (This is a good ex­am­ple where rea­son­able­ness can fix the prob­lem.) In par­tic­u­lar, if mar­ket con­di­tions change, then the buyer may use that op­tion to ne­go­ti­ate more con­ces­sions, like a lower pur­chase price.

Ac­cel­er­a­tion has a similar effect in debt deals. No­body ever wants to ac­cel­er­ate debt; it’s a sure­fire way to end up in bankruptcy court. When a con­tract breach gives a lender the op­tion to ac­cel­er­ate, what ac­tu­ally hap­pens is that they use that op­tion as lev­er­age to ne­go­ti­ate a new deal. They’ll want a higher in­ter­est rate, or a claim on more of the bor­rower’s as­sets, or the like.

Take­away: just be­cause a con­tract speci­fies a par­tic­u­lar penalty for breach does not mean that the penalty ac­tu­ally hap­pens. Often, the penalty is re­ally used as an op­tion by one party to rene­go­ti­ate the con­tract, and pro­vides lev­er­age for such a ne­go­ti­a­tion.

Takeaways

Con­tracts are a lot like com­puter pro­grams: they’re taken very liter­ally, and they could po­ten­tially en­counter a wide va­ri­ety of cor­ner cases in the wild. To­gether, those two pieces make a con­tract writer’s job quite similar to a pro­gram­mer’s job: a client/​man­ager will tell you what they think they want, and then you go back-and-forth try­ing to for­mu­late what they re­ally want.

Com­pared to (good) soft­ware de­vel­op­ers, lawyers do not seem to be very good at this; they tend to throw patches on top of patches, cre­at­ing more cor­ner cases rather than fewer. They don’t seem to have even re­al­ized that en­forced scope and mod­u­lar­ity are things which one could use in a con­tract; con­se­quently, ev­ery con­tract must be read in its en­tirety by any­one rely­ing on it. That puts a sharp limit on the scale of to­day’s con­tracts.

Un­like pro­gram­mers, lawyers do have a “do what I mean” but­ton, al­though its use comes with a cost; it means leav­ing in­ter­pre­ta­tion to the whims of a court. For many “sim­ple” things, that cost is rel­a­tively minor—so con­tracts can ig­nore “im­ma­te­rial” prob­lems, or re­quire “rea­son­able” be­hav­ior, or stipu­late con­sis­tency with “past prac­tice” and “the course of or­di­nary busi­ness”.

Func­tion­ally, con­tracts provide in­surance against stated facts be­ing false, and they provide pre­com­mit­ments for the fu­ture. They can also stipu­late nom­i­nal penalties for breach of con­tract, though in prac­tice these penalties of­ten serve as op­tions to rene­go­ti­ate (with lev­er­age) rather than ac­tu­ally be­ing used.