My Response to a Student Seeking Advice on Contract Drafting

Today I came across a blog post entitled, straightforwardly enough, “Looking for Advice on Contract Drafting.”

It was posted on the Marquette University Law School faculty blog and was written by a part-time student by the name of Tiffany. Besides being a student, she holds down a job—she’s responsible for maintaining the templates of her company’s commercial contracts and preparing deal documents based on those templates.

In her post, Tiffany describes how that responsibility fell to her; says that the work is painstaking but has its satisfactions; wonders whether she runs the risk of making a mistake that could lead to a lawsuit; and finally asks whether anyone has any suggestions how she might improve her contract-drafting skills.

Here’s how I’d respond:

Tiffany: For me, the key passage in your post is this one:

And, I would be lying if I said working on contract language is a creative or imaginative process, because it is not. Really, from my own experiences, day-to-day transactional contracts are just boilerplate indemnity language and seemingly ever changing “standard” business terms. Maybe that’s why contract drafting is usually left to a contract administrator or a paralegal . . . or a Marketing Coordinator who goes to law school in her spare time.

If your responsibilities consist of merely changing the numbers and product names in an endless stream of otherwise identical documents, then sure, that task could be delegated. But if that were all there was to it, you probably wouldn’t have asked for advice.

Junior lawyers, as well as many senior ones, are way too deferential when it comes to contract language. They assume that what’s in a contract is holy writ, and they limit their input to tweaking the deal terms and making sure everything is internally consistent.

I suggest that instead you approach contract language critically. When reading a contract, ask yourself what everything means. If you don’t understand a given provision, research the issue, and don’t be satisfied with the conventional wisdom. If something seems like gobbledygook, it probably is—consider what the alternatives are.

I’m reluctant to say it, but if you want to get to grips with contract language, you’re going to have to consult my book, A Manual of Style for Contract Drafting. I know that seems desperately self-serving, but I’m confident that others would give you the same advice.

What would you accomplish with a critical approach to contract language? You’d probably feel generally more confident in your work. But more to the point, I suspect that you would spot all sorts of ways to make your company’s templates much clearer and more consise—that’s nothing to sneeze at when you’re dealing with templates that are used countless times. You could make a real difference.

If you have any suggestions for Tiffany, by all means post them here.

About the author

Ken Adams is the leading authority on how to say clearly whatever you want to say in a contract. He’s author of A Manual of Style for Contract Drafting, and he offers online and in-person training around the world. He’s also chief content officer of LegalSifter, Inc., a company that combines artificial intelligence and expertise to assist with review of contracts.

3 thoughts on “My Response to a Student Seeking Advice on Contract Drafting”

  1. My advice to Tiffany: Focus primarily on understanding the business ideas.

    Draw a grid on a whiteboard to play the what-if game:

    – Brainstorm a list of the various kinds of events that could occur during various phases of the contract relationship: startup; normal operations; unusual operations; trouble; and shut-down.

    – For each Event X, ask: If this occurs, what will the parties want to happen — or to NOT happen — and (if appropriate) how exactly will they make their desires come to pass.

    – Turn this list into standard English.

    Much of your contract-drafting work is now largely finished.


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.