Drafting an agreement is like programming

At 11 o’clock in the morning, I waited at a “mamak” restaurant for my friend to arrive. The place was in a quiet corner of the Curve. Customers chattered, tapping away at laptops, sipping teh tarik, some smoking, some deep in conversation. People hang out there to kill time, before heading elsewhere for the real appointment.

Programming is like contract writing, or maybe it is vice versa.

When he arrived, I shook hands with the friend who had moved successfully from IT to finance. We spoke of various matters, and life in general.

And then he shared a pearl of wisdom, which felt like an out-of-place luxury. “I used to do programming,” he said casually, “and it helped me to understand how to vet and draft an agreement.”

“How so?” asked curious me.

“In programming, you declare your variables. In contract drafting, you define your terms. In programming, you have functions, defining what happens, when. In contract drafting, you also define what happens, when. In programming, you catch exceptions. In contract drafting, you catch exceptions too.”

That made sense, even though I wasn’t a programmer. (I’m trying to pick up some programming in my free time, but there isn’t much free time to begin with.)

“In other words, what do you mean?”

“Define the terms; plan what happens, then draft it; then imagine what else could happen, and draft around it.” He was done with his meal. “Trust me. When I went into finance I had to vet through dozens of agreements every day, that helped me become good at it.”

He used to program, but today he deals with startups from the other side of the table. He speaks their lingo. Yet he understands the legal jargon that these tech types have to face. He has become the perfect go-between to explain to techies what happens, if they sign the contract(s).

I recalled a conversation I’d had with a VC some time back. She’d said something similar: “Within ten minutes of talking to the guy, I’ll know whether his product is worth looking into.” They develop a keen sense of how to detect bullshit.

Predatorial animals tend to know exactly how and where to attack, to best bring down their prey. The guy who goes through dozens of contracts every month is apt to develop keen sense of what is workable. And as the friend from an IT background told me, developing a contract can sometimes be like programming.

First, define your terms.

Second, imagine what you want to happen.

Third, brainstorm the worst case scenarios if something unexpected happens.