The 3 R’s of Contracts
I’m not a lawyer. I’m not giving legal advice, and I suggest you consult your own lawyer (I can recommend at least a few good ones) before entering into any contractual agreements.
I’ve been on both sides of quite a number of contracts (more than I can count), so I’ve seen a lot of different types of things embedded within the cryptic language that, frankly, need at least a few years at law school to understand. In the process of building the agreements that FounderTherapy uses for our contractors, our employees, and our clients, I’ve followed the advice below. As a result, I’ve saved time and reduced headaches for me and everyone else involved.
Every lawyer you speak with will tell you their agreements are “standard” and that “everyone does it this way”. While there’s a grain of truth to these statements, the truth of the matter is that there’s a great deal of variety in terms of what demands are placed on each side of such agreements depending on which lawyer drafts it. Lawyers (both the good ones and the bad ones) provide guidance and counsel (thus the name), and it’s up to you to decide what advice to take.
What I’ve learned is that there are some things that will make your life easier when you’re on the delivering side of things like work-for-hire and non-disclosure agreements.
Reasonable
When you hand a contract to someone, whether they are a software developer you want to hire or a business development consultant who needs a business agreement, you’re crafting a legal document that not only defines the expectations you have for their performance, but also makes a statement about how you view your relationship with them. Their success in meeting your expectations depends upon their trust in you.
As with any relationship, if you make unreasonable demands, such as performance requirements that would mean they need to work 27 hours a day or the equivalent of indentured servitude if things go sideways, you’re going to start your formal relationship off on the wrong foot. Being reasonable means putting yourself in their shoes, and evaluating each requirement against whether you’d want to have such a requirement placed upon you.
Establish reasonable expectations and deliverables with them before even asking your lawyer to put pen to paper. Be clear about your expectations, require them to be clear about theirs, and discuss all of the aspects of how you want to work together. Importantly, only put into a contract those things that you reasonably need to include. Every additional clause can result in negotiation delays and lawyer rewrites.
Responsible
Don’t include contract clauses that you would not enforce (read: take them to court) if they’re broken. You want to make sure you’re protected, through such things as non-disclosure agreements, but every clause you put into a contract will most likely require negotiation, may cause the other party to insist on a higher level of compensation, or potentially could cause them to walk away.
I regularly see contracts and employee agreements that have IP assignment clauses that read as patent land grabs. Software engineers regularly experiment with and occasionally invent new software technology. They never know where things will lead, and often can figure out novel solutions to an employer’s problems through this exploration.
With overly broad IP assignment clauses, that engineer will be hesitant to do this type of exploration for fear that their employer will claim their creation even when it’s irrelevant to their business. As a result, the employer doesn’t have the benefit of those novel solutions the engineer might find if they felt more free to explore. For you as an employer, this situation is just shooting yourself in the foot. The best way to handle IP assignment is to make it specific to relevant technology developed in the course of working for your company.
Even worse, I’ve seen employment agreements that demand disclosure of all previous contracts and potential IP. After 15 years in this industry, I can honestly tell you that I don’t remember all of the technology I developed. Requiring such a disclosure can take hours and hours, and most developers are likely to not bother to do it at all. I’ve never encountered a situation where such a disclosure winds up being relevant, so what’s the point? These types of demands result in arguments between you and the other party, cost money once lawyers are involved (and they’re often involved), and degrade good will. Given the rapid pace of change in the software world, these clauses just result in expensive history lessons.
Realistic
Having unrealistic terms in your contracts is a sure-fire way to cause your potential employees and contractors to walk away or demand extra compensation.
For example, I’ve seen non-compete clauses in contracts that lock up an employee for years after they are no longer working with a company. Only the most technologically advanced or senior business positions in a company warrant such restrictions. In such cases, I’ve often seen competitor definitions that would make it impossible for a former employee to work for just about any other technology company. Worse, if you’re not clear about such a clause and your team finds out after the fact, it can lead to tremendous animosity and delayed work as everyone spends time discussing how you misled them.
If you want to make sure that a contractor doesn’t work with a competitor, make sure to compensate them for the potential lost business. That can be expensive, and for the vast majority of employees and contractors, it won’t be worth it. If it’s a contract relationship, remember that contractors have other clients, and if you’re not realistic in your contract, they’re likely to just drop you, which means you won’t have the benefit of their expertise.
I see similar situations with NDAs. At FounderTherapy, we have a policy to never sign NDAs prior to meeting with Founders (if we’re hired, we’re happy to sign such documents). In addition to being expensive for us (our lawyer needs to review all of them, even the ones we decide not to sign), a Founder’s idea isn’t worth much without an actual working implementation that has been market tested. The idea and a discussion about the business are far better protected by a “FriendDA” (a handshake agreement to not disclose, which is how we treat all conversations with Founders).
Closing the Deal
For the unicorn startups and their founders that actually have something real to protect, they should be speaking with a patent attorney. For everyone else, there’s a saying: “Ideas are like assholes: Everyone’s got one”. If an idea is worth turning into a company, you’re going to be far better off talking with lots of people who can help rather than keeping it to yourself or restricting discussions with an NDA.
Especially for startups, these guidelines also mean not encoding into a contract a set of completely inflexible deadlines and deliverables. Things change rapidly when building a new company, and what you need today may be different from what you need next week, and what you need in a couple of months might be unimaginable.
Most importantly, don’t surprise your contractors and employees with something that you didn’t discuss in the contract. That’s going to cause more time negotiating and more legal work (which means higher cost for both you and them), and is going to set a bad precedent for how they can expect to work with you going forward.
Following the three R’s when creating contracts can help simplify the process and get your contracts drafted, negotiated, and signed faster. That means you can get back to what you really should be doing as a founder: building your product.
Picture by 24oranges.nl
Originally published at foundertherapy.co.
